More security for websites with security headers

The security headers are sent as additional HTTP headers when the connection is established between the browser and the server. In TYPO3, additional headers can be added via TypoScript.

As of TYPO3 version 7.6, the specification is made via a numeric array in the following form:

config.additionalHeaders {
 10.header = Parameter1:Value; possibly additional values
 20.header = Parameter2:Value; possibly additional values
...

}In TYPO3 version 6.2 and earlier, the individual headers are separated by a pipe symbol |. The above configuration would therefore be

config.additionalHeaders (
 Parameter1:Value;possibly additional values |
 Parameter2:Value;possibly additional values |
...

)At the end of this page there is a complete example that can be used as a template for your own TYPO3 projects.

With the HTTP Strict Transport Security line, the browser is informed when a domain is called up for the first time that all future calls should only be made via an encrypted connection (https). This specification can also be extended to all subdomains.

The browser remembers these settings for all future accesses within the specified period and refuses access via unencrypted connections (http://).

The prerequisite for using HSTS is that a valid SSL certificate exists for the domain. If the specification is extended to subdomains, it must be checked whether either a wildcard SSL certificate exists for the domain or alternatively whether all subdomains used also have an SSL certificate.

Syntax of the HTTP Strict Transport Security header for one domain only:

strict-transport-security:max-age=31536000The

max-age parameter specifies how long this rule should be valid (in seconds), a value of one year is recommended (31536000 seconds).

If all subdomains are also to be included in the rule, the header is

strict-transport-security:max-age=31536000; includeSubdomains

The X-Frame-Options header can be used to specify whether your own website may be integrated into frames. If you prevent a page from being loaded via a frame in the browser, you can prevent attacks via so-called clickjacking.

Possible parameters are:

DENY: embedding the page in a frame is generally not possible

SAMEORIGIN: embedding is only permitted from your own domain

ALLOW-FROM example.com: you can explicitly specify websites that are allowed to be integrated via frame

The use of SAMEORIGIN is recommended for TYPO3 websites:

X-Frame-Options:SAMEORIGIN

Current browsers have built-in protection against reflective XSS attacks. This protection can be switched on and off with the X-Xss-Protection header. With the optional parameter mode=block, the attack is blocked instead of just filtered. Recommended setting:

X-Xss-Protection: 1; mode=block

The Referrer-Policy header can be used to configure whether and how the referrer is transferred for outgoing links from the website. This header is relatively new and has been supported since the beginning of 2017.

The following configuration options are available:

no-referrer: no referrer is provided

no-referrer-when-downgrade: when switching from an https to an http page (encrypted to unencrypted), no referrer is passed. The referrer is generated for links from unencrypted pages (http).

same-origin: the referrer is generated for links within a website, but not for links to external websites.

origin: the referrer is always generated and specifies the source domain, but the path is removed.

strict-origin: like origin, but the source domain is only specified if the target is a website with encryption (https)

origin-when-cross-origin: within the same domain, the path is also listed in the referrer, when linking to other domains only the domain name without the path.

strict-origin-when-cross-origin: as before, but no referrer information is sent when downgrading from an encrypted to an unencrypted connection.

unsafe-url: the referrer is sent in any case, even when linking from an encrypted to an unencrypted connection. This option is not recommended (hence the name "unsafe")

Recommendation:

If an SSL certificate has been issued for the domain, the strict-origin option is recommended, otherwise the origin option.

Referrer policy:strict-origin

With the content security policy, you can specify exactly which content may be loaded from where by the browser on the website. Unfortunately, it is not possible to recommend a standard entry here, as the details depend on the individual content of the website.

Detailed information on this can be found on the Scott Helme website.

It is strongly recommended that the policy is first tested with the "Content-Security-Policy-Report-Only" instruction before the policy goes live. The output during testing is displayed in the console of the Chrome browser, for example.

Here is an example of how the configuration looks on the jweiland.net website:

Content-Security-Policy: default-src 'unsafe-inline' 'unsafe-eval'; 
script-src 'unsafe-inline' 'unsafe-eval' https://jweiland.net https://stat.jweiland.net https://www.googletagmanager.com https://www.google-analytics.com; font-src 'self'; 
style-src 'unsafe-inline' https://jweiland.net/; 
img-src 'self' https://www.google-analytics.com/ https://stats.g.doubleclick.net/ https://stat.jweiland.net; 
frame-src https://player.vimeo.com/;
connect-src https://jweiland.net/

The following example for TYPO3 version 7 (and higher) can be used as a basis:

config.additionalHeaders {
 10.header = strict-transport-security:max-age=31536000
 20.header = X-Frame-Options:SAMEORIGIN
 30.header = X-Xss-Protection: 1; mode=block
  40.header = X-Content-Type-Options: nosniff
50.header = Referrer-Policy:strict-origin
}For

TYPO3 version 6.2 (and lower) here is the example configuration:

config.additionalHeaders ( 
 strict-transport-security:max-age=31536000 |
 X-Frame-Options:SAMEORIGIN |
 X-Xss-Protection: 1; mode=block |
  X-Content-Type-Options: nosniff |
 Referrer-Policy:strict-origin
)

Once the settings have been made in TYPO3, the actual configuration can be checked with a tool:https://securityheaders.io

If you would like to find out more about security headers, please visit the following websites:

Website of Scott Helme
OWASP Project Security Headers