Security model
| Boundary | Control | Purpose |
|---|---|---|
| Account vs reader | slidesfly.com and slidesfly.xyz | Keep account and write surfaces off the content origin. |
| Reader vs deck | Sandboxed iframe without allow-same-origin | Give uploaded HTML an opaque origin. |
| Storage | Private R2 with a policy gateway or short-lived signed URL | Prevent a direct public-bucket bypass. |
| Lifecycle | Current version, expiry, visibility, and moderation checks | Make a stable path follow current policy state. |
Opaque-origin iframe sandbox
sandbox="allow-scripts allow-popups allow-popups-to-escape-sandbox allow-forms"Slidesfly intentionally omits allow-same-origin andallow-top-navigation. Uploaded deck code can run scripts, submit forms, and open permitted popups, but it does not receive a normal shared origin or permission to replace the top-level reader page.
Private object access
R2 buckets remain private. Public and unlisted deck assets pass through a content gateway that checks current database policy. Private, password, and allowlist flows receive short-lived signed object URLs after viewer authorization.
- Expired and quarantined decks are denied by the reader and content path.
- Historical versions are not exposed through a stable guessed object path.
- Deck IDs are non-sequential; obscurity is not used as the only authorization control.
Browser controls
The reader CSP limits default resources, scripts, styles, images, frames, and connection targets. Host-wide headers add HSTS, MIME sniffing protection, a strict referrer policy, clickjacking protection, and a restrictive Permissions Policy.
Embed mode intentionally changes the reader shell's frame-ancestorsbehavior for that request. It does not loosen the inner deck sandbox.
Upload and abuse controls
- Single-file decks cannot load remote scripts.
- Multi-file deck scripts must use local relative paths inside the archive.
- Known blocklisted domains and unsafe archive paths are rejected.
- Zip traversal, duplicate normalized paths, file count, and expansion limits are checked.
- Published decks can be reported and quarantined under moderation policy.
- Rate limits and plan quotas protect publish and view-event paths.
Limits and responsible disclosure
Sandboxing reduces risk; it does not justify a “zero risk” claim. Browser behavior, framework code, integrations, and policy systems can fail. Do not publish secrets, credentials, regulated data, or content you are not authorized to host.
For suspected security vulnerabilities, use the security contact or private disclosure route listed by the project owner. For an abusive deck, use the public report control on the reader.
Agent-readable equivalent: security.md.