Cookies, CSRF, CORS, XSS and the BFF Pattern

Cookie controls

• HttpOnly prevents normal JavaScript from reading a cookie.
• Secure limits transport to HTTPS.
• SameSite restricts some cross-site sending.

These controls reduce risk but do not replace authorization or complete CSRF protection.

When CSRF matters

Cross-site request forgery matters when the browser automatically attaches credentials, especially cookies, to a state-changing request. Protect unsafe methods with antiforgery defenses, strict origin handling and suitable SameSite settings. Never change state on GET.

An API used only with an Authorization bearer header is not normally vulnerable to classic cookie CSRF because another site cannot make the victim's browser attach that header automatically. It still faces XSS, token theft and authorization failures.

What CORS does

CORS tells browsers which origins may read or send certain cross-origin requests. It is not authentication and does not stop curl, mobile apps or backend callers. Treat allowed origins as a trust list.

Avoid reflecting arbitrary Origin values. Do not combine an unrestricted origin policy with credentials.

XSS and token storage

Output encoding, safe templating and Content Security Policy reduce script-injection risk. A browser-accessible long-lived token increases impact if XSS occurs. A BFF can keep tokens server-side, but a compromised page may still send requests through the user's cookie session, so CSRF and authorization remain essential.

Interview comparison

SPA holding tokens: fewer server components, but greater exposure to browser script and refresh-token storage decisions.

BFF with cookie: better token isolation, but added backend state, CSRF controls and operational dependency.

The correct choice depends on application boundaries, identity provider support and the team's ability to operate the controls reliably.