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.  

Table of contents
  1. Security Headers Security Assessment Level
  2. What are Security headers?
  3. How Security Headers Can Prevent Vulnerabilities
  4. How to Enable Security Headers
  5. Webserver Configuration (Apache, Nginx, and HSTS)
  6. HTTP Strict Transport Security (HSTS)
  7. X-Frame-Options
  8. X-XXS-Protection
  9. X-Content-Type-Options
  10. Same-Site Cookie
  11. Content-Security-Policy
  12. Referrer-Policy
  13. Cache-Control
  14. Access-Control-Allow-Origin
  15. Use a scanner tool to prevent the attacks

Security Headers Security Assessment Level

Security Assessment Increase TLS Key Size

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:

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:

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:

Scan Your Security Headers and Prevent Attacks

SCAN FOR FREE NOW

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:

ValueEffect
denyDo not allow frames of this site
sameoriginAllow frames of this site when the domain matches
allow-from DOMAINAllow 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.

ValueEffect
0Disable the filter
1Enable the filter to sanitize the webpage in case of an attack
1; mode=blockEnable 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.

ValueEffect
nosniffOnly 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.

ValueEffect
NoneThe cookie will be sent in all contexts.
LaxThe 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.
StrictPrevent the cookie from being sent to the target site in all cross-site requests, even when following a link into 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.

ValueEffect
default-scr ‘self’ resources.example.orgDefine loading all resource types from the own domain and resources.example.org
script-src ‘self’ scripts.example.orgEnable 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.orgEnable loading stylesheets from the own domain and style.example.org
img-src ‘self’ imgs.example.orgEnable loading images from the own domain and imgs.example.org
media-scr ‘self’ media.example.orgEnable 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.orgEnable loading fonts from the own domain and fonts.example.org
connect-src ‘self’ api.example.orgEnable 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
sandboxEnables 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-contentPrevents browser to load mixed content (such as HTTP and https mixed elements)
upgrade-insecure-requestsDownload 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.

ValueEffect
no-referrerDo not include any referrer information on requests
no-referrer-when-downgradeDo not send the referrer when the actual connection is an https request and the new request is HTTP
originSend the origin as referrer but do not include any path information
origin-when-cross-originSend the origin as the referrer when the new request is on another domain and all information for same-origin cases
same-originSend the referrer only when the request stays in the current domain
strict-originSend the origin as the referrer, but only when the request is no downgrade from https to HTTP
strict-origin-when-cross-originSend 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-urlAlways 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.

ValueEffect
must-revalidateThe cache must revalidate the state of the resource before using it
no-cacheSend the request even if the cache has stored the resource
no-storeDo not store the resource in any cache
no-transformDo not transform the resource (e.g. change the image format to store cache space)
publicAllow storing the resource in any cache
privateAllow to store the resource in a user-specific cache, but not a shared cache
proxy-revalidateSame 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.org

If 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.

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 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.

See if Your Web App or API Has Security Vulnerabilities

SCAN FOR FREE NOW