There are a number of methods to attach a web site and its viewers’ browsers. Many of these have simple fixes that can be applied in the Apache configuration file. This article presents some of the headers that can be applied
WordPress can add headers in the config.php file. However, setting them in the webserver configuration will secure the site, not just the WordPress content.
For Apache, headers are added by the mod_headers module. The directives are in the form:
Header set Strict-Transport-Security: “max-age=7776000; includeSubDomains”
Security Headers
Many headers change the browser’s behavior so it is more secure. Some headers have complex options for which you will need to provide your own values.
The headers are listed alphabetically.
Content-Security-Policy
This header limits the origin of content to prevent cross-site scripting attacks. If incorrectly set, it can break access to included content. Third-party content including analytics and ad networks may require an insecure policy. In most cases, you can safely specify “object-src ‘none’; base-uri ‘self’;”. Violations can be reported so that you can adjust your policy appropriately.
This header implements a policy. If you are using content from third-party sites, you will need to set a policy that enables access to their content. Consider enabling reporting of policy violations. When creating your policy consider suffixing the header name with “-Report-Only” which will disable enforcement while enabling reporting. Generating a secure policy for scripts can be difficult.
There are currently three CSP versions with differing functionality. Version 3 includes the ability to specify a nonce used to secure scripts. Unless your site already implements nonces, this will likely require changes to script tags and in-line scripts.
Strict-Transport-Security
This header specifies that the site should only be accessed via HTTPS for a period of time. It is ignored for HTTP requests. Once seen, requests to the site will only use HTTPS until the time expires. The required “max-age=’ directive specifies the number of seconds until the policy expires. The optional valueless directive “includeSubDomains” indicates the policy also applies to subdomains.
While in force, this policy will force access to use the HTTPS protocol with valid trusted certificates. This secures access from man-in-the-middle attacks. While there are other methods to provide trust, it is best to use certificates from an external certificate authority. The LeysEncrypt initiative provides free trusted certificates.
X-Content-Type-Options
This header has only one option “no-sniff”. This provides protection for various text resource requests. For style and script resources the MIME type must be correct. For other text MIME types. Cross-Origin Read Blocking (CORB) is enabled. The content security headers control valid origins.
X-Frame-Options
This header prevents pages from being embedded in frames. Embedding pages in frames is used in clickjacking attacks. This header has two valid options: deny and same-origin. The deny option prevents embedding anywhere. The same-origin option allows embedding only within content from the same site. Normally same-origin is used. Consider using the “always append” action with this header.
X-Permitted-Cross-Domain-Policies
This header prevents Adobe from accessing content from your site. If you are hosting content for Flash or active PDF content, you should set an appropriate policy. Otherwise, you should use the “none” option. Modern browsers block this kind of content, so this header may not be required.
X-XSS-Protection
This header only applies to legacy browsers. The Content-Security-Policy header provides the same functionality in modern browsers. The secure setting for this header is “1; mode=block”.