Browser & HTTP Security
A browser can display files, run application code, retain a signed-in session, and load content from other websites. Keeping those activities separate matters when people administer a Site, open a shared document, or submit files through an embedded Inbox.
Files.com combines controls over content rendering, framing, request authentication, and browser origins. These address concerns such as clickjacking, where another website disguises an interactive page, and cross-site scripting (XSS), where supplied content is interpreted as application code.
The controls work together. A Content Security Policy limits what a page may load or run; it does not replace careful rendering of supplied text. Authentication identifies the connecting user or visitor, while permissions determine the operations that connection may perform.
The Response Determines the Policy
The main web interface, API responses, embedded sharing pages, and Public Hosting serve different purposes. Their browser policies reflect those differences.
| Response | Intended browser behavior |
|---|---|
| Main web interface | Runs the Files.com application and restricts which resources it loads and which websites can frame it. |
| API response | Returns data for a client to interpret, with restrictive content policies rather than an interactive application. |
| Embedded Share Link or Inbox | Allows a Files.com sharing experience to operate inside a customer's website while retaining its visitor access requirements. |
| Public Hosting | Serves customer-published content on a separate hosting origin, with controls chosen for the publishers and visitors involved. |
For example, allowing a dedicated Inbox embed inside a customer portal is intentional. It does not permit that portal to frame the ordinary administrative interface or inherit a Site Administrator's access.
Browser Boundaries and Customer Choices
A browser origin is the combination of protocol, hostname, and port. Different folders under one hostname share an origin even when their URL paths and passwords differ. This matters when choosing who may publish scripts through Public Hosting.
An embedded sharing page also remains separate from the website containing it. Your website controls its own scripts and policies; Files.com controls the embedded experience and its access requirements. The containing site's login is not a replacement for the Share Link's or Inbox's controls.
Use a current browser with HTTPS, JavaScript, cookies, and browser storage available. The browser enforces response policies; disabling its security features changes the environment in which those protections operate. The Web Interface troubleshooting guidance explains browser and extension requirements.
Scope of the Protections
Browser controls complement the service's authentication and authorization checks. Hiding a button, preventing framing, or restricting a browser read does not grant or remove a user's file permissions. Non-browser clients still need credentials and permission for the operations they request.
Files delivered to an authorized recipient remain that recipient's responsibility. Browser protections do not erase downloaded copies or remove scripts and metadata from original files. File Content explains preservation and processing, while Access Revocation explains the lifetime of sessions and previously authorized transfers.
For a browser-focused security assessment, OWASP's Web Frontend Security guidance provides criteria for content interpretation, cookies, origins, and response controls. Apply those criteria to the Files.com response and configuration involved, keeping intentionally embedded or published content distinct from the main application.