Add secure application sessions

Enable secure login sessions

Open your project, choose Runtime → Capability Toggles, enable Secure login sessions, and save. A workspace owner or administrator can make this change. You can also ask Idam to enable secure login sessions for the project and review its runtime-policy update. The setting applies to the project's backend modules. It is off by default, including when a plan permits it; unrelated runtime changes preserve your choice. Workspace policy restrictions still apply.

This setting allows your backend to issue a tightly constrained session cookie. It does not create an authentication system, grant arbitrary response headers, or share sessions with other projects. Your app must implement account verification, session expiry and revocation, and authorization for every protected record and operation.

Issue and clear a session cookie

In the Rust SDK, send a cookie through Response::set_cookie:

Response::json(200, r#"{"signed_in":true}"#)
    .set_cookie(format!(
        "__Host-session={token}; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600"
    ))

Here token is an unpredictable, cryptographically secure session token generated by your authentication code. Never derive it from a timestamp, username, password, or predictable counter. Store the session securely on the server, bind it to the authenticated user, and reject expired or revoked sessions. Do not log the token or place it in URLs, frontend source, or browser local storage.

The edge accepts one Set-Cookie value per response, up to 4,096 bytes. Cookie names must start with __Host-, followed by letters, digits, underscores or hyphens, with a total name length of at most 128 characters. Values must use unquoted ASCII cookie characters; spaces, quotes, commas, semicolons, backslashes and control characters are rejected.

Every cookie must include Path=/, Secure, HttpOnly, and SameSite=Lax or SameSite=Strict. Domain is forbidden: a project cannot set a session cookie for a parent domain or another tenant. Duplicate attributes, multiple cookie values, SameSite=None, Expires, and unsupported attributes are rejected. Use an optional Max-Age from 0 to 2,592,000 seconds (30 days). Omitting it creates a browser session cookie; the server must still enforce its own expiry. Invalid cookie headers are omitted from the response.

To sign out, revoke the server-side session and return:

__Host-session=; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=0

Disabling the project setting stops new cookie issuance, including deletion cookies. Revoke active sessions in your app and clear them before disabling the setting when possible. A project hosted on a custom domain has a separate host-only session from its BlinkHost subdomain.

Protect requests and customer data

Use same-origin HTTPS requests to /_server_islands/<module>/<route> from your published frontend. The backend receives the full production path, including /_server_islands/<module>. Read the request's cookie header and accept exactly one matching session cookie; reject duplicate session-cookie names. Use the session's authenticated identity for every database access. Never trust a user ID, organization ID, role or price supplied by the browser without authorization checks.

For cookie-authenticated changes, validate the request's Origin against the exact app origin and require an appropriate CSRF defense, such as a server-bound CSRF token. Reject unexpected or missing origins for browser mutation routes. Treat login, logout and account changes as protected state changes too. SameSite alone is insufficient because another customer's sibling subdomain may count as the same site. Never perform writes in GET routes or rely on CORS as authorization. Keep client-rendered content safe from script injection.

An application with its own authentication normally uses the runtime's Public request route and enforces authentication in its code. The platform's token-protected access mode instead consumes the Authorization header for a BlinkHost API token; it is a separate access mechanism. Never put that platform token in a public frontend. An app may alternatively use its own opaque bearer token held only in browser memory on a public route, with full server-side authentication and authorization. It will need a fresh sign-in after a page reload unless the app implements another secure session mechanism.

Preview and production verification

Idam's private build preview serves an immutable frontend artifact. It does not proxy backend requests or run a full application server. Its content restrictions intentionally prevent external backend access. Use it to inspect the frontend, then verify actual authentication and data operations through the published application.

The IDE's live frontend preview has a separate backend bridge. That bridge uses its own preview authorization, omits browser cookies, and does not forward an application's bearer header to the module. Backend preview also suppresses module response headers and status codes. Enabling secure login sessions does not change these restrictions. Do not claim a successful preview is evidence that production login or access control works.

On the published app, check sign-in, a protected read and write, reload, logout and session expiry. Confirm that a signed-out visitor and another account cannot read or modify the first account's records. Keep test identities and screenshots free of real customer data and credentials.