Security Headers in the headers.json file Last updated: 27. Nov 2023

Setting HTTP headers for your Docly™ published folders.

Introduction

HTTP headers kan be configured in the followin file:
#/headers.json

Our platform utilizes a dedicated headers.json file to manage and apply HTTP security headers across different websites hosted on our content platform. This file serves as a central repository for security configurations, ensuring that each site is equipped with the necessary headers to enhance its security posture and safeguard against common web vulnerabilities.

The headers.json file contains a structured layout where each entry corresponds to a specific website, outlining the security headers and their respective values. These headers are meticulously chosen and configured to provide robust protection against threats like Cross-Site Scripting (XSS), Clickjacking, MIME type sniffing, and more, while also enforcing secure data transmission policies.

In this document, we provide an overview of the security headers included in the `headers.json` file. Each header is accompanied by a detailed explanation of its purpose, along with a comprehensive list of valid values and their implications. This guide aims to assist you in understanding the security mechanisms in place and how they contribute to maintaining the integrity and confidentiality of user data and interactions on our platform.

Overview of security headers

Header Description Values
Content-Security-Policy Limits the resources the website can use to prevent XSS and data injection attacks. default-src, script-src, img-src, connect-src, font-src, object-src, media-src, frame-src, sandbox, report-uri, child-src, form-action, frame-ancestors, plugin-types, base-uri
X-Frame-Options Determines whether a webpage can be displayed within a frame, iframe, embed, or object. DENY, SAMEORIGIN, ALLOW-FROM uri
X-Content-Type-Options Prevents the browser from MIME-sniffing a response away from the declared content-type. nosniff
Strict-Transport-Security Enforces secure (HTTP over SSL/TLS) connections to the server. max-age=<seconds>, includeSubDomains, preload
X-XSS-Protection Enables a browser's built-in protection against cross-site scripting. 0, 1, 1; mode=block, 1; report=<reporting-URI>
Referrer-Policy Controls the amount of information sent along with the referrer. no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url
Permissions-Policy Manages access to browser features like geolocation, microphone, and camera, enhancing security by limiting third-party access. Feature names: geolocation, microphone, camera, etc.
Directives: (self), (*), (src 'example.com'), (), to control feature access per origin.

Content-Security-Policy

The "Content-Security-Policy" header is designed to prevent Cross-Site Scripting (XSS) and data injection attacks. It allows web administrators to control which resources can be loaded and executed, thus enhancing the website's security.

Docly™ recommendation: Content-Security-Policy: default-src 'self';

This default setting restricts all content types to load only from the origin of the served document, implementing a strong same-origin policy.

Value Description
default-src 'self' Restricts all content types to load only from the origin of the served document (same-origin policy).
script-src 'self' Allows scripts to be loaded from the same origin as the document.
script-src <source> Specifies a whitelist of sources for scripts.
img-src 'self' Permits loading images from the same origin.
img-src <source> Defines valid sources for loading images.
object-src 'none' Disallows <object>, <embed>, and <applet> elements, blocking plugins.
style-src 'self' Allows stylesheets to be loaded from the same origin.
style-src 'unsafe-inline' Permits the use of inline styles in the document.
font-src 'self' Restricts font loading to the same origin.
connect-src 'self' Limits where the document can connect to via scripts (e.g., WebSocket, fetch).
frame-src 'self' Restricts sourcing of frames to the same origin.
sandbox Applies extra restrictions to the content in <iframe> tags.
report-uri <URI> Specifies where the browser should send reports if the content security policy is violated.
child-src 'self' Defines valid sources for web workers and nested browsing contexts.
form-action 'self' Restricts the URLs which can be used as the action of HTML forms.
frame-ancestors 'self' Specifies valid parents that may embed a page.
plugin-types <type> Restricts the set of plugins that can be embedded into a document.
base-uri <source> Defines a base URI for relative URIs within the document.

X-Frame-Options

The "X-Frame-Options" HTTP header is used to control whether a browser should allow a webpage to be rendered in a <frame>, <iframe>, <embed>, or <object>. Its main function is to protect against 'clickjacking' attacks, where a malicious site tricks a user into clicking something different from what the user perceives, potentially revealing confidential information or taking control of their account.

Docly™ recommendation: X-Frame-Options: SAMEORIGIN

This setting ensures that pages can only be displayed in frames or iframes that are from the same origin as the page itself. It's a widely supported and effective measure for protecting against clickjacking attacks.

Value Description
DENY The page cannot be displayed in a frame on any site, including the site it belongs to.
SAMEORIGIN The page can only be displayed in a frame on the same origin as the page itself.
ALLOW-FROM uri The page can be displayed in a frame, but only on the specified uri. This is less commonly used due to limited browser support.

X-Content-Type-Options

The "X-Content-Type-Options" HTTP header is used to instruct the browser to stop automatically detecting and interpreting the content type of the resources it loads. This is particularly important for preventing MIME type sniffing vulnerabilities.

Docly™ default: X-Content-Type-Options: nosniff

This default value is universally applicable and is crucial for enhancing security by instructing the browser to strictly follow the declared content type in the MIME headers, thus preventing MIME type sniffing attacks.

Value Description
nosniff Instructs the browser to refrain from MIME-sniffing a response away from the declared content-type. This setting helps prevent attacks based on MIME-type confusion.

Strict-Transport-Security

The "Strict-Transport-Security" (HSTS) HTTP header is used to enforce secure connections to the server. Its primary function is to tell browsers that they should only interact with the server using secure HTTPS connections and not via the insecure HTTP protocol. This is a critical security measure for preventing "man-in-the-middle" attacks, where an attacker could intercept or alter the communication between the user and the website if transmitted over an unencrypted HTTP connection.

Docly™ recommendation: Strict-Transport-Security: max-age=31536000;

Value Description
max-age=<seconds> Specifies the time, in seconds, that the browser should remember to access the site only over HTTPS.
includeSubDomains Instructs the browser to apply HSTS to all subdomains of the site's domain, enforcing HTTPS on the entire site.
preload An optional directive used to indicate the site's inclusion in browsers' preload lists for HSTS.

X-XSS-Protection

The "X-XSS-Protection" HTTP header is a feature of certain web browsers designed to enable or enhance their built-in protection against cross-site scripting (XSS) attacks. While modern browsers have robust XSS protection mechanisms, this header can provide additional security for users of older browsers.

Docly™ recommendation: X-XSS-Protection: 1; mode=block

This setting activates the XSS filtering built into most modern web browsers, and in case an XSS attack is detected, the mode=block directive instructs the browser to block the response instead of sanitizing or allowing it.

Value Description
0 Disables the XSS filtering. Useful if the website implements its own XSS protection or doesn't need it.
1 Enables the XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
1; mode=block Enables the XSS filtering. If a cross-site scripting attack is detected, instead of sanitizing, the browser will block the entire page.
1; report=<URI> Enables XSS filtering. If a cross-site scripting attack is detected and the mode=block is activated, the browser will send a report to the specified URI.

Referrer-Policy

The "Referrer-Policy" HTTP header controls how much referrer information (the URL of the referring page) should be included with requests. This header is essential for privacy and security, as it governs the amount of information sent to the server when a user navigates from one page to another. Proper configuration can help prevent leakage of sensitive information through URLs.

Docly™ recommendation: Referrer-Policy: no-referrer-when-downgrade

This setting ensures that the full URL of the referring document is sent to the destination when the protocol security level is the same (HTTPS to HTTPS) or lower (HTTPS to HTTP). However, if the protocol security level is downgraded (from HTTPS to HTTP), it will not send any referrer information, thus preventing potential data leakage in unsecured environments.

Value Description
no-referrer No referrer information will be sent along with requests.
no-referrer-when-downgrade Full URL is sent with requests to the same protocol security level. No referrer is sent when downgrading from HTTPS to HTTP.
origin Only the origin of the referring document is sent as referrer information.
origin-when-cross-origin Full URL is sent to same-origin requests, but only the origin is sent for cross-origin requests.
same-origin Full referrer is sent for same-origin requests but no referrer for cross-origin requests.
strict-origin Only the origin is sent as the referrer to a more secure destination (HTTPS -> HTTPS), but no referrer to a less secure destination (HTTPS -> HTTP).
strict-origin-when-cross-origin Full referrer is sent to same-origin requests and only the origin to more secure destinations, but no referrer to less secure destinations.
unsafe-url Full URL, including the path and query string, is sent with all requests regardless of origin.

Permissions-Policy Header

The "Permissions-Policy" HTTP header (formerly known as "Feature Policy") is a mechanism that allows website administrators to control which browser features and APIs can be used in the browser. This header can enable or disable powerful features like geolocation, camera, microphone access, and more, within the site's own pages and for iframes.

This header is instrumental in enhancing security and privacy by restricting features that could be exploited by malicious content. For example, it can prevent third-party content embedded in iframes from accessing sensitive device features or user data without explicit permission.

By specifying the allowed features and the contexts in which they can be used, the Permissions-Policy header provides granular control over the execution environment of the web content, thereby contributing to a more secure and user-centric web experience.

Docly™ recommendation: Permissions-Policy: geolocation=(self), microphone=(), camera=()

Feature Values Description
geolocation (self), (*), (none) Controls access to geolocation data.
microphone (self), (*), (none) Manages access to the device's microphone.
camera (self), (*), (none) Determines access to the device's camera.
fullscreen (self), (*), (none) Controls the ability to display content in fullscreen mode.
payment (self), (*), (none) Manages access to payment request APIs.

Example recommended headers.json file

{
    "Content-Security-Policy": "default-src 'self';",
    "X-Frame-Options": "SAMEORIGIN",
    "X-Content-Type-Options": "nosniff",
    "Strict-Transport-Security": "max-age=31536000;",
    "X-XSS-Protection": "1; mode=block",
    "Referrer-Policy": "no-referrer-when-downgrade",
    "Permissions-Policy" : "geolocation=(self), microphone=(), camera=()"
}