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 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.

🔗 https://securityheaders.com