Posted on May 15, 2021

Server Response Headers to Protect Your Website from Hackers

Developers that build web applications know that many factors go into protecting a site from hackers. Whitelisting input, ensuring proper authentication features, and building frontend and backend code that checks for certain attacks are just a few ways developers can protect web applications, but using web server headers are also an effective way of protecting from cross-site scripting (XSS), man-in-the-middle (MitM) attacks and clickjacking.

X-Content-Type-Options: Nosniff

Some web browsers (mainly Internet Explorer and Chrome) analyze the content of a web page and use the detected asset type of an object to render it on the user’s desktop. This phenomenon is called MIME (Multipurpose Internet Mail Extensions) sniffing. The intention is to read and render web page assets even if the developer has incorrectly labeled them, but it can be a cybersecurity risk and leave your web pages vulnerable to cross-site scripting (XSS) attacks.

The “X-Content-Type-Options: Nosniff” header is not supported by all browsers, but adding this to the web application’s server response will protect users that work with Chrome or Internet Explorer. The vulnerability exists when the application allows users to upload content that’s then rendered later. Your application might have filters to block certain content types (for instance, it could filter out HTML file uploads), but attackers will test for XSS vulnerabilities by changing a malicious file’s extension (e.g. from HTML to JPG) and upload it. When the browser uses MIME sniffing, the HTML file disguised as a JPG is first downloaded by a user. Then, the browser detects that the content should be rendered as HTML instead of JPG and allows the malicious script to run in the user’s browser.

With the “X-Content-Type-Options: Nosniff” header, the browser will no longer MIME sniff and will render assets based on headers sent by the server.

X-Frame-Options: SAMEORIGIN

This header option is used on sites that have iframe HTML tags. Using this header will stop clickjacking vulnerabilities. With clickjacking, an attacker can trick users by adding an iframe to a malicious web page that loads your application. The attacker uses invisible layers that trick the user into sending commands to the application, but really they are interacting with the attacker’s site.

Clickjacking can trick the user into interacting with the attacker’s invisible layer or an invisible iframe that loads your application content. For instance, clickjacking used to be popular in blackhat online marketing where an attacker would load invisible Facebook like buttons over an application’s buttons. An attacker could have a “Play” button with invisible like buttons over the Play button. Users click “Play,” but they also click “Like” on an attacker’s page.

The infamous Adobe Flash vulnerability that gave an attacker remote control of a user’s machine used clickjacking. The attacker loaded invisible Flash settings buttons over a visible web page. A user would click buttons on the attacker’s web page, but an invisible iframe placed Flash security options over these buttons and users unknowingly changed settings on their local browser, which in turn gave the attacker control of the desktop.

You can avoid this attack by using the “X-Frame-Options: SAMEORIGIN” server header. The SAMEORIGIN directive tells the browser that only your domain can load content into an iframe. This directive is needed if you use iframes on the site, but you have two other options if you want to allow a third party (e.g. another site that you own or an affiliate) to load the site in an iframe or deny iframes altogether.

The following two header directives are also available:

  • X-Frame-Options: DENY – use this option if you want to block all content from loading in an iframe.
  • X-Frame-Options: allow-from – use this option if you want to allow a third-party domain to load your site into an iframe.


Some websites pull content from different resources on separate domains. For instance, you might pull a web font from Google’s cloud servers or store your cached JavaScript files on a cloud server. Requesting content from a cloud server could speed up your website, but browsers have internal security features that manage websites that request content from a third-party source. Cross-Origin Resource Sharing (CORS) is not uncommon for many applications, but leaving your site open to requests from any third-party domain opens it to several vulnerabilities including XSS, cross-site request forgery (CSRF), cookie theft, session hijacking and any vulnerability that requests data from the original site.

CORS is often implemented when a web application calls an API over HTTP(S). As an example, using for your site, and as the domain for the API. makes calls to to retrieve information about a user. sends information from the user’s authentication session to query data about the user from If no CORS header is used, any domain can make calls to and will return the requested data. Without CORS security, an attacker could trick a user into making a request to and send the information to the attacker, which in this scenario gives the attacker private data about the user account.

With the “Access-Control-Allow-Origin” header, can specify which domains can receive data.’s admin would need to set the “Access-Control-Allow-Origin” header to allow to make calls to the API and retrieve data. Note that this header specifies if will send data to, but will still be able to make calls.

A common way that developers perform CORS requests is to use the AJAZ XMLHttpRequest (XHR) object. This object performs a request without requiring a full refresh of the web page. If CORS security is used on, a request using XHR will return an error.

The two header options are commonly used in web applications:

  • Access-Control-Allow-Origin: *  — this setting is not recommended. The asterisk tells the web application that any domain can retrieve data from the target web page.
  • Access-Control-Allow-Origin: – this header tells that the domain “” can retrieve data from the local site.


These three server headers will improve web application cybersecurity. It doesn’t stop every vulnerability from being exploited, but it stops some attack risks from common coding mistakes and bugs. Using these headers, you can stop XSS, CSRF, session hijacking and some attacks that use social engineering and phishing.


Leave a Reply

Your email address will not be published. Required fields are marked *

Trusted by Clients Across All Industries

Don’t take our word for it - let our happy clients do the talking. See More

Full Host did an amazing job of migrating my site seamlessly onto their server. My only regret was not switching my site over to them sooner. Now it is performing great, images are uploading way faster than ever before.

" Vancouver Sofa and Patio - Jerry Schmidt

Two thumbs up for Fullhost! Agents reply to me fairly quickly or at least let me know they received the ticket and are looking into it. Kudos to the support team as they have always given me exactly what I need without delays.

" Universal Staffing Inc. - Anthony Calvano

FullHost is an absolute pleasure to work with, and their customer service is exceptional. Whenever I have questions or need adjustments, they are there to help, quickly, efficiently, with answers and insights.

" Mooseworld Inc. Norine Leibel

With coast to coast coverage,
We help you serve the world.

Whether your audience is located in Europe, Asia, Africa, or Australia, provide them with lightening speed!

FullHost's data centers are located in Toronto and Vancouver to ensure worldwide quality and speed.

Get in Touch
We Trust Only The Best Tech to Support You

FullHost operates with the most innovative technology to bring you unparalleled levels of hosting services.