Update remediation advice for cache control for a [non-]sensitive page

[aidanstansfield]

Currently, the remediation advice for the two VRT items Server Security Misconfiguration > Lack of Security Headers > Cache-Control for a [Non-]Sensitive Page state:

As a best practice, consider using the Cache-Control: no-cache as it will help insure that the browser does not cache pages.

It also references the Cache-Control docs. The issue is that setting the Cache-Control header to no-cache means the browser can still cache and store the response, it just must revalidate that cached response every time. From the Mozilla docs:

no-cache: The response may be stored by any cache, even if the response is normally non-cacheable. However, the stored response MUST always go through validation with the origin server first before using it, therefore, you cannot use no-cache in-conjunction with immutable. If you mean to not store the response in any cache, use no-store instead. This directive is not effective in preventing caches from storing your response

Thus, even if this header is set on a sensitive page, it is still possible to view the contents of that sensitive page by examining the cached files locally. This can be remediated by changing the advice to.

As a best practice, consider using the Cache-Control: no-store as it will help insure that the browser does not cache pages.