Cross-site Scripting (XSS)
Files.com displays filenames, descriptions, registration information, and other text supplied by users and external senders. That information needs to remain data when it appears in the application.
Interpreting it as HTML or JavaScript could let supplied content act with the browser's access to the application; this is the concern called cross-site scripting, or XSS.
Files.com combines controlled rendering of supplied content with browser policies that restrict script execution. Uploaded documents and intentionally published websites have separate handling rules because displaying a filename, previewing a document, and hosting a web application are different operations.
Text and Formatted Content
The web interface renders ordinary values, such as filenames, as text rather than inserting them as executable HTML. Characters that have meaning in HTML remain part of the displayed value.
Where the application supports Markdown, it uses a Markdown renderer rather than treating the supplied value as an unrestricted HTML page. Links are limited to supported web or email schemes, and images use HTTPS sources. Formatting text does not grant the author permission to supply arbitrary application scripts.
These rendering boundaries are the first control. OWASP's XSS guidance likewise distinguishes safe handling of text, markup, and URLs according to where the value will be used.
Script and Resource Policies
The main web interface sends a Content Security Policy that restricts script sources. Script elements are limited to the application's own origin; the policy also separates the sources permitted for styles, frames, images, workers, and network connections.
Inline styles are permitted to support custom branding. That style permission does not permit inline JavaScript. The policy does not grant arbitrary external script sources merely because images or file-transfer connections may use other hosts.
Application scripts are loaded as Files.com application resources. Uploaded documents have separate delivery and processing paths; publishing a document is different from adding code to the Files.com application.
CSP provides an additional browser control alongside content rendering. It does not establish that every value is appropriate for every use, nor does it replace the service's authorization checks. HTTP Response Headers explains directive scope and the different policy used for API data.
The web interface's split session storage prevents either its saved cookie or local storage alone from containing the complete session token. It does not prevent JavaScript already running in the application's origin from accessing both parts or using the current session. Preventing supplied content from becoming application code remains necessary.
Documents and Published Websites
Files.com preserves original uploaded files, including embedded scripts and metadata. Uploading an HTML document does not turn its contents into the Files.com web interface's code, but a recipient who downloads and opens that document still receives the original contents.
Previews and conversions have their own processing and delivery behavior. File Content explains isolation of supported processing, and Previews explains what is delivered to the browser.
Public Hosting intentionally serves uploaded HTML and JavaScript on a separate hosting origin. A publisher's scripts running there are part of the hosted website's behavior. They do not receive the primary Files.com application's session through that origin.
Hosted folders can still share an origin with one another. Use HTML sandboxing for content published by people who should not run scripts, and a separate hosting origin when different publishers' content must be independent. Those controls preserve the intended publishing boundary without rewriting every uploaded file.