In this blog, we will take a look at the headers recommended by the Open Web Application Security Project (OWASP). These headers can be utilized to actively increase the security of the web application. This blog tries to shed a light on both headers that actively increase security as well as headers that might have a passive impact on security.
- Content-Security-Policy (CSP)
X- Frame Option
- This header gives instructions to the browser if and when a page should be displayed as part of another page (i.e. in an IFRAME).
- Allowing a page to be loaded inside an IFRAME opens up the risk of a so-called Clickjacking attack.
- The X-Frame-Options can be used with the following options
- DENY- Unless your application explicitly requires being loaded inside an IFRAME.
- SAMEORIGIN- When an application uses IFRAME within the application itself.
- ALLOW-FROM <URI>- When you need your page to be farmable defines the external origin.
E.g. X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM contextis.co.uk
- It is known as HSTS(HTTP Strict Transport Security)
- It tells the browser to enforce an HTTPS connection whether a user tries to reach the site sending this header.
- The header is only valid for a certain amount of time
- The lifetime is specified in seconds, STS-settings for half a year.
E.g. Strict-Transport-Security: max-age=15768000
- To extend this rule to all subdomains
Strict-Transport-Security: max-age=15768000; includeSubDomains
- It instructs the web browser to utilize its Cross-Site Scripting protection.
- Good idea but very difficult to filter the malicious code, sanitize and maintain the working
- It is difficult to give a definitive recommendation for this header.
- g. To explicitly enable the filter that tries to sanitize malicious input
- To use the all-or-nothing approach
X-XSS-Protection: 1; mode=block
- To report an incident
X-XSS-Protection: 1; mode=block; report=https://domain.tld/folder/file.ext
- This header can be used to prevent certain versions of Internet Explorer from “sniffing” the MIME type of pages.
- It leads to cross-site scripting risk.
E.g. X-Content-Type-Options: nosniff
- Public-Key-Pinning was known as HTTP Public Key Pinning (HPKP).
- It’s new and is not yet widely used but it has great security potential.
- It allows site operators to specify (‘pin’) a valid certificate and rely less on CAs
- Similar to HSTS, the browser is then supposed to remember this pin and only accept connections to a site if the certificate pin matches the pin provided by the header.
E.g. Public-Key-Pins: pin-sha256=”<sha256>”; pin-sha256=”<sha256>”; max-age=15768000;
To include all sub-domains
Public-Key-Pins: pin-sha256=”<sha256>”; pin-sha256=”<sha256>”; max-age=15768000; include Subdomains
- To specify which content in a site may be executed and which not.
- The problem is the browser doesn’t know which source to trust and which not to trust.
- The solution is white listing legitimate resource.
E.g. Content-Security-Policy: script-src ‘self’ https://apis.google.com
- Cookie attributes (HttpOnly and Secure)
- Server / X-Powered-By
- Caching directives
- X-Robots-Tag and Robots.txt
Cookie attributes (HttpOnly and Secure)
- These are the special attributes that can be associated with cookies, which can drastically reduce the risks of cookie theft.
E.g. Set-Cookie: cookie=xxxxxxxxx; HttpOnly
- Secure – It instructs the browser to send this cookie only over an HTTPS connection. This should be the norm for all session and authentication related cookies.
E.g. Set-Cookie: cookie=xxxxxxxxx; Secure
- Yes we can combine both
E.g. Set-Cookie: cookie=xxxxxxxxx; HttpOnly; Secure
Server /X- Powered- By
- Both of these headers advertise the server software in use and its version number.
- It helps for debugging purposes not useful for user experience.
- It should either be omitted entirely or reduced to an amount that does not leak any version details.
- Another issue that is often overlooked is the caching of sensitive information by the browser.
- A browser frequently stores elements of a website to a local cache to speed up the browsing experience.
- To instruct the browser not to store anything in its cache one should use the following directives.
E.g. Cache-Control: no-cache, no-storeExpires: 0Pragma: no-cache
- This is also used for caching purpose.
- The server uses a special algorithm to calculate an individual ETag for every revision of a file it serves.
- Browser asks if the file is under ETAG if server responses with HTTP 304 status it means browser should to use local cache version of it or the server sends full path of the resource with status HTTP 200 status.
E.g. FileETag MTime Size
X-Robots-Tag and Robots.txt
- The X-Robots-Tag header gives search engines, which support this header, directives on how a page or file should be indexed.
- There are directories where few we want it to be displaced and few are secret directories not to be displayed, you should never list files that you want to block.
- g An example to block everything:
User-Agent: *Disallow: /
- An example that tells the crawler to index everything under /Public/ but not the rest
E.g. User-Agent: *Allow: /Public/Disallow: /
Recommended – Read my next blog on Encoding schemas.