Clickjacking & Embedding

An interactive Files.com page must remain recognizable to the person using it. Another website should not be able to place the ordinary web interface inside a hidden or misleading frame and cause someone to activate its controls without understanding what they are doing. This concern is commonly called clickjacking.

Files.com restricts framing of the ordinary web interface. Dedicated Share Link and Inbox embeds deliberately allow framing so customers can include file exchange in their own portals.

Ordinary Pages and API Responses

The main web interface uses X-Frame-Options: SAMEORIGIN, which restricts framing to pages on the same browser origin. Another website cannot make the interface embeddable simply by adding an iframe or changing its own Content Security Policy.

API responses have a different policy: their Content Security Policy includes frame-ancestors 'none', and their framing header denies embedding. They return data rather than a page intended for someone to operate inside a frame.

These restrictions control how a browser presents a response. The service still checks authentication and permissions for each operation; a framing policy does not change the user's authority.

Dedicated Sharing Embeds

Files.com provides dedicated embedded versions of Share Links and Inboxes. Those versions permit the framing required to place the sharing experience on another website. They retain the link's or Inbox's supported visitor requirements and allowed actions.

The containing website's login does not automatically authenticate a visitor to Files.com. Likewise, displaying an Inbox inside a portal does not give uploaders permission to browse the destination folder or administer the Site.

Invitation-only Access Control and email-based one-time passwords require personalized invitation entry and are not supported for embedded Share Links. Choose an access arrangement supported by embedding rather than assuming that every standalone sharing option works in a frame.

The Two Sides of a Frame Policy

The containing page's frame-src policy controls which framed pages it may load. The framed response's frame-ancestors policy controls which pages may contain it. A permission on one side cannot override a restriction on the other.

The initialization script for a Files.com embed also runs in the containing page. Its script policy must allow the documented Files.com source, while the framed experience operates on its own origin. Limit other scripts on the containing website to sources you trust with that page.

Content Security Policy for Embedding explains the required policy changes. OWASP's framing guidance explains why response headers, rather than a rule on the containing page alone, establish the framing boundary.