Your web server security is crucial, and to improve it, you must configure different HTTP headers to make sure that your web-server is more secure from various types of attacks. Without these important headers, your website would be at risk and the attacker may compromise it.
In this article, we will discuss the essential headers that will ensure the protection of our web-server and prevent hackers from attacking our website.
What is HTTP Header
When a user sends a request to a web server, the server responds with specific HTTP headers containing metadata, cache rules, and many more things. A big part of these headers is the security HTTP headers, which are responsible for the behavior of your website.
Here is the list of HTTP header tags, which have great significance in your web-server security:
- HSTS (HTTP Strict Transport Security)
- Content Security Policy
- Access-Control-Allow-Origin
- Set-cookie
- X-Frame Options
- X-XSS Protection
- X-Content Type Option
- Feature Policy
- HPKP (HTTP Public Key Pinning)
- Referring Settings (Referrer-Policy)
- X-Download-Options HTTP Header
- Expect-CT HTTP Header
HSTS (HTTP Strict Transport Security)
Suppose you have just shifted your website from HTTP to HTTPS, thinking that it will improve your website security, but wait, that’s not all. What if still your website is being accessed by using HTTP instead of HTTPS, your problem remains there, Right?
HTTP strict transport security is one of the HTTP security headers which comes into action here, it forces your website to be redirected from HTTP to HTTPS so that your fear of getting attacked by some hacker is eliminated, but if the problem remains there and your user is still accessing through HTTP, then it is easy for the hacker present on the same network to intercept your insecure connection, and your risk of getting attacked is increased.
There are three instructions used within HSTS. Their syntax is given below:
Strict-Transport-Security: max-age=<expire-time> Strict-Transport-Security: max-age=; preload Strict-Transport-Security: max-age=; includeSubDomains
Content Security Policy
Content Security Policy protects from various Cross-Site-Scripting (XSS) attacks that can severely harm your website. When you are using Content Security Policy, you are restricting your website from loading different scripts defined in the policy only such as scripts, CSS, images, etc.
If this policy is utilized correctly, it can help us to prevent other various attacks other than XSS, such as HTML injection or Clickjacking attack.
Four types of instructions (directives) are provided, which you can utilize to make your own Content Security Policy. These are:
- Default-src
- Script-src
- Media-src
- Img-src
Content Security Policy Syntax:
Content-Security-Policy: <policy-directive>;<policy-directive>
Access-Control-Allow-Origin
This header permits a third-party website to access the resource present on your website. To understand how it works, let’s take an example.
Suppose site#1 wants to access a resource present on site#2, then site#2 will use the Access-Control-Allow-Origin header to respond to the request by using site#1 address. You can also create multiple origins utilizing this technique.
Without the correct configuration of Access-Control-Allow-Origin, an attacker may proceed with an attack by using another third-party website.
Access-Control-Allow-Origin: Site1.com
Set-Cookie
The Set-cookie header confirms that your cookies are encrypted via HTTPS. If these cookies are not encrypted, then it could be dangerous for the user as many attacks like MiTM (Man-in-the-middle) attack can be performed by a hacker to steal your cookies.
While using a Set-Cookie header, your website must be on HTTPS, not on HTTP. You must confirm that your cookies are not being stolen with the help of javascript, and this can be done by using the Set-Cookie header.
The Set-Cookie has the following attributes:
Secure: This attribute is used to make sure that your cookies are only encrypted via HTTPS. Otherwise, your cookies will be at risk.
HTTPOnly: The browser will prevent the hacker from using a Javascript code to steal the cookies.
X-Frame Options
One of the HTTP security headers, X-Frame header is very useful to prevent any clickjacking attacks. It merely disables page iframe element to avoid any attacks. The hackers can trick the user with the help of clickjacking invisible frame elements to get legitimate clicks, and this could be a dangerous scenario for the user.
There are three directives available for X-Frame header:
X-Frame-Options: DENY – This will directly disable the page iframe element to minimize the risk of clickjacking.
X-Frame-Options: same-origin – If the origin of the page is identical, then the frame will be enabled according to that origin only.
X-Frame-Options: allow-from URI – This option is used to allow the frame element for a specific URL address of any website.
X-XSS Protection
X-XSS protection header is used to prevent any Cross-Site-Scripting (XSS) attacks. Chrome, Safari, and Internet-explorer have built-in XSS filters. Cross-Site-Scripting attacks could be very severe, and they can harm your website in many ways. The filters used by our browser are of three types:
X-XSS Protection:0 – When the value is set to 0, the XSS filter will be automatically disabled.
X-XSS-Protection: 1 – When the value is set to 1, the XSS filter will be fully enabled, and if any malicious XSS code is detected, the browser will prevent it from execution, and it will clear the page.
X-XSS-Protection: 1; mode=block – The page render will stop upon an attack if the X-XSS is enabled by using value 1 with mode=block.
X-Content-Type-Options
It is utilized to control the MIME sniffing, which is done by the browsers (by default) to check the content which is being uploaded to the server from the user’s side. MIME sniffing is enabled in many browsers like Google Chrome, Internet Explorer, etc.
The problem with MIME sniffing is that it can be dangerous for your website, a hacker can upload a malicious HTML file containing Cross-Site-Scripting malicious codes, and when the browsers sniff this file, the malicious code will be executed on the web-server.
- The attacker will upload content
- The browser will start sniffing it
- Check the file type. It could be HTML
- It executes the malicious code inside HTML
To prevent this scenario, we use X-Content-Type-Options to prevent sniffing by setting it to nosniff. The syntax is given below:
X-Content-Type-Options: nosniff
Feature Policy
Feature policy is used to take control over several web browser features; you can allow or deny any features such as fullscreen, geolocation, speaker, autoplay, USB, speaker, vibrate, payment, microphone, VR, etc.
feature-policy: autoplay 'none'; speaker'none'
HPKP (HTTP Public Key Pinning)
The HPKP is one HTTP security header that checks the public-key-pinning header certificate and tells the browser to trust those certificates. When the browser checks those provided certificates for the very first time, it saves those certificates.
You should not bother using this header because it’s very risky, and it can mess up a lot of things. There is a possibility that you may end up pinning a wrong certificate, or you may lose the key, then it could be a dangerous scenario for you.
Instead of HPKP, you can use Public-Key-Pins-Report-Only header, it is not that risky, and it will lock those with fake certificates.
Referring Settings (Referrer-Policy)
With the help of Referring Settings, you can state that when Referer headers would be used by the browser. This header is not very crucial to use, but it is suggested that you use it. It is a response-type header. It takes control over the referrer information, which is being sent with the requests.
Referrer-Policy: no-referrer Referrer-Policy: no-referrer-when-downgrade Referrer-Policy: origin
X-Download-Options HTTP Header
This option is available in Internet Explorer version 8 or the latest versions. Suppose you download an HTML file from somewhere. When you will open that HTML file with IE 8, the file and the code behind it will be executed in the form of a website, which means that any script will also be executed. These scripts could be malicious codes that can let an attacker perform some unwanted action.
Expect-CT HTTP Header
Expect-CT is one of the HTTP security headers that look for any non-issued certificates can be used to report Certificate Transparency requirements. The Expect-CT header is used to prevent these certificates. Once Expect-CT is enabled, then it will check if these non-issued certificates are in Public logs.
- Certificates are first sent to logs
- These logs are monitored
- After monitoring, auditing is done by browser auditors
The expect-ct header has a form like this:
expect-ct: max-age=604800, enforce, report-uri="https://www.abc.com/report"
Conclusion
Your website security comes first. To give a great experience to your user, your website should be fully secured with fewer loopholes and leaving fewer possibilities for the attacker to attack your website. You can also check for the security headers using this online third-party website here to get more idea about it,
HTTPS headers are a great way to protect your website from a ton of attacks happening nowadays. If you are still not using them, then it’s your mistake. Once you have configured your security headers correctly, it will not only help you to make your website more secure, but your users will be on advantage with it. There will be no need left to spend money on finding and fixing the bugs because of HTTP headers (if used correctly) will minimize all the risk, and you will be less fearful. Setting up these headers and then keeping them updated is enough for your website security. These HTTP header types will surely help you to make the web secure for the user and yourself.
