0

During security tests/assessments it is often said that you need to set the cache-control to no-cache (and some other things). But as I was looking at this I found that POST requests are not cached (which makes sense) by default.

So my question is: If sensitive data is only send as response to a POST request is it then still necessary to set the no-cache header for those POST requests? This is assuming it is no problem that GET requests are cached as they contain nothing of interest.

  • 1
    See stackoverflow.com/a/626083/413180 . I would take this to mean that the browser could cache the response, therefore it is good practice to set the headers to inform the browser that it should not. – SilverlightFox Mar 20 '17 at 11:41
  • Yes saw that one already, but isn't it something that is only possible if you really go out of your way to configure caching of POST requests? So more of an extreme outlier than actual risk? – Wealot Mar 20 '17 at 11:44
  • RFC 2616 (13.10) explicitly states "Some HTTP methods MUST cause a cache to invalidate an entity....PUT...POST...DELETE". That means that a browser can write this data to its cache (in the absence of an explicit directove not to) but it cannot use the value in the cache. You've also said that using "no-cache" is important for security - while in the case of a non-idempotent request, it is very unlikely that a browser would write a response to cache, they frequently will write no-cache content to disk. If you want to prevent this, use "no-store" – symcbean Mar 20 '17 at 13:10
  • 1
    @symcbean Just a note to say that we should now be looking at this section of rfc 7234 rather than the obsolete 2616. A cache MUST invalidate the effective Request URI [snip] response header fields (if present) when a non-error status code is received in response to an unsafe request method. This is for "unsafe" methods, not just non-idempotents. You're correct though to advise no-store although many modern browsers interpret no-cache as equivalent. – SilverlightFox Mar 20 '17 at 13:55
  • Ok I see the no-store point, but to just clarify: in the POST response is actually sensitive data so if there is any chance that a "normal" user has a browser that caches that to the harddrive that would be an issue. How high is the chance a normal user's browser (who doesn't tinker to much) would cache POST replies? And as I understand it now this would only be the case when an error status code is received? – Wealot Mar 20 '17 at 14:58
1

Referring, to this answer I would take this to mean that the browser could cache the response, therefore it is good practice to set the headers to inform the browser that it should not.

As that is a an old post, note that we should now be looking at this section of rfc 7234 rather than the obsolete 2616. Many modern browsers now interpret no-cache as no-store as equivalent, although for the small price of setting the correct header I would explicitly set no-store.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.