Securing your Web Application with HTTP Headers — Best Practices🛡️
The following article will cover some basics around web application security along with providing a good understanding to things that should be taken in mind (such as security headers and analyzing protection level) when having an already running or about to be deployed web application from a security perspective.
As i’m pretty sure this topic is not on everyone’s day-to-day routine, I will over-elaborate in this post along with providing knowledge tools that will let you avoid security threats.
💬 In any case — If you have more questions feel free to contact/comment.
Security Analysis
A web application security state can be analyzed manually or using some tools. I do want to recommend a few resources that I find helpful for quick understanding.
- https://securityheaders.com — Provides an easy-to-understand web analysis along with reporting for CSP and other security headers.
- OWASP’s main page and more specifically Secure Headers resource. (OWASP is the Open Web Application Security Project which is an online community that leads the field of web application security).
- KeyCDN blog article — covers HTTP security headers.
- Mozilla’s HTTP Docs — security headers and descriptive explanations.
What is a security header?
First, let’s dive into what exactly security headers are. OWASP defines them as:
“The OWASP Secure Headers Project describes HTTP response headers that your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities. The OWASP Secure Headers Project intends to raise awareness and use of these headers.”
In other words, it’s a contract (defined by HTTP response headers that set the level of our website’s security) between the developer and the browser.
Why is it important?
Client-side vulnerabilities have become a common target of attacks. Financial organizations must keep up by assessing their exposure to threats.
To read more about the different threats — see the Security Threats section.
Case Study
In the last several months I was part of a task force that developed a new web application. Before it is going live to production it was important to review all security aspects to make sure not only we do not downgrade our security state, but also improve it.
All the next analysis were reported by securityheaders.com:
First, I analyzed our current (already running) web application in production:

Second, I made a report analysis for the about-to-be-deployed new application:

And over our production DNS:

Looking at the results, though both reports shows a low score of D, there’s also some gap between what was applied for the different security headers per application:
- X-Frame-Options + X-Content-Type-Options applied in the 1st report.
- Only Strict-Transport-Security is applied in the 2nd report.
The approach I wanted to go through from here is understanding each security header (either marked in red, or in green) and making sure it is being set with the most recommended value that fits our needs. Generally, it’s always worth harden your settings unless you have a specific use case preventing you from doing so.
Security Headers Applied
Note, the final configurations applied for the new web application are placed in a one column table, each table content consists of both the header name and its value. For example: Header-Name=”Value”
1. X-Frame-Options (read more)
The X-Frame-Options header (RFC), or XFO header, protects your visitors against clickjacking attacks. An attacker can load up an iframe on their site and set your site as the source, it’s quite easy.
X-Frame-Options = ”SAMEORIGIN”Previous state for the production application was also set to “SAMEORIGIN”
SAMEORIGIN = The page can only be displayed in a frame on the same origin as the page itself. The spec leaves it up to browser vendors to decide whether this option applies to the top level, the parent, or the whole chain.
2. X-XSS-Protection (read more)
This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header are 0, which disables the protection, 1 which enables the protection and 1; mode=block which tells the browser to block the response if it detects an attack rather than sanitizing the script.
X-XSS-Protection = “1; mode=block”Previous state for the production application was also set to “1; mode=block”
1; mode=block = Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
3. Referrer-Policy (read more)
The Referrer-Policy HTTP header controls how much referrer information (sent via the Referrer header) should be included with requests.
Referrer-Policy = “no-referrer-when-downgrade”Previous state — we did not have this header.
no-referrer-when-downgrade (default) = This is the default behavior if no policy is specified, or if the provided value is invalid. The URL is sent as a referrer when the protocol security level stays the same (HTTP→HTTP, HTTPS→HTTPS), or improves (HTTP→HTTPS), but isn’t sent to less secure destinations (HTTPS→HTTP).
4. X-Content-Type-Options (read more)
The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.
X-Content-Type-Options = “nosniff”Previous state — “nosniff”
nosniff = Blocks a request if the request destination is of type:
- “style” and the MIME type is not text/css, or
- “script” and the MIME type is not a JavaScript MIME type
5. Feature-Policy (read more)
The HTTP Feature-Policy header provides a mechanism to allow and deny the use of browser features in its own frame, and in content within any <iframe> elements in the document.
Feature-Policy = “fullscreen ‘self’; geolocation ‘self’; notifications ‘self’;”Previous state — we did not have this header.
“fullscreen ‘self’; geolocation ‘self’; notifications ‘self’;” = describes allows permissions for features ‘fullscreen, geolocation, notifications’ only for ‘self’ while self means the feature is allowed by default in top-level browsing contexts and in nested browsing contexts (iframes) in the same origin.
6. Content-Security-Policy
This header was not handled as it requires better understanding for all third parties running in our page, after spiking this, we could list them and allow each one if we want.
Now that we have the above headers set in place, let’s analyze our site’s security again!

Looks nice isn’t it? 😊
Deployment for Configurations
Previous section describes the following settings that should be set via our server’s configuration:
X-Frame-Options = “SAMEORIGIN”X-XSS-Protection = “1; mode=block”Referrer-Policy = “no-referrer-when-downgrade”X-Content-Type-Options = “nosniff”Feature-Policy = “fullscreen ‘self’; geolocation ‘self’;”
In our case, we use Netlify, so the deployment of the above configuration takes place in one of the following ways:
- Netlify allows you to add security headers by adding a
_headersfile to the root of your website’s deployed folder. If you are using a static site, this file should go right next to yourindex.htmlfile. If you are using a framework like React, the file should go in the/publicfolder. - You can instead create a
netlify.tomlfile in the root of your github repository. The contents of that file will need to be slightly different than above.
We used option #2.
Anyhow, you can read more about Netlify header configuration here — https://www.netlify.com/docs/headers-and-basic-auth/
See also another reference about the Netlify configuration options.
ℹ️ Security Threats
1.Cross-site scripting (XSS)
One of the most popular forms of cyber attack. This attack consists of injection of a malicious code into our application and then executing it by the user browser.
This kind of attack allows to embed on the page both JavaScript programs and embedded objects such as for example Flash apps (ActionScript), Java applets, ActiveX controls or even plain simple HTML code which allows conducting CSRF attack.
2.UI Redressing
The purpose of the attack is to force the user to execute a specific action on the infected application. The attack is done through changes in the interface or behavior of the application.
3.Cross-site request forgery (CSRF/XSRF)
This is a special type of attack, unlike the others, it is directly targeting user’s browser, not the web application itself. It consists in forcing the browser to make a false request (generated by the attacker), to a vulnerable application to perform a specific action on it, such as registering a new account, removal of certain resources or in the case of electronic banking system applications — transfer money to the attacker account. Typically, this type of attack is based on the assumption that during it the victim will be logged on to his account and will, therefore, have the rights to allow the browser to call the malicious request.
4.Network eavesdropping and man-in-the-middle (MitM)
Eavesdropping — As its name suggest this attack involves listening of unsecured network traffic between victims computer and the web application, for example in a situation when the victim is using a public wireless network.
Man-in-the-middle — MitM attacks take a similar form, but unlike the previous one, the attacker is able to modify the transmitted data as the network traffic passes through the controlled by him the portion of the network.
5.HTTPS (SSL/TLS)
HTTPS is an encrypted variant of the HTTP protocol for sending hypertext documents, where all communication takes place by using lower cryptographic protocols such as SSL and TLS.
6.Same-origin Policy (SOP)
It is the core security model used in web browsers, which enforce restrictions for the JavaScript-based applications. It says that the given script is only allowed to get access to only this resources which are under the same execution context, i.e. they have the same origin.
7.Content Security Policy
It is a tool designed to prevent code injection attacks, mainly XSS. We use it to tell the browser which resources it can load and what scripts it can execute (whitelist mechanism).
8.Cross-origin resource sharing (CORS)
CORS is a mechanism that is part of the W3C specification, whose main intention is to make it possible to specify which sites from a different domain can use our resources.
9.Securing Cookies
The HTTP cookie is a small piece of information (up to 4096 bytes) that is sent between the client and the server.
10.Web (DOM) Storage security
Unlike cookies data held in Web Storage is encrypted by browsers running on certain system platforms. This makes it more difficult to get physical access to them, but it does not prevent it completely since there are available tools used to read them.
If you liked the article, please click the 👏💚 below so other people will see it on Medium!
