There are several types of HTTP headers (Request, Response, Entity etc..) but to avoid some of the most common malicious attacks I am going to cover few response headers here.

Remove these response headers,


They give information about the application server and the software being used, you don’t want to expose this information to hackers who might want to look for disclosed vulnerabilities and hack your business before you fix the problem.

I have seen a well known bank disclosing these recently,


Stop clickjacking attacks using,


The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

Test if your website is susceptible to clickjacking,

Expected Result : If you can see both the text “This Website is vulnerable to clickjacking!” at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks.

This page -> is not protected against clickjacking


Resultant Page –


This page – is not susceptible to clickjacking


Resultant Page –


Google has set the X-Frame-Options header..


Header Syntax

There are three possible directives for X-Frame-Options:

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM


If you specify DENY, not only will attempts to load the page in a frame fail when loaded from other sites, attempts to do so will fail when loaded from the same site. On the other hand, if you specify SAMEORIGIN, you can still use the page in a frame as long as the site including it in a frame is the same as the one serving the page.

    The page cannot be displayed in a frame, regardless of the site attempting to do so.


    The page can only be displayed in a frame on the same origin as the page itself.


    The page can only be displayed in a frame on the specified origin.

Further very good read and how to configure this in apache, nginx, IIS etc.

Stop Cross-site scripting attacks,


Cross-site scripting attacks occur when one website, generally malicious, injects (adds) JavaScript code into otherwise legitimate requests to another website.

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript (‘unsafe-inline’), they can still provide protections for users of older web browsers that don’t yet support CSP.

Header Syntax

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

    Disables XSS filtering.
    Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).


    Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.

1; report=<reporting-URI>  (Chromium only)

    Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.

Example for google,



Further good read and how to block –

Recommended reading –