Security headers and embedding
Choose who can show your app in an iframe, set your own Content Security Policy, and change the Referrer-Policy of your published app.
Every published Floot app is served with a safe set of security headers. You can change three of them for your own app: who may embed it in an iframe, its Content Security Policy (CSP), and its Referrer-Policy. Your assistant sets them for you — there is nothing to configure by hand.
What your app gets by default
- Embedding
- Any site may show your app in an iframe. That's what most apps want, and it is what you need to embed your app in Notion, Webflow or your own site.
- Content Security Policy
- A shared policy that allows what Floot apps commonly load — scripts, styles and fonts over HTTPS, images from anywhere, API calls to any HTTPS host — and blocks plugins and
<base>tag tricks. - Referrer-Policy
strict-origin-when-cross-origin: other sites see your domain when a visitor follows a link, never the full page address.
Block or limit embedding
Stopping other sites from framing your app protects it from clickjacking (a page that hides your app under its own buttons to trick visitors into clicking). It is also the usual fix for a security scan that reports a missing X-Frame-Options header.
| Setting | Who can embed your app |
|---|---|
| Anyone (default) | Every site |
| Only my app | Only your app's own pages |
| Nobody | No site, not even your own app |
| A list of sites | Your app plus the sites you name, for example https://partner.com or https://*.example.com |
Ask your assistant in plain words, for example "don't let other sites embed my app" or "only allow my app to be embedded on https://mycompany.com".
Set your own Content Security Policy
You can replace the shared policy's sources for any of these directives: default-src, script-src, style-src, img-src, font-src, connect-src, media-src, frame-src, worker-src, manifest-src and form-action. A directive you set replaces the shared one completely; the ones you leave alone keep Floot's. That works both ways:
- Tighten it: allow scripts only from your app and Stripe, limit forms to your own pages, or only allow iframes from YouTube.
- Loosen it: allow something the shared policy blocks, when your app needs it.
A few sources are always required, because every Floot page needs them: your app's own origin ('self'), inline scripts and styles ('unsafe-inline'), and https://floot.com for scripts while the built-in visitor analytics is on. Floot refuses a policy without them rather than letting it break your app.
Try a stricter policy before you enforce it
A stricter policy can block something your app quietly relies on — an API, a payment form, file uploads, a map. Ask your assistant to try it in report-only mode first: the browser logs everything it *would* block in the console and blocks nothing. Use the app's main flows on the live site, have your assistant add what's genuinely needed, then switch report-only off and publish again.
Change the Referrer-Policy
Pick any standard value. no-referrer is a good choice for an app whose links carry private tokens (password reset or magic sign-in links), so those addresses are never sent to another site.
When the change takes effect
On your published app, at its next publish. The preview runs on a different domain with its own headers, so it never shows these settings — check the live site after publishing. Duplicates of your project keep the setting.
What it does not cover
- Responses from your app's endpoints (
/_api/...). These headers matter on pages, not on data. An endpoint that returns its own HTML page — an OAuth callback, a payment-complete page, an embeddable widget — sets its headers itself, and your assistant knows how. - Native iOS and Android builds, which load your app from the device.
- Nonce-based CSP, which isn't possible because published pages are cached at the edge.