Working with HTTP Headers

HTTP Headers Image
Share on facebook
Share on twitter
Share on pinterest

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)

Arguably one of the most important HTTP Headers – 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.

Strict-Transport-Security: max-age=

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

Syntax: Strict-Transport-Security: max-age=;

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=; preload


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 is a HTTP Header which 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

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

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


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:


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

Syntax: Access-Control-Allow-Origin: *

“: Allows access from a specific origin.

Syntax: Access-Control-Allow-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.


A HTTP header which affects the cookie values the application sets can be controlled by 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: =; Domain=;
Secure; HttpOnly


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

Syntax: Set-Cookie: =

`Expires=`: Specifies the maximum lifetime
of the cookie.

Syntax: Set-Cookie: =;

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

Syntax: Set-Cookie: =;

`Domain=`: Specifies the host to which
the cookies will be sent.

Syntax: Set-Cookie: =;

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

Syntax: Set-Cookie: =;

`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

Syntax: Set-Cookie: =; 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: =; 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 (, &ltiframe>, or ).
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


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

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.


The latest cyber security news

Enter your email below to be notified when a new article is released.

Share this post with your colleagues

Share on linkedin
Share on facebook
Share on twitter

This website uses cookies to ensure you get the best experience on our website.