Files.com uses HTTP response headers to control how browsers load content, display pages, and use HTTPS. The applicable policy depends on the response: an interactive page, an API response, and an embedded Share Link serve different purposes. Evaluate the headers on the URL involved in your integration or review.

What the Controls Decide

Browser response controls answer different questions. A policy that governs one of these activities does not establish the result for the others.

Control	Decision it governs
Content Security Policy	Which kinds of content a page may load or run, and which sources it may use.
Framing restrictions	Which websites may embed a response in a frame.
CORS	Whether browser scripts on another origin may read a response.
HSTS	Whether the browser uses HTTPS for subsequent connections to a hostname.
Content type and `nosniff`	How the browser interprets the returned content.

Authentication and permissions still determine whether the request may receive protected information. Headers also depend on the purpose of the response: a page designed for embedding needs different framing rules from the main web interface, while an API response has no need to run an interactive application.

Content Security Policy

The web interface's Content-Security-Policy separates the sources permitted for scripts, styles, images, embedded frames, and network connections. Each directive governs a particular type of content. For example, script-src-elem controls script elements when present; otherwise, the browser falls back to script-src and then default-src, following the CSP directive rules.

Files.com permits inline styles through unsafe-inline in style-src to support custom branding. That permission applies to styling, not JavaScript. The appearance of unsafe-inline in a style directive does not establish that inline scripts are permitted.

Embedded Content

Files.com provides dedicated embedded versions of Share Links and Inboxes for use on other websites. An ordinary Files.com page and its embedded version are not interchangeable when evaluating framing restrictions.

The parent's frame-src policy controls which frames it can load. The embedded page's frame-ancestors policy controls which pages may contain it. These are different checks, so review the response being embedded as well as the containing website's policy. Content Security Policy for Embedding covers the configuration your website needs.

HTTPS and Custom Domains

Files.com enables HTTP Strict Transport Security (HSTS) on its Custom Subdomains. The Strict-Transport-Security header tells browsers to use HTTPS for subsequent connections to that hostname.

For a Custom Domain, HSTS depends on the site's Custom Domain setting. Review the hostname and its configuration when checking for this header.

API Response Content

Files.com API responses use a restrictive Content Security Policy because they return data rather than an interactive page. They also use X-Content-Type-Options: nosniff, which tells browsers to honor the declared content type rather than infer a different one. These browser controls complement the API's authentication and permission checks; they do not grant access to files or change a user's permissions.

Reviewing a Browser Integration

Use the actual hostname, URL, and response involved in the integration. Check redirects as well as the final response, and distinguish the policy on your containing page from the policy on content loaded into it. A header observed on an API URL does not describe the policy for a Share Link or a Public Hosting page.

For Public Hosting, also review who can publish content and whether scripts are enabled. Its origin, CORS, and sandboxing controls determine how hosted pages interact with other content. CORS permits certain browser reads; it does not restrict access by other clients or replace a destination's authentication requirements.

HTTP Response Headers