PS Product SecurityKnowledge Base

🧱 Browser Security Foundations: CSP, CORS, Cookies, and Sessions

Intro: These controls are often configured by copy-paste. They deserve better because weak defaults here create long-lived product risk that is hard to see in backend dashboards.

What this page includes

  • practical guidance for CSP and CORS
  • cookie and session rules that product teams should standardize
  • common mistakes in browser storage
  • release checks for frontend security posture

A practical baseline is:

  • Secure for session cookies;
  • HttpOnly for cookies that do not need JavaScript access;
  • explicit SameSite rather than relying on browser defaults;
  • short idle and absolute timeouts for high-risk sessions.

Current browser behavior makes SameSite=Lax a safer baseline than the historic default, and SameSite=None should only be used with Secure over HTTPS.

CORS

CORS is not an authorization system. Treat it as a browser exposure control.

Good defaults:

  • allow exact origins instead of wildcards;
  • do not combine Access-Control-Allow-Credentials: true with broad origins;
  • keep preflight and method allowances narrow.

CSP

Use CSP to reduce script execution risk, especially when marketing tags, support tools, or user-generated content enter the page. Start with reporting, then tighten around script sources, object sources, framing, and inline script strategy.

Browser storage

Avoid putting sensitive session material in localStorage unless the design has a strong reason and compensating controls. Session and token design should assume browser-side JavaScript compromise is possible in some failure scenarios.

Release checks

  • cookie attributes validated in production headers;
  • CORS reviewed for exact origins and credential use;
  • CSP present and tested on high-value pages;
  • no raw secrets or privileged state in frontend build output.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.