Working with HTTP Headers


HTTP headers are a core part of how web requests are made, passing additional information along with the request or response. Some HTTP headers, such as Request Method:, Status: and User-Agent: are quite well known although there are many more which are commonly used. In this blog we will focus on the HTTP headers which improve security, offering powerful protection against common exploits such as cross-site scripting (XSS) and man in the middle (MiTM) attacks. These will now be detailed below:

HTTP Strict Transport Security (HSTS)

This header instructs the browser to access the web server only by using HTTPS. Once this security header is configured on the server, it sends this header in HTTP response back to the browser as `Strict-Transport-Security`. After a browser receives this header, all the requests to that server are only sent over HTTPS.

Example: Strict-Transport-Security: max-age=31536000; includeSubDomains


Max-age: This directive sets the time for which the web server should be accessed only through HTTPS. The default value of this directive is 3153600 seconds. This specifies the maximum time for which this header is valid. The server prevents this time from expiring by updating it with every new request.

Syntax: Strict-Transport-Security: max-age=<expire-time>

IncludeSubDomains: This directive helps in providing control over the subdomains of the website.

Syntax: Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

Preload: Preload directive specifies the list of the websites hardcoded into Google Chrome browser. This website can be set to communicate over HTTPS only.

Syntax: Strict-Transport-Security: max-age=<expire-time>; preload

Security implications:

An attacker can perform a Man in The Middle (MiTM) attack and gain access to sensitive user data like cookies and sessions.

Content Security Policy (CSP)

CSP uses whitelisting approach to instruct the browser from where to load the scripts, styles, applets and images. Once this security header is configured on the server, it sends this header in HTTP response back to the browser as ` Content-Security-Policy`.

Example: Content-Security-Policy: default-src ‘self’; img-src *; media-src; script-src


default-src: Specifies where should everything be loaded from.

Syntax: Content-Security-Policy: default-src ‘self’

media-src: Specified where the media should be loaded from.

Syntax: Content-Security-Policy: media-src

script-src: Specifies where the scripts should be loaded from.

Syntax: Content-Security-Policy: script-src

img-src: Specified where the images should be loaded from. The example value of this directive could be `*`.

Syntax: Content-Security-Policy: img-src *

Security Implication:

Correct implementation of CSP reduces the chances of exploitation by Cross-Site Scripting (XSS), ClickJacking and HTML injection attacks.


This is a Cross-Origin Resource Sharing header (CORS). This header allows the third party access to the resources. It is a workaround for the restrictions set by the Same Origin Policy. Once this security header is configured on the server, it sends this header in HTTP response back to the browser as `Access-Control-Allow-Origin`.

Example: Access-Control-Allow-Origin: null


`*`: Allows access to the resource from any origin.

Syntax: Access-Control-Allow-Origin: *

`<origin>`: Allows access from a specific origin.

Syntax: Access-Control-Allow-Origin: <origin>

`null`: Specifies the origin to be null. It should not be used. For further details, please view (

Syntax: Access-Control-Allow-Origin: null

Security Implication:

In an incorrect implementation of Access-Control-Allow-Origin could allow an attacker to read the data from the target website by using another third-party website. If a wildcard is used for this header it will allow any website to read data.


The cookie values set by the application are sent by the server in the `Set-Cookie` header. Once the browser receives this header, it will send cookies with every HTTP request in the `Cookie` header.

Example: Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly


`<cookie-name>=<cookie value>`: The value starts with the cookie name and value pair.

Syntax: Set-Cookie: <cookie-name>=<cookie-value>

`Expires=<expiry date>`: Specifies the maximum lifetime of the cookie.

Syntax: Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

`Max-Age=<number of seconds>`: The number of seconds until the cookie expires.

Syntax: Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>

`Domain=<domain value>`: Specifies the host to which the cookies will be sent.

Syntax: Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>

`Path=<path value>`: It indicates the URL path that is required to exist in the requested resource before sending the cookie header. 

Syntax: Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>

`Secure`: A cookie that is set with this attribute will not be sent over clear-text HTTP protocol. It will only be sent our encrypted HTTPS protocol.

Syntax: Set-Cookie: <cookie-name>=<cookie-value>; Secure

`HTTPOnly`: This attribute instructs the browser to not permit JavaScript code to access the contents of the cookies. This can help in the mitigation of session hijacking attacks.

Syntax: Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Security Implication:

The absence of this header can allow an attacker to gain access to cookie values and perform session hijacking attacks. HTTP cookies often contain sensitive information about user’s session and they should be protected against unauthorised access.


This header is used to instruct the browser to not load the page in frames (<frame>, <iframe>, <embed> or <object>). X-FrameOptions header can help in protecting user against ClickJacking attacks.

Example: X-Frame-Options: sameorigin


`DENY`: This will not allow the page to be loaded in an iframe by any other website.

Syntax: X-Frame-Options: deny

`sameorigin`: This will allow the page to be loaded in an iframe only if the origin is the website is the same.

Syntax: X-Frame-Options: sameorigin

`allow-from`: This will allow the page to be loaded in an iframe by specific domains.

Syntax: X-Frame-Options: allow-from

Security Implication:

An attacker can load a target application into an invisible iframe of a malicious website. When a user of a target website clicks on the malicious website the clicks will be stolen and sent to the target website (ClickJacking).


This HTTP header helps in protecting against Cross-Site Scripting attacks. It is a feature of Internet Explorer and also works with the XSS filters used by modern browsers. Although it is largely unnecessary in modern browsers when a web application implements a strong Content Security Policy.

Example: X-XSS-Protection: 1; mode=block


` 0`: The value of 0 will disable the XSS filter.

Syntax: X-XSS-Protection: 0

` 1 `: The value of 1 will enable the XSS filter. In this case, the XSS attack will be detected and the content will be sanitized to block content.

Syntax: X-XSS-Protection: 1

` 1; mode=block`: The value of 1 with block mode will stop the page from rendering if an XSS attack is detected.

Syntax: X-XSS-Protection: 1; mode=block


The HTTP header is used to protect against MIME sniffing vulnerabilities. The MIME sniffing is the feature of the web browsers to analyse the content of the file being served.

Example: X-Content-Type-Options: nosniff


`nosniff`: It blocks the request if the request type is script or style.

Security Implication:

An attacker can exploit this vulnerability by uploading a legitimate file type containing malicious code. This code can then execute in the browser, potentially compromising the application. “