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 -> https://www.yoursitecanbeclickjacked.co.uk/personal/customer/forgotten-log-in-details is not protected against clickjacking
Resultant Page –
This page – http://www.google.com is not susceptible to clickjacking
Resultant Page –
Google has set the X-Frame-Options header..
There are three possible directives for X-Frame-Options: X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM https://example.com/ Directives 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. DENY The page cannot be displayed in a frame, regardless of the site attempting to do so. SAMEORIGIN The page can only be displayed in a frame on the same origin as the page itself. ALLOW-FROM uri The page can only be displayed in a frame on the specified origin.
Stop Cross-site scripting attacks,
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.
X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report=<reporting-uri> 0 Disables XSS filtering. 1 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). 1;mode=block 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 – https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
Recommended reading – https://www.owasp.org/index.php/About_OWASP