HTTP Security Headers are essential tools for enhancing the security of web applications. They instruct browsers on how to handle content, enforce security policies, and mitigate various attacks.

These headers, along with our other security practices, significantly reduce the risk of common web vulnerabilities.

We undergo regular vulnerability scans as part of our SOC 2 Audit process and we continuously monitor and review our security settings to provide a safe and secure environment for our customers.

Content-Security-Policy

The Content Security Policy (CSP) feature is designed to provide an additional layer of security to web applications by allowing developers to specify which resources can be loaded and executed.

In Files.com, we provide a Content Security Policy based on Content Security Policy (CSP) Version 3.

Inclusion of unsafe-inline

Files.com uses the latest CSP Version 3, which uses "Nonce"-based security. This is the best protection available in a Content Security Policy.

However, in order to support older web browsers, CSP Version 3 allows you to include the directive unsafe-inline. When used in conjunction with the "Nonce" feature of CSP Version 3, this directive is ignored by modern browsers and only used to provide backward compatibility to old browsers.

This inclusion of the unsafe-inline directive sometimes results in false positives from security scanner software not aware of the modern behavior of CSP Version 3. Please see Google's official information about CSP Version 3 for more information.

X-Frame-Options

Files.com also defines the X-Frame-Options header with the value "SameOrigin." This configuration allows us to embed content within our own domain while preventing other websites from embedding our content in an iframe, which would potentially expose the site to clickjacking attacks.

The "SameOrigin" directive restricts iframe embedding to the same domain, and is set on all responses. This measure has been reviewed and is aligned with industry practices that align with most modern websites and platforms.

Strict-Transport-Security (HSTS)

The header Strict-Transport-Security (HSTS) is used to ensure that all communications with the server are conducted over HTTPS, thereby mitigating the risk of man-in-the-middle attacks.

We have configured this header to ensure our users always access our platform securely, enforcing the use of HTTPS for all connections.

This header is not automatically set for customers using a Custom Domain, however you may optionally enable it in this situation.

XSS Protection

The X-XSS-Protection header is a browser-level feature that aims to protect against Cross-Site Scripting (XSS) attacks. While modern browsers are increasingly capable of preventing XSS on their own, this header is still included as an additional measure to mitigate potential XSS vulnerabilities.

Content-Type-Options

Files.com also sets the Content-Type header to prevent MIME type sniffing. The X-Content-Type-Options header is set to "nosniff," which instructs browsers not to automatically detect the MIME type of a resource but to trust the specified content type. This prevents potential security risks related to content type confusion, such as executing a malicious file under the wrong MIME type.

Permitted Cross-Domain Policies

The Cross-Origin-Resource-Policy header is set to "same-origin," which means that resources can only be loaded from the same origin as the document. This header helps prevent Cross-Site Resource Sharing (CORS) vulnerabilities by restricting how resources are shared across different origins.

Server

The server header is set to files.com in all HTTP responses. This provides a non-specific server identifier, helping prevent the leakage of sensitive server details while still maintaining compliance with security standards.