Skip to main content

Cross-origin Requests

A browser visiting another website may be able to send requests to Files.com without giving that website permission to read the response or act as the signed-in user. Request authentication, browser origin rules, and CORS govern different parts of that interaction.

The important questions are whether the request carries a valid credential, whether that credential authorizes the operation, and whether the browser allows the calling page to read the result. A successful browser connection does not answer all three.

Requests Initiated by Another Website

The main web interface splits its saved session token between a cookie and local storage. It combines those parts and explicitly supplies the complete token in an authenticated request header. Sending the cookie alone does not supply that credential.

A different website displaying an image, opening a frame, or submitting an ordinary form to the Site therefore does not automatically make the request act as the signed-in Web App user.

A script on another origin also cannot read the application's origin-scoped browser storage. Sending a non-standard authentication header across origins requires the browser's preflight checks as well as possession of the credential. These boundaries prevent an unrelated page from turning ordinary browser navigation into authenticated API work.

Authentication does not authorize every operation. Files.com checks the user's permissions and the credential's restrictions for the requested action. Selected sensitive changes also require Re-authentication.

CORS Controls Browser Reads

Cross-Origin Resource Sharing (CORS) determines whether browser code on one origin may read a response from another. It does not authenticate a caller, grant folder permissions, or prevent a non-browser client from requesting the URL.

A preflight request asks whether the browser may send particular methods and headers. It does not itself carry out the requested file or administrative operation. The response to the actual request must still satisfy authentication and authorization.

For Public Hosting, customers can enable CORS and choose allowed origins. CORS is off by default. Credentialed access requires particular care because a browser may already hold credentials for the destination; allow only websites trusted to receive that content.

For hosted content requiring Site login, cross-origin browser content loads need both enabled CORS and an explicitly allowed origin. An empty list does not allow those requests.

Opening the hosted page as a top-level browser visit is separate from loading it inside another website.

These settings do not separate pages on the same hosting origin. Different folders, passwords, and URL keys remain on one origin unless a separate hosting domain is configured.

A person may open a public Share Link while already signed in to the same Site. The public Share Link page omits that user's Web App session token from its API request header and uses the sharing visitor's access instead.

The link's requirements and allowed actions determine the visitor experience. Opening it while signed in does not make its visitor requests operate with the user's administrative or folder permissions. Share Links explains that separate access relationship.

Embedded Pages and Parent Websites

A Files.com sharing embed operates in a separate frame. The browser's origin boundary separates the framed page from its parent website; allowing the frame does not give the parent unrestricted access to the frame's documents or authentication state.

The initialization script you include runs in your own page and creates the embedded experience. Your page's script and frame policies must therefore allow the documented sources. Clickjacking & Embedding explains that deliberate exception to ordinary framing restrictions.

Return Destinations and Authorization Redirects

An application's return destination after login is different from an external application's authorization callback. The web interface recognizes local application routes for its ordinary return navigation. App authorization flows validate their client and callback through the applicable authorization process.

An external destination does not receive the user's Files.com browser session merely by becoming a navigation target. When connecting an application, review the authority granted to it and the lifetime of its own credentials; Desktop & Mobile App Sessions and Remote MCP authorization describe those relationships.