Security Headers in the headers.json file Last updated: 04. Aug 2024

HTTP headers kan be configured in the following 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.

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.

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.

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.

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;

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.

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.

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=()