This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
CRV2 SecCommsHTTPHdrs
This is a draft version
Overview
HTTP headers allow the server to dictate or advise the user agent and intermediary servers how to handle the content being provided. Some of these headers can aid a web site in securing itself; these include the standard Cache-Control headers, and newer specifications like HSTS and Content Security Policy headers.
Description
From a security point of view controlling the HTTP headers sent with web site content can tell the users browser how to store the content, how to access further content, and how to trust various parts of the content received by the browser.
Two point to note up front:
- Headers can only be trusted over a HTTPS session
- This section only covers HTTP response headers
Without HTTPS between the web server and the users browser an attacker can modify the content or the associated headers. Thus if you were returning headers specifying that your web site should only be access over HTTPS, an attacker could remove these headers and the browser would not receive the information. A web site should not trust HTTP request headers for security decisions as there are many ways an attacker could modify these headers (or construct the whole request themselves), so there is nothing to cover for secure headers coming from the client, as they are inherently insecure. Of course the cookie header is an exception to this, but that is because our web site has set the cookie header to a random value that should only be known during the browsing session. This section will not cover the cookie header as this is covered in the session management topic.
For business web sites that allow sensitive or confidential information to be downloaded to the client device, the caching of that sensitive data will become a security issue. A user accessing their bank account details does not want an intermediary proxy caching their web pages. A legal web site does not want copies of sensitive PDF documents stored on the laptop or smartphone disk storage, only for that device to be lost and the documents visible to an attacker.
The 'Cache-Control' header tells the users browser how to handle the content being downloaded. Some browsers can interpret the header values differently thus the understood header settings to return with content that must not be cached are:
Cache-Control: no-store, no-cache Pragma: no-cache Expires: 0
This should be understood by all browsers (including mobile webviews) that the content being returned must not be stored to disk cache. Note that it is possible for intermediate proxies to ignore caching headers and still cache the content, which is another reason why using end-to-end HTTPS sessions is important, as the proxies will only have encrypted versions of the sensitive content.
What to Review
When reviewing code modules from an HTTP header sercurity point of view, some common issues to look out for include: