Served-App Security
The response headers, cookie flags, and per-app origin separation a deployed app inherits without configuration, and the embedding and access gates the serving layer enforces.
A deployed Remy app is a web application served on its own origin. The platform sets the response headers, cookie flags, and origin boundaries a security review looks for, so every app inherits them without configuration. This chapter covers what the serving layer enforces and why each origin is where it is.
#One Origin Per App
Every app serves on its own subdomain of the platform apex, or on its own custom domain. Cookies, local storage, and the same-origin policy therefore separate one app from every other app, and from the platform itself. An app's session cookie is scoped to its origin and signed with a per-app secret.
Three more origins are deliberately different sites:
| Origin | Purpose | Why it is separate |
|---|---|---|
| The files domain | Private file delivery via signed URLs | A cookieless origin, so a file URL carries no session and file content cannot read one |
| The public CDN hosts | Public files, images, video | Untrusted uploaded content never renders on an app's origin |
| The dev-box preview apex | Unreleased, agent-authored code | A different registrable domain, so it never shares a cookie scope with deployed apps |
On the app's own origin, only raster images from public file stores are transformed and served inline; any other public file is redirected to the isolated CDN origin.
#Response Headers
The static serving path sets on every response:
| Header | Value | Effect |
|---|---|---|
X-Content-Type-Options | nosniff | Browsers honor the declared content type |
Referrer-Policy | strict-origin-when-cross-origin | Referrers do not leak paths across origins |
Content-Security-Policy | frame-ancestors <allowlist> when the app declares one | Only the listed origins may embed the app |
X-Robots-Tag | noindex, nofollow on gated and preview surfaces | Previews and private apps stay out of search indexes |
Cache-Control | private, no-cache on session HTML; public, immutable on content-addressed assets | Personalized pages are never cached; assets are cached hard |
The platform's HTTP server does not advertise its framework, and HTTPS is forced at the edge before any request reaches the platform.
#Cookies
The app session cookie is HttpOnly, Secure in production, and carries a same-site policy chosen by the platform: strict by default, relaxed only when the app is served embedded and the builder has declared the embedding origin. The cookie is a JWT signed with the app's own secret and carries its original issue time, so an absolute maximum session age can be enforced regardless of activity.
#Embedding
An app is not embeddable by default. A builder who wants the app inside another site declares the allowed embedding origins, and the platform emits a frame-ancestors policy naming exactly those. The platform's own console is the one origin that may frame an app for its preview surfaces.
#Preview and Access Gates
A branch preview host answers nothing, not even a page, without a workspace session or a share link, and the gate is re-checked across the whole internal request surface, not only on HTML. An app whose access is restricted resolves the visitor before serving content. An app that has never published answers 404 on its origin rather than falling back to any other build.