HTTP Response Headers
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 hostname and URL involved in your integration or review. A policy observed on one kind of response does not describe every Files.com page or file delivery.
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. |
| Referrer policy | Which address information the browser sends when following a link or loading another resource. |
| Cache controls | Whether browsers and intermediaries may retain a reusable response. |
| Permissions Policy | Which browser capabilities, such as camera or location access, a page may use. |
Authentication and permissions still determine whether the request may receive protected information. A browser policy does not grant file access or authorize a request.
A page designed for embedding needs different framing rules from the main web interface. An API response has no need to run an interactive application, while Public Hosting can intentionally serve a customer's scripts.
Content Security Policy
The web interface's Content-Security-Policy separates the sources permitted for scripts, styles, images, embedded frames, workers, 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. The main web interface limits script elements to its own origin.
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.
The main web interface also restricts its base URL and form destinations to its own origin and upgrades insecure resource requests. Resource policies complement controlled rendering of supplied content; they do not replace it.
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.
Clickjacking & Embedding explains Files.com's ordinary framing restrictions and dedicated sharing embeds. 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. Their policy blocks script execution, form submissions, and framing.
X-Content-Type-Options: nosniff tells browsers to honor the declared content type rather than infer a different one. The web interface uses it as well. These controls help keep a data response from being interpreted as an application document.
The API disables the obsolete browser XSS filter with X-XSS-Protection: 0. This follows OWASP's recommendation for that legacy header; content rendering and CSP provide the relevant modern controls.
File downloads, previews, and Public Hosting have different content-delivery purposes. File Content explains why preserving an original document is separate from safely displaying application text.
Referrer Information
The web interface uses Referrer-Policy: same-origin. The browser can include referrer information for requests within that origin, while withholding it from requests to a different origin.
Referrer policy does not remove a sensitive URL from copies made elsewhere, browser history, or messages. Keep invitation links and signed transfer URLs private because possession can authorize access for their lifetime. Stored Credentials explains those URL credentials.
Caching and Previously Delivered Content
The web interface distinguishes application resources from dynamic responses. Versioned scripts, styles, and images can be cached for reuse; other web-interface responses use no-store. A cacheable application script is not a cacheable response containing a user's files or settings.
Cache directives govern reuse by browsers and intermediaries. They do not recall a response already received, remove a downloaded file, or prevent a person from retaining information displayed on screen. Cookies & Browser Storage explains the device and session responsibilities.
Public Hosting has its own response behavior. Its publication and authentication settings need to be evaluated on the hosting URL rather than inferred from the main application's cache policy.
Browser Capabilities
The web interface's Permissions-Policy restricts browser capabilities it does not need, including camera, microphone, geolocation, and payment access. This limits what the application page may request from the browser; it is separate from Files.com folder permissions and does not govern native applications or an unrelated website containing an embed.
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.
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.
Cross-origin Requests explains why browser read permission, authenticated requests, and server-side authorization are separate checks. Cookies & Browser Storage explains how cookies and browser storage participate in sign-in, rather than applying one cookie rule to every response.