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.

Publication and Recipient Access

Public Hosting serves files and web content at a hosting URL. Write access to the hosted folder gives a person the ability to change what visitors receive, including HTML that runs in their browsers when scripts are enabled.

Treat publishing access as responsibility for the content and behavior of the hosted site.

Choose the hosting access requirements before publishing. An unrestricted folder is available to people who have its hosting URL. Password protection requires a shared credential; requiring site login requires an active user on the Site.

These controls are different from ordinary folder permissions and from Share Link invitation and expiration controls. Use Share Links when the task is a controlled delivery to recipients rather than hosting a website or set of published files.

Site IP whitelisting does not apply to Public Hosting. Evaluate the hosting controls themselves when deciding who may read published material. A confidential source folder does not make its published copy confidential.

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.

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.

Hosting Sessions

Requiring Site login needs a way to admit the signed-in visitor without giving a published website the main application's session token. Files.com establishes a separate Public Hosting session for this purpose.

After authentication on the Site, a short-lived, single-use handoff returns the visitor to a validated HTTPS hosting URL. Files.com checks that the destination belongs to the same Site and requires Site login.

The handoff establishes the hosting session and is removed from the destination URL by a redirect that withholds referrer information and prohibits caching.

The hosting credential is stored in a Secure, HttpOnly cookie with SameSite=Lax on the hosting hostname. It authorizes hosted access rather than ordinary Web App or API operations. Cookies & Browser Storage explains why this cookie differs from the main application's split session storage.

The hosting session remains tied to its originating login session and user. Ending or expiring that login session, or disabling the user, prevents further access through the hosting session. A temporary download URL already issued still has its own expiration.

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.

For a folder without Site login, an empty allowed-origins list permits reads from other non-null origins. This includes a password-protected folder when the browser supplies the shared credentials.

For a folder requiring Site login, cross-origin browser content loads require both enabled CORS and an explicitly allowed origin. An empty list does not permit them.

A different hostname can share the browser's classification of "same-site" without sharing an origin; that classification alone does not admit the request.

Normal top-level visits to the hosted page remain available, subject to its access requirements. The cross-origin request checks distinguish those visits from another website loading protected content in a frame, script, image, or browser request.

Allowlisting an origin does not replace the visitor's hosting credential or override the browser's rules for when to send its hosting cookie.

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.

Public Hosting