Security headers can address a number of cyber threats. Also known as security-related HTTP response headers, they modify the behavior of web browsers to avoid security vulnerabilities.
While their use comes with some strings attached in terms of browser features, security headers can be of great help in preventing many kinds of common attacks, including Cross-Site Scripting and Clickjacking. In addition, they can provide an additional layer of security for your web applications.
Let’s dig into the possible vulnerabilities and the methods for enabling security headers in modern browsers.
Security Headers Security Assessment Level
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
What are Security headers?
They are directives to increase the protection and create more defense against vulnerabilities using browsers. For example, they modify the behavior of web browsers to avoid security vulnerabilities just to accept one kind of valid server certificate like TLS.
Types of security headers include:
- HTTP Strict Transport Security (HSTS)
- Content Security Policy (CSP)
- HTTP Public Key Pinning (HPKP)
How Security Headers Can Prevent Vulnerabilities
Inserting a security header can prevent a variety of hacking attempts.
You can refer to OWASP Secure Headers Project for the top HTTP response headers that provide security and usability.
Here are some of the vulnerabilities you can avoid by using a security header:
- Protocol downgrade attacks like Poodle
- Content Injection attacks like XSS and Clickjacking
- Reflected XSS attack
- Cross-Site Request Forgery attack
- Cross-Site Scripting attack
Before you apply a security-related HTTP response header for attack prevention, make sure to check whether it’s compatible with the browsers you’re targeting.
How to Enable Security Headers
To correctly set the security headers for your web application, you can use the following guides:
- Webserver Configuration (Apache, Nginx, and HSTS)
- X-Frame-Options
- X-XSS-Protection
- X-Content-Type-Options
- Same-Site Cookie
- Content-Security-Policy
- Referrer-Policy
- Cache-Control
- Access-Control-Allow-Origin
Webserver Configuration (Apache, Nginx, and HSTS)
To configure your webserver, you can apply the settings described below — for Apache, Nginx, and HTTP Strict Transport Security (HSTS).
Apache Security headers
For Apache, you’ll need to update your configuration to include the correct header directives.
Add this to the virtual host configuration in /etc/apache2/sites-enabled/domain.conf or /etc/httpd/sites-enabled/domain.conf:
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=31536000"
Header always set X-Frame-Options "deny"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self'"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</VirtualHost>Nginx Security headers
For nginx, you’ll have to update the configuration file. It’s usually located at /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/yoursite.com (Ubuntu / Debian) or /etc/nginx/conf.d/nginx.conf (RHEL / CentOS).
Include the following header with the add_header directives:
server {
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;" always;
add_header X-Frame-Options "deny" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
HTTP Strict Transport Security (HSTS)
The HSTS header enforces HTTPS connections. This prevents downgrade attacks that can affect an insecure HTTP connection. You can review our How to Enable HSTS guide for the correct settings.
X-Frame-Options
The X-Frame-Options response header sets whether a website can be embedded as a frame into other websites.
The header values are:
| Value | Effect |
| deny | Do not allow frames of this site |
| sameorigin | Allow frames of this site when the domain matches |
| allow-from DOMAIN | Allow frames of this site when embedded in webpages on DOMAIN |
Setting the X-Frame-Options HTTP header to deny will protect the website against clickjacking attacks. This will prevent an attacker from overlaying the web page’s iframe with arbitrary content to bait victims into clicking on certain links.
X-XXS-Protection
Some web browsers are equipped with a Cross-Site-Scripting (XSS) filter. It can detect and protect against certain XSS attacks. To configure the browser filter, use the X-XSS-Protection header.
| Value | Effect |
| 0 | Disable the filter |
| 1 | Enable the filter to sanitize the webpage in case of an attack |
| 1; mode=block | Enable the filter to block the webpage in case of an attack |
Setting this header 1; mode=block instructs the browser not to render the webpage in case an attack is detected.
X-Content-Type-Options
Browsers try to detect the MIME-type of the files that the webserver sends.
If an attacker uploads a malicious executable file to a webserver that only sends images, the MIME-type identification can provide some protection. It informs the browser it should expect an image and not an executable file. As a result, the browser shouldn’t try to detect the MIME-type but should only use the MIME-type provided by the webserver.
You can enable this by using the X-Content-Type-Options header and setting it to nosniff.
| Value | Effect |
| nosniff | Only use the declared MIME-type |
Same-Site Cookie
Setting a cookie flag prevents cross-site information leakage and can help mitigate Cross-Site Request Forgery attacks.
You can use the same-site cookie flag to restrict the browser from sending cookies along with cross-site requests. Possible values are Strict, Lax, or None.
If the same-site cookie flag is set to None, the secure flag must be set to prevent sending the cookie in an insecure context.
| Value | Effect |
| None | The cookie will be sent in all contexts. |
| Lax | The cookie is sent when a user follows a link to your site. But the cookie is not sent when the content of your site is included in a third-party site. |
| Strict | Prevent the cookie from being sent to the target site in all cross-site requests, even when following a link to your site. |
Content-Security-Policy
By setting the Content-Security-Policy header, you can instruct the web browser on the domains from which it can load further resources, such as scripts, images, or stylesheets.
This can prevent various Cross-Site-Scripting (XSS) and other Cross-Site-Injection attacks. The policy of the Content-Security-Policy HTTP header needs to be tweaked for particular use because it may easily stop analytic scripts, fonts, or other resources loaded from a third party.
| Value | Effect |
| default-scr ‘self’ resources.example.org | Define loading all resource types from the own domain and resources.example.org |
| script-src ‘self’ scripts.example.org | Enable loading scripts from the own domain and scripts.example.org |
| object-src ‘none’ | Disallow loading of all objects such as <applet>, <embed> and <object> |
| style-src ‘self’ style.example.org | Enable loading stylesheets from the own domain and style.example.org |
| img-src ‘self’ imgs.example.org | Enable loading images from the own domain and imgs.example.org |
| media-scr ‘self’ media.example.org | Enable loading media elements from the own domain and media.example.org |
| child-src ‘self’ | Define that in <frame> and <iframe> elements only pages from the own domain may be loaded |
| font-src ‘self’ fonts.example.org | Enable loading fonts from the own domain and fonts.example.org |
| connect-src ‘self’ api.example.org | Enable connections via script interfaces such as XMLHttpRequest or WebSocket to the own domain and api.example.org |
| manifest-src ‘self’ | Enable loading manifests from the own domain |
| frame-ancestors ‘self’ | Define that this page may only be used as a frame on pages of the own domain |
| form-action ‘self’ | Ensures that form actions can only be of the own domain |
| sandbox | Enables a sandbox that blocks most actions on the page. More Information: CSP: sandbox |
| plugin-types application/x-java-applet | Allows embedding an <applet>. This only works if object-src is not set to ‘none’ |
| block-all-mixed-content | Prevents browser to load mixed content (such as HTTP and https mixed elements) |
| upgrade-insecure-requests | Download all resources via an https connection |
A straightforward policy can be default-src ‘self’. However, make sure to test your configuration thoroughly to don’t block your analytics script or other third-party resources.
Referrer-Policy
The Referrer-Policy header defines how much information about the referrer is sent when the user clicks on a link.
The referrer may leak sensitive information, such as user-specific URLs. You can set the referrer-policy might to a more restrictive value.
A relatively secure setting is strict-origin-when-cross-origin.
| Value | Effect |
| no-referrer | Do not include any referrer information on requests |
| no-referrer-when-downgrade | Do not send the referrer when the actual connection is an https request and the new request is HTTP |
| origin | Send the origin as referrer but do not include any path information |
| origin-when-cross-origin | Send the origin as the referrer when the new request is on another domain and all information for same-origin cases |
| same-origin | Send the referrer only when the request stays in the current domain |
| strict-origin | Send the origin as the referrer, but only when the request is no downgrade from https to HTTP |
| strict-origin-when-cross-origin | Send the origin as the referrer to cross-origin requests and the full referrer on same-origin requests but only when the request is no downgrade |
| unsafe-url | Always send the full URL as the referrer |
Cache-Control
With the Cache-Control header, you can control the configuration of the caching in the browser.
Depending on the header’s value, the browser may cache the website, including any sensitive information. Therefore, for pages where confidentiality is an issue, it’s best to set the header to no-store.
| Value | Effect |
| must-revalidate | The cache must revalidate the state of the resource before using it |
| no-cache | Send the request even if the cache has stored the resource |
| no-store | Do not store the resource in any cache |
| no-transform | Do not transform the resource (e.g. change the image format to store cache space) |
| public | Allow storing the resource in any cache |
| private | Allow to store the resource in a user-specific cache, but not a shared cache |
| proxy-revalidate | Same as must-revalidate for shared caches |
| max-age=<seconds> | Configure the time for which the resource will be treated as fresh |
| s-maxage=<seconds> | Overwrite a max-age or Expires header, but is only used for shared caches |
Access-Control-Allow-Origin
The Access-Control-Allow-Origin Header defines which applications can use your API.
Set it to the domain of your frontend, such as:
Access-Control-Allow-Origin: https://example.orgIf you have multiple applications using your API, you can consult our resource on Multiple Values Access-Control-Allow-Origin.
Need stronger application security? You can check out Crashtest Security’s Vulnerability Testing Software to identify cybersecurity weaknesses and various types of attacks on your applications.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
Use a scanner tool to prevent the attacks
Another way to prevent different attacks is using an automated vulnerability scanner that continuously tests your website.
- You get a report with all the security headers you need to fix
- Discover new cybersecurity weaknesses that make you exposed to attacks such as the OWASP 10 list risks.
- Get access to an exclusive wiki with articles about remediation and prevention for your website as well.
For businesses, this is important, as nowadays, having the correct settings to avoid attacks is not easy. It takes time from developers and the company’s budget. Try this new vulnerability testing software to keep your and your customer’s data in an easy and budget-friendly way.
