Public Hosting and Browser Access

Public Hosting separates published content from your Files.com application. Within Public Hosting, access also depends on who can publish, which folders share a browser origin, and the credentials a visitor's browser holds. A folder's password and site-login requirements check access to its content; they do not give each hosted folder a separate browser origin.

Hosting Origins

An origin consists of a protocol, hostname, and port. By default, all publicly hosted folders on a Files.com site share https://[subdomain].hosted-by-files.com. Their URL keys identify different paths on that origin. Different keys, passwords, or file permissions do not create different origins.

The separate hosting domain keeps published content outside the origin used by your Files.com web interface and API. Hosted pages do not inherit authenticated access to that application. This separation protects the primary application's sessions; it does not separate hosted folders from one another.

When scripts are enabled, a page in one hosted folder can request and read content from another folder on the same origin. Each request still has to satisfy the destination folder's access requirements. The browser may supply credentials or a hosting session already established by the visitor, without the script knowing the password. Grant write access to a hosted folder that can run scripts only to people you trust with the other hosted content on that origin.

Passwords and Site Login

Password protection checks a shared HTTP Basic username and password on each request. It does not identify an individual Files.com user. Browsers can cache these credentials and reuse them on subsequent requests. Each folder's authentication realm combines the site name and folder key so browsers can distinguish credentials for different folders. Distinct realms reduce incorrect password reuse and repeated prompts; they do not create separate origins.

Requiring site login checks that the visitor is an active user on the site. It establishes a session for Public Hosting without applying the user's file permissions to the hosted path. When both site login and password protection are enabled, both checks must pass.

CORS and Browser Reads

CORS controls whether browser scripts on other origins may read hosted responses. It is off by default. Disabling CORS or restricting its allowed origins does not restrict reads between pages on the same origin, block direct downloads, or replace authentication.

When CORS is needed for protected content, allow only origins you trust to receive it. An empty allowed-origins list permits credentialed reads from other websites when the browser supplies the visitor's credentials. Public Hosting never returns Access-Control-Allow-Origin: null, including when the list is empty. This prevents the CORS setting from granting read access to pages whose origin is represented as null, such as sandboxed documents.

HTML Sandboxing

The per-folder HTML sandboxing option serves HTML with Content-Security-Policy: sandbox. The browser gives the document an opaque origin, separate from the hosting origin, and blocks scripts, form submissions, and popups. The option is off by default so hosted web applications can run.

Enable sandboxing for any hosted folder writable by someone other than an administrator. It restricts what HTML published in that folder can do. Applying it only to a folder containing private documents does not stop scripts in another folder from requesting those documents; use a separate hosting origin when the content must be independent of other publishers.

Separate Domains and Folder Boundaries

Binding a custom domain to one folder limits that hostname to the selected folder. By default, the shared hosting address continues to serve the folder too. To give the folder its own hosting origin, enable the option to serve it only on its custom domain, then distribute the custom-domain URLs. Keep CORS disabled or limited to trusted origins to preserve the intended separation. A separate Files.com site also provides a different hosting origin.

A permission fence excludes a subtree from its parent's Public Hosting URL. If you separately enable Public Hosting at the fence boundary, the resulting URL still shares the site's hosting origin unless you configure a dedicated domain as described above.