CDN Security Headers

CDN Security Headers

Using HTTP security headers can improve website and application security and protect against clickjacking, cross-site scripting, as well as other common attacks. HTTP headers let the client and server pass additional information using an HTTP request or response which can have an impact on its final behaviour. Security headers are the subset that specifically have an impact on the security of the website or application and when used correctly can become a crucial part of setting up a more secure platform.

You can use the MEDIAMAKS UK Security Headers tool to easily add security headers to your website. To use this tool:

• Head to Manage Hosting and select ptions > ManageO on the site you want to add security headers for.
• Select the Security Headers icon within the CDN section.

There’s several main security headers that you can set, we’ve outlined what each security header does and in what scenario you may want to use the header below.

X-Frame-Options

The X-Frame-Options header is used to indicate whether or not a browser should be allowed to render a page in an iframe or object tags. Sites can use this to avoid click-jacking by ensuring that their content is not embedded into other sites.

There are two options you can use with X-Frame-Options:

• DENY – The page cannot be displayed in a frame, regardless of the site attempting to do so
• SAMEORIGIN – The page can only be displayed in a frame on the same origin as the page itself.

For more information on X-Frame-Options please see the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

X-Content-Type-Options

The X-Content-Type-Options header is a marker used by the server to indicate that the MIME types in the Content-Type headers should not be changed. This is a way to opt out of MIME type sniffing or to say that the MIME types are configured deliberately.

There’s only one option with X-Content-Type-Options, nosniff, this blocks requests if the request destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type.

For more information on X-Content-Type-Options please see the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Referrer-Policy

The Referrer-Policy header controls how much referrer information, which is sent using the Referer header, should be included with requests.

The options you can use with Referrer-Policy header are as follow:

• no-referrer – The Referrer header will be omitted entirely. No referrer information is sent along with requests.
• no-referrer-when-downgrade – Send the origin, path, and querystring in Referer when the protocol security level stays the same or improves. This includes HTTP to HTTP, HTTP to HTTPS and HTTPS to HTTPS but excludes HTTPS to HTTP and HTTPS to file.
• origin – Send only the origin in the Referer header.
• origin-when-cross-origin – Send the origin, path, and query string when performing a same-origin request to the same protocol level. Send only the origin for cross origin requests and requests to less secure destinations.
• same-origin – Send the origin, path, and query string for same-origin requests. Don’t send the Referer header for cross-origin requests.
• strict-origin – Send the only the origin when the protocol security level stays the same (HTTPS to HTTPS). Don’t send the Referer header to less secure destinations (HTTPS to HTTP).
• strict-origin-when-cross-origin – This is the default, this will send the origin, path, and querystring when performing a same-origin request. For cross-origin requests it will send only the origin when the protocol security level stays same (HTTPS to HTTPS). Don’t send the Referer header to less secure destinations (HTTPS to HTTP).
• unsafe-url – Send the origin, path, and query string when performing any request, regardless of security.

For more information as well as examples of the Referer-Policy header please see the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Strict-Transport-Security

The Strict-Transport-Security header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

The options available are:

• max-age= – Which allows you to set the time in seconds that the this should remember that it can only be accessed using HTTPS.
• includeSubDomains – This is an optional parameter and if applied the rule will aply to all of the sites subdomains as well.

For more information on Strict-Transport-Security please see the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

X-XSS-Protection

The X-XSS-Protection header is a feature of Internet Explorer, Chrome and Safari which stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers with sites that have implemented a strong Content-Security-Policy that disables the use of inline JavaScript (‘unsafe-inline’), they can still provide protections for users of older browsers that don’t yet support Content-Security-Policy.

• 0 – Disables XSS filtering.
• 1 – Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page.
• 1; mode=block – Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
• 1; report= (Chromium only) – Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.

For more information on X-XSS-Protection please see the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection