Skip to main content

Enable security headers

Security headers can effectively prevent a variety of hacking attempts. Therefore, you should consider Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, or X-XSS-Protection titles.

Security Assessment


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.

See the 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, check whether it is compatible with the browsers you're targeting.

Prevent attacks

Use the following options to set the correct security headers for your web application:

  • Webserver Configuration (Apache, NGINX)
  • HTTP Strict Transport Security (HSTS)
  • X-Frame-Options
  • X-XXS-Protection
  • X-Content-Type-Options
  • Same-Site Cookie
  • Content-Security-Policy
  • Referrer-Policy
  • Access-Control-Allow-Origin

Webserver configuration

Use the following configurations to configure your webserver to contain all described headers. Below, you find further descriptions of the single headers.


On Apache you 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"


On Nginx you need to update your configuration file which is usually located at /etc/nginx/nginx.conf,/etc/nginx/sited-enabled/ (Ubuntu/Debian) or /etc/nginx/conf.d/nginx.conf (RHEL/CentOS) to include the correct 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 to an insecure HTTP connection. See Enable HSTS for the correct settings.


The X-Frame-Options header declares whether this site may be embedded as a frame into other websites. The values are:

denyDo not allow frames of this site
same-originAllow frames of this site when the domain matches
allow-from DOMAINAllow frames of this site when embedded in webpages on DOMAIN

Setting this header, e.g., to deny, will protect the website against clickjacking attacks where an attacker overlays your iframe in your webpage with arbitrary content to bait his victims in clicking on certain links on your website.


Some web browsers are shipped with a Cross-Site-Scripting (XSS) filter. This filter can detect specific XSS attacks and prevent them. To configure the browser filter behavior, use the X-XSS-Protection header.

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, e.g., to 1; mode=block will tell the browser that it should not render the web page if it detects an attack.


Browsers try to detect the MIME-type of files sent by the webserver. For example, suppose an attacker manages to upload a malicious (executable) file to a webserver, which only sends images. The MIME-type can provide protection, as it tells the browser that it should expect an image and not an executable file. Therefore, the browser must not detect the MIME-type but only use the webserver provided MIME-type. To enforce this behavior, use the X-Content-Type-Options header and set it to nosniff.

nosniffOnly use the declared MIME-type

The Same-Site cookie flag tells the browser not to send cookies and cross-site requests. This cookie flag prevents the risk of cross-site information leakage and can also help to mitigate Cross-Site Request Forgery attacks. 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.

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


The Content-Security-Policy (CSP) header tells the browser from which domain further resources such as scripts, images, or stylesheets may be loaded. This can prevent various Cross-Site-Scripting (XSS) and other Cross-Site-Injection attacks. However, the policy needs to be hand-crafted for the particular usage, as it may easily prohibit analytic scripts, fonts, or other resources that are loaded from a third party.

default-scr 'self' resources.example.orgDefine loading all resource types from the own domain and
script-src 'self' scripts.example.orgEnable loading scripts from the own domain and
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 .
img-src 'self' imgs.example.orgEnable loading images from the own domain and
media-scr 'self' media.example.orgEnable loading media elements from the own domain and
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
connect-src 'self' api.example.orgEnable connections with script interfaces, such as XMLHttpRequest or WebSocket to the own domain and
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-appletAllows 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 over an HTTPS connection.

A specific and restrictive policy can be default-src 'self.' Test your configuration thoroughly, as you may not want to block your analytics script or other third-party resources.


The Referrer-Policy header defines how much information about the referrer is sent when the user selects a link. The referrer may leak sensitive information such as user-specific URLs. Therefore, the referrer-policy might be set to some more restrictive value. A relatively secure setting is strict-origin-when-cross-origin.

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 a 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 a referrer, but only when the request is not downgraded from HTTPS to HTTP.
strict-origin-when-cross-originSend the origin as a 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 a referrer.


The Cache-Control header defines how caching in the browser is configured. Depending on the header's value, the browser may cache the website, including any sensitive information. The header should be set to no-store for pages where confidentiality is an issue.

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.


The Access-Control-Allow-Origin header defines which applications may consume your API. It should be set to the domain of your frontend, such as:


See this topic if you have multiple applications using your API.