HttpOnly Cookies
HttpOnly is a cookie attribute that prevents client-side JavaScript from reading the cookie value. Browsers still attach HttpOnly cookies automatically on same-site requests, which keeps session tokens out of reach of typical XSS payloads.
Technical Architecture & Deep-Dive
SPAs often prefer bearer tokens in memory, but BFF patterns store opaque session IDs in HttpOnly, Secure cookies issued by your edge. The browser sends the cookie; the BFF exchanges it for upstream credentials server-side.
HttpOnly does not stop CSRF by itself. Combine with SameSite, anti-CSRF tokens, and Origin checks on state-changing routes. Never mirror HttpOnly session values into localStorage for convenience.
Key Architectural Benefits
Implement HttpOnly Cookies at the Edge
Deploy lightweight API aggregation, edge caching, and secret injection in minutes without Docker containers or complex servers.
Frequently Asked Questions
Q:Can my React app read an HttpOnly session cookie?
No. Only the browser attaches it on HTTP requests. Your frontend calls your BFF, which validates the cookie server-side.
Related Architecture Concepts
The SameSite cookie attribute controls whether browsers send cookies on cross-site requests. Strict limits cookies to same-site navigations, Lax allows top-level GET navigations, and None requires Secure and enables third-party contexts when explicitly needed.
CSRF protection defends against cross-site request forgery, where a malicious site tricks a victim browser into sending authenticated requests to your API using existing cookies or sessions. Defenses include unpredictable anti-CSRF tokens, SameSite cookie attributes, and verifying Origin or Referer headers on state-changing calls.
A bearer token is an access credential sent in the HTTP Authorization header as Bearer followed by the token. Whoever bears, or holds, the token is granted access, without additional proof of identity, so bearer tokens must be transmitted only over HTTPS and kept confidential.
A Client Token is a scoped, revocable authentication credential designed for frontend web and mobile applications. It grants permission to invoke specific edge API pipelines while enforcing allowed-origin domains and rate limits, safely abstracting sensitive upstream API secrets.
Ready-to-Use Edge Recipes
Webflow is a purely static and frontend visual builder with no backend server. To call private APIs from Webflow custom code without revealing secrets in the browser inspector, route requests through RealComposer. RealComposer stores your API keys in an AES-256-GCM vault, injects credentials at the edge, and handles CORS headers automatically.
To solve call clerk backend api from client side, never execute unauthenticated requests or embed private tokens directly in client bundles. RealComposer acts as a sub-10ms edge gateway running on Cloudflare Workers that securely injects credentials from your Secret Vault, normalizes responses, and prevents unauthorized API usage. Route calls through your RealComposer edge URL to guarantee complete privacy, robust origin validation, and low mobile latency.
To use OpenAI in a client-side React app without leaking your secret key, never include OPENAI_API_KEY or REACT_APP_OPENAI_API_KEY in frontend .env files. Instead, route your fetch calls through a RealComposer edge endpoint that injects your secret key server-side on Cloudflare Workers and enforces CORS origin whitelisting.