Primer on HTTP Security Headers

What are HTTP headers?

HTTP headers are a list of key-value pairs which are sent along with HTTP requests and responses.

Let us take an example with below request(left) and response(right):

In the above snapshot, we can see that we have an HTTP request being sent to Host. Along with that request/response, we see Key:Value pairs, these are HTTP Headers. These look similar to YAML format.

HTTP headers let the client and the server pass additional information with an HTTP request or response. ¹

Security Headers

Security Headers are HTTP headers that can be used to enhance the security of an application. Having these can stop common attacks such as code injection, cross-site scripting attacks, and clickjacking.
Below is a list of commonly used HTTP Security Headers:

• X-Frame-Options
• Access-Control-Allow-Origin
• Strict-Transport-Security
• Content-Type and X-Content-Type-Options
• Referer and Referrer-Policy
• Set-Cookie
• Cache-Control
• Content-Security-Policy

X-Frame-Options

• X-Frame-Options is a response header.
• It instructs the browser whether the page being fetched can be displayed inside an <iframe>, <embed>, <frame> & <object>.
• This improves protection against clickjacking. ²
• A new implementation CSP frame-ancestors is used more recently.
  If CSP frame-ancestors is present X-Frame-Options will be ignored.

Example:

Access-Control-Allow-Origin

• Access-Control-Allow-Origin is a response header
• It instructs the browser whether the response can be accessed(shared to Origin by the browser) by the Origin which has requested the resource.
• When siteX.com tries to fetch content from siteY.com, the browser sends an Origin header which contains the site which is requesting the resource, in this case, siteX.com. This is a normal Cross-Origin request.
• By default siteX.com cannot access siteY.com’s resources unless siteY.com opens it by using the Access-Control-Allow-Origin header.
• Thus, for each page/resource that siteY.com permits siteX.com to access it should include a reponse header:

  Access-Control-Allow-Origin: https://siteX.com
  

  which will let siteX.com access resources from siteY.com

Note: When specifying an origin, only one origin can be set in the value. For example:

Access-Control-Allow-Origin: https://adityatelange.in https://www.adityatelange.in
Access-Control-Allow-Origin: *.adityatelange.in

are invalid values!

• To counter the above issue, the Access-Control-Allow-Origin has to be set to * for requests not containing any Origin header.
• For requests containing an origin header, the origin header should be checked against an allow-list of origins stored which can access the resource and then added back to the response as a value to Access-Control-Allow-Origin. Along with this, a Vary response header has to be sent with a value as Origin

  Access-Control-Allow-Origin: https://adityatelange.in
  Vary: Origin
  

Strict-Transport-Security

• Strict-Transport-Security is a response header.
• Popularly known as HSTS: HTTP Strict Transport Security.
• It instructs that the website should be accessed only using HTTPS.
• Browsers automatically convert any further attempts to connect to the site from HTTP to HTTPS.
• This helps prevent Man-In-The-Middle(MITM) attack.
• Google maintains an HSTS preload service which recommends setting value as per the below example. ³ Usually max-age is set to 63072000 or 2 years.

Strict-Transport-Security: max-age=<expire-time-in-seconds>; includeSubDomains, preload

Content-Type and X-Content-Type-Options

• X-Content-Type-Options is a response header.
• It instructs the browser that the MIME type value set in the Content-Type header should only be used and not changed by using MIME type sniffing ⁴ (guessing MIME type by parsing the bytes of the resource, sometimes called magic-bytes)
• Using strict type checking will ensure that the browser does not render/process unidentified content as valid content by guessing the file type.
• For example, if the app has an upload functionality that lets users upload images only of type PNG, the Content-Type header will have the value set as image/png, thus even after uploading a non-PNG file (suppose PHP) will only be processed as image/png by the browser.

X-Content-Type-Options: nosniff

Referer and Referrer-Policy

• Referer is a request header. Referrer-Policy is a response header.
• Referer header indicates the origin/URL from which the request was made.
• Referrer-Policy indicates what part or URL should be made available in the Referer header.
• So, if we set Referrer-Policy to same-origin, it means that the Referer field will only be included in requests made to the same origin as the current page.
• Referrer-Policy will be set by the web-app developer while the Referer header will be set by the browser following the policy stated in Referrer-Policy.

Basic Syntax:

Referrer-Policy: {policy-directive};

Policy Directives for Referrer-Policy:

Referer vs Origin:

• Referer is similar to the Origin header we saw in earlier parts of this blog, but it also includes a path along with the origin.
• Referer is typically used to identify the webpage that is linked to the resource being requested while Origin is used to identify the source of the request itself.
• That means Referer tells you which page the user was on before they made the request, while the Origin tells you which website or application made the request.

Set-Cookie

• Set-Cookie is a response header.
• It is used to send a cookie(s) from the server to the browser.
• A cookie is a small string that is used to identify a user/device.
• A client will then store this data and send it in subsequent requests through the Cookie header.

Basic Syntax:

Set-Cookie: {cookie-name}={cookie-value}

Attributes:

Of these Secure, SameSite, Domain, Path, and HttpOnly are considered important when it comes to securing an application.

Set-Cookie: {cookie-name}={cookie-value}; Domain={domain-value}; Path={path-value}; Secure; HttpOnly; SameSite={samesite-value}

Note: Remember setting multiple cookies separately (not comma , separated) for example:

Set-Cookie: c_one=val_one; Domain=abc.xyz; Secure; HttpOnly; SameSite=Strict
Set-Cookie: c_two=val_two; Domain=abc.xyz; Secure; HttpOnly; SameSite=Lax

Let’s look into what each of the attributes does.

Cache-Control

• Cache-Control is both request and response header.
• It holds instructions about caching content.
• It is important to prevent certain information from getting cached, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. ⁵
• A web app should use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached.
• There are mainly 2 types of caches:
  • Private Cache
  • Public Cache/Shared Cache

Basic Syntax:

Cache-Control: {attribute}={value}; {attribute}={value}

Policy Directives:

Content-Security-Policy

• Content-Security-Policy or CSP is a response header.
• It is used to specify a whitelist of allowed sources of content for a web page.
• By far it can be said that CSP is the most powerful security header out of all the headers discussed above.
• If the CSP policy is set properly, many attacks can be mitigated on the browser/client side.
• CSP header is made up of one or more directives which are separated by a semicolon ;.
• It is important to carefully consider the allowed sources of content for a page and test the CSP configuration to ensure that it does not break the functionality of the page.
• Tool to generate CSP: Report URI: Generate your Content Security Policy

Basic Syntax:

Content-Security-Policy: {policy-directive}; {policy-directive}

Policy Directives: ⁶

Note: {source} can hold values:
- 'self': Used as it is, denotes the origin from which the document is being served.
- scheme-type : Includes schemes such as http:, https:, data:, blob:.
- host : Includes hostnames or IP addresses with ports, like *.adityatelange.in, http://*.adityatelange.in:8080.

How do we define a good starter CSP Policy?

• A good starting point for CSP policy is to define the scope of the policy.
• Listing out the domains and subdomains which are necessary to make the application function is necessary.
• The types of content which should be allowed to be loaded should be noted.
• It is a good idea to include a default-src directive.
• The security implications should be thought about such as unsafe-inline and unsafe-eval which are under script-src.
• It’s also important to regularly review and update the CSP to ensure that it does not break the site’s functionality as well as continues to provide adequate protection against security threats.

Scan for Security Headers

🔗 https://securityheaders.com