HTTP security headers are particularly important for protecting websites and applications. They improve the security of a web server by preventing or making attacks from outside more difficult. They can also prevent the disclosure of sensitive data to unauthorized persons. All modern browsers, such as Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, or Opera, support HTTP security headers.
You should know these HTTP security headers
The term HTTP Security Header summarizes a set of HTTP response headers that allow the webserver to communicate with the browser using security features. These include:
- Content Security Policy (CSP): With this header, the server specifies which resources are allowed to be loaded onto the page. It can also be used to prevent cross-site scripting attacks and other malicious code from being executed. We'll explain which parameters to set here in a moment.
- X-Frame-Options: With this header, the server determines whether the page can be displayed in a frame or iframe on another website. This can prevent so-called clickjacking attacks.
- X-XSS protection: This header is used by the server to determine whether cross-site scripting (XSS) protection is enabled for the page. After activation, foreign scripts are prevented from being executed on the own website.
X-XSS-Protection: 1; mode=block
- X-Content-Type-Options: In order for a browser to display a web page correctly, it must know which file types it is dealing with. If this information is not supplied, it tries to "guess" the correct file type - and attackers can exploit this vulnerability. This command in the HTTP security header prohibits "sniffing".
- Referrer-Policy: This header is relevant for data protection. The server uses the referrer policy to control whether the link source should be transmitted when linking to other websites.
- Permissions-Policy: With this policy - formerly called feature policy - websites prohibit access to sensitive user data such as webcam, microphone, location or payment interface, which makes potential attacks more difficult.
Example: Permissions-Policy: <directive>=(<allowlist>), <directive>=(<allowlist>)
- HTTP Strict Transport Security (HSTS): With this header, the server can force the browser to transfer all pages over HTTPS. This ensures the encryption of all data during transmission. Attention: This is not a substitute for setting up properly established server-side HTTPS encryption, but only an additional safeguard.
Strict-Transport-Security: max-age=<expire-time>; includeSubdomains
How to set up HTTP Security Header on WordPress
Under WordPress there are different ways to set up HTTP Security Header. Regardless of the CMS used (like WordPress), the way via the .htaccess file is considered the default.
This file is located in the root directory of the website and can, for example, control that a certain part of a website is only accessible via password. Here, you enter the desired HTTP security headers between the tags <IfModule mod_headers.c> and </IfModule>. In the following screenshot, we show what this can look like.
Attention: This method affects all subpages of the website.
Another possibility under WordPress is the integration of the HTTP security headers via the file functions.php. However, we do not recommend this way, because the file and therefore also the security headers are overwritten by updates of WordPress or the used theme and so security gaps could open up unnoticed.
Check HTTP security headers on your own and other websites
To check the correct setup of the security headers on your or another website, you can use several free tools, for example, webbkoll.dataskydd.net.
After you have entered the corresponding URL, a complete list will be created, including which headers are used and which are not. For the next step, it is also important to know which external hosters your website uses. You can find this out either via the developer tools of your browser or via the linked tool: It outputs a whole list of external hosts at the push of a button.
Set Content Security Policy (CSP) for WordPress correctly
Setting up the content security policy correctly is complex. Blocking external hosts can quickly cause the website to stop loading all necessary content. First, you need to determine where the server is connecting to in order to systematically adjust it in the CSP. Content from external sources is not a concern per se, for example when using Content Delivery Networks (CDN).
This header provides extensive configuration options that must be customized to the specific locations of files such as images, fonts, and scripts on your website. If the header configuration does not match the requirements of your website, some resources may not load properly or work at all.
In our example, the administrator wants to allow website users to embed images of any origin in their own content. Audio or video media, on the other hand, are restricted to the two trusted hosts example.org and example.net. Scripts may only come from userscripts.example.com.
So, in use, the CSP in the .htaccess file might look like this:
In addition to the allowed locations for files to be loaded, the CSP can make further settings to increase the security of the own website. With plugin-types, for example, the permitted MIME types (Multipurpose Internet Mail Extensions, specifies what kind of file it is) for plugins that can be started via <object> or <embed> are defined.
- The sandbox applies a same-origin policy, but prevents popups, plugins, and script execution.
- Instructs the browser to send a policy error report to a specified URI (Uniform Resource Identifier).
- Defines valid sources that can be used for the <form> action in an HTML document.
- Defines valid sources for embedding with <frame>, <iframe>, <object>, <embed> and <applet>.
How did you like the article?
Thanks for your feedback!