
This article will explain HTTP security headers, recommended best practices, and how to enable HTTP security headers to secure your website from vulnerabilities.
HTTP security headers are the necessary part of website security that allows your server to prevent web vulnerabilities like XSS, Clickjacking, Cross-Site Scripting attacks, and many other known threats before they impact your website.
Using HTTP security headers to avoid web vulnerabilities
HTTP security headers are directives used by web applications to make security protections in web browsers. They are also used to configure the web browser to allow valid TLS communication only and enforce valid certificates or even enforce using a specific server certificate.
Overview of the web vulnerabilities to avoid by using HTTP security headers
The list of web vulnerabilities that you can avoid by using HTTP security headers include the following:
- Content injection or content spoofing attacks
- Clickjacking attacks
- Cross-Site Scripting (XSS) attacks
- Protocol downgrade attacks like Padding Oracle on Downgraded Legacy Encryption (POODLE) attacks
- Cross-Site Request Forgery (CSRF) attacks
- Reflected Cross-Site Scripting (XSS) attacks
Content injection or content spoofing attacks
Content spoofing attacks, also known as content injection attacks, are when the website visitor for the web application is able to modify the contents of the web page.
This type of attack will happen when the web application is unable to handle data supplied by the end-user. The attackers inject malicious text or HTML content via a parameter value into a legitimate website, which is then reflected in the webpage.
Clickjacking attacks
Clickjacking or UI redressing is an interface-based attack that tricks website visitors into clicking a webpage element that is invisible as another page or HTML element. The invisible page could be a malicious or legitimate page the visitor did not wish to visit. The attackers insert their malicious links into legitimate pages or links or buttons on a website. If the website visitor clicks on these links or buttons, the attackers will get access to the confidential information of that visitor. This attack is commonly performed by hiding the target website’s UI and arranging the visible UI so that the visitors aren’t aware of clicking the target website.
Cross-Site Scripting (XSS) attacks
Cross-Site Scripting (XSS) is an attack that allows an attacker to inject malicious executable scripts into the code of a trusted web application or website. This type of attack will occur if the web application or website does not employ enough validation or encoding. The attackers frequently initiate XSS attacks by sending malicious links to a user and attracting the user to click them.
Protocol downgrade attacks like Padding Oracle on Downgraded Legacy Encryption (POODLE) attacks
The attacker will then force your web browser to downgrade the server’s security protocol to SSL 3.0 from TLS 1.0 to steal sensitive data, such as passwords, session cookies, or other authentication tokens that help them to impersonate a user and gain access to a website.
Cross-Site Request Forgery (CSRF) attacks
The Cross-Site Request Forgery (CSRF) attack forces an authenticated user to execute unwanted actions or submit a request on a web application or website where they’re currently authenticated. In a CSRF attack, an attacker uses social engineering techniques to handle an authenticated user into performing malicious actions without their awareness or consent. By simply clicking on a suspicious link in an email or chat message, the website user may accidentally give an attacker the ability to operate their identity and access privileges.
Reflected Cross-Site Scripting (XSS) attacks
Attacks that use a malicious script that is reflected from a web application to the victim’s browser are known as reflected XSS attacks or non-persistent attacks. A link that sends a request to a website with a vulnerability that allows the execution of malicious scripts activates the script.
A guide to preventing website vulnerabilities by using HTTP security headers
When a user visits a website in the browser, the browser sends some request headers to the server, which then responds with the content along with HTTP response headers. These HTTP response headers are used by the client and server to share information as a part of the HTTP protocol.
Some HTTP response headers contain content metadata such as Content-Encoding, status codes, Cache-Control, etc. Along with the HTTP response headers, there are also HTTP security headers that tell the browser how to behave during communication with the site. Browsers have defined the behavior of the web page according to the HTTP response headers during communication with the server.
The recommended HTTP security headers are as follows:
- HTTP Strict Transport Security (HSTS – Strict-Transport-Security)
- Cross-Site Scripting Protection (X-XSS-Protection)
- Website IFrame Protection (X-Frame-Options)
- Preventing Content-Type Sniffing (X-Content-Type-Options)
- Content Security Policy (CSP – Content-Security-Policy)
- Referrer-Policy
- Permissions-Policy
HTTP Strict Transport Security (HSTS – Strict-Transport-Security)
HTTP Strict Transport Security (HSTS) header is a security enhancement that configures the web browser to always use a valid secure connection (HTTPS) with the web application. This ensures the connection cannot be established through an insecure HTTP connection which could allow cybersecurity attacks like Man-in-the-middle attacks, Session Hijacking, etc.
If the server TLS certificate becomes expired or untrusted, the web browser will no longer connect to the web application. Also, if the user tries to access the web application using an HTTP:// URL, the web browser will automatically change it to HTTPS://. This will help us to prevent cybersecurity attacks.
You will need to ensure all your website pages are accessible over HTTPS before implementing the HSTS header. Otherwise, they will be blocked. Currently, all major web browsers support HTTP strict transport security.
You can implement HTTP Strict Transport Security (HSTS) in Apache by adding the following entry in the Apache configuration file:
Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” env=HTTPS
For Nginx, you can add the following entry in the Nginx configuration file to implement HTTP Strict Transport Security (HSTS):
add_header Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload;’ always;
Cross-Site Scripting Protection (X-XSS-Protection)
Cross-Site Scripting Protection (X-XSS) header helps to protect your websites against Cross-Site Scripting or script injection attacks. When the hacker inserts malicious JavaScript code into an HTTP request to access confidential information such as session cookies, the X-XSS Protection header allows you to block cross-site scripting from loading on your website when they detect reflected Cross-Site Scripting (XSS) attacks. The X-XSS Protection header (filter) is enabled by default in popular web browsers such as Chrome, Safari, etc.
The available options to implement Cross-Site Scripting Protection (XSS protection) are as follows. You can use it as per your requirement:
- X-XSS-Protection: 0 — To disable Cross-Site Scripting Protection.
- X-XSS-Protection: 1 — To enable Cross-Site Scripting Protection and remove the unsafe part.
- X-XSS-Protection: 1; mode=block — To enable Cross-Site Scripting Protection and prevent the entire page from rendering when a Cross-Site Scripting (XSS) attack is detected.
You can implement Cross-Site Scripting Protection (X-XSS-Protection) in Apache by adding the following entry in the Apache configuration file:
Header set X-XSS-Protection “1; mode=block”
For Nginx, you can add the following entry in the Nginx configuration file to implement Cross-Site Scripting Protection (X-XSS-Protection):
add_header X-XSS-Protection “1; mode=block”;
Mohammed Noufal