🧭 Frontend Security Review Playbook

Intro: A frontend security review should not stop at “looks fine” because modern risk usually hides in state transitions, browser trust assumptions, partner scripts, and file handling. This playbook gives reviewers a repeatable way to inspect the browser-facing part of a product without drifting into vague advice.

What this page includes

• a practical review flow for web frontends and BFF-backed experiences
• what to inspect in auth, state, storage, rendering, and integrations
• evidence reviewers should ask for before approving release
• common anti-patterns and a decision matrix for escalation

Use this review when

Use this page when a team introduces one or more of the following:

• a new login, session, or logout flow;
• a new frontend framework or rendering mode;
• browser-side token handling;
• a payment, support, analytics, or chat widget;
• a high-risk upload, export, or document-viewing experience;
• a feature where tenant data can be viewed, exported, or delegated.

Review order

1. Map the trust boundaries first

Draw the request path and mark:

• the browser;
• the frontend application;
• the BFF, if one exists;
• the identity provider;
• the API gateway and backing APIs;
• third-party origins loaded as scripts, frames, images, fonts, or APIs.

If the team cannot explain where authority actually lives, the review is not ready to approve.

2. Identify the browser-held authority

Ask these questions first:

• What credentials or session material exist in the browser?
• Which of them can JavaScript read?
• Which actions can the browser perform directly versus only through a BFF?
• Which claims are only decorative in the frontend and which are server-authoritative?

Preferred bias: keep high-value authority in a server-controlled trust boundary and make the browser present intent rather than hold broad privilege.

3. Walk the rendering model

The rendering model changes the attack surface:

4. Inspect browser controls

A high-value release should have explicit decisions for:

• cookies: Secure, HttpOnly, SameSite, scope, lifetime;
• CSP: script strategy, frame strategy, reporting, exception inventory;
• CORS: exact origins, credential usage, preflight behavior;
• framing: frame-ancestors or equivalent;
• download behavior: inline render versus forced download;
• storage: what lives in cookies, memory, sessionStorage, or localStorage.

5. Inspect dangerous feature classes

Pay extra attention when the frontend can:

• upload files;
• render user-supplied HTML or rich text;
• start exports or bulk actions;
• embed support or analytics tools;
• call administrative APIs;
• manage organization settings, members, billing, or secrets.

Review checklist by topic

Authentication and session handling

Verify:

• login, refresh, and logout flows are consistent across tabs and devices;
• session invalidation works after password reset, MFA reset, and role change;
• the frontend does not trust its own route guards as the final authorization decision;
• logout clears the session from the browser and from the server-side session model;
• BFF routes reject direct cross-site abuse and do not accept confused-deputy behavior.

State and storage

Reviewers should reject or escalate if they find:

• long-lived bearer tokens in localStorage without a strong justification;
• secrets, API keys, or private environment values shipped in the bundle;
• entitlement checks implemented only in JavaScript;
• client-side feature flags exposing sensitive rollout logic.

Browser rendering and DOM risk

Look for:

• direct DOM sinks such as innerHTML, unsafe markdown rendering, template injection, or untrusted HTML display;
• dangerous file preview behavior;
• missing sanitization for rich text, comments, knowledge-base articles, templates, or email previews;
• support tools that can read full DOM state on authenticated pages.

Third-party scripts and widgets

Before approval, require:

• an owner for each script or widget;
• allowed data access documented;
• removal/disable path documented;
• CSP allowance explained;
• impact if the provider is compromised or starts collecting more data than expected.

Evidence reviewers should request

Ask the team for concrete proof, not only statements:

• production or staging response headers from real endpoints;
• screenshots or docs showing cookie attributes;
• a list of allowed origins and why they exist;
• a short CSP violation sample or reporting dashboard snapshot;
• a bundle or code grep showing that secrets are not compiled into the client;
• a short flow diagram for login, token refresh, logout, and privileged action confirmation.

Escalation triggers

Escalate the review if any of the following is true:

• the browser can directly call privileged upstream APIs;
• the team needs broad unsafe-inline or broad wildcard script sources in CSP;
• session or token invalidation behavior is unclear;
• tenant data export or admin actions are browser-mediated without server-side re-verification;
• the frontend can render attacker-controlled files inline;
• support tooling or marketing tooling has read access to highly sensitive pages.

Bad versus better patterns

Bad: frontend decides authorization

// Anti-pattern: route or UI state implies permission.
if (currentUser.role === 'admin') {
  showBillingExportButton();
}

Better: frontend presents intent, backend enforces policy

// Safer pattern: the frontend may hide or show UI,
// but the backend remains the source of truth.
const canExport = await api.get('/me/permissions/billing-export');
if (canExport.allowed) {
  showBillingExportButton();
}

The frontend can improve usability, but it must not be the last control.

Review close-out

Approve only when the team can answer:

1. Which authority lives in the browser?
2. Which actions require server-side re-verification?
3. Which origins, scripts, and files are trusted, and why?
4. Which telemetry would show abuse later?

Related pages

• Browser Security Foundations: CSP, CORS, Cookies, and Sessions
• OAuth for SPA, BFF, and Frontend Secret Anti-Patterns
• Third-Party Scripts, File Handling, and Frontend Supply Chain
• Security Headers and Reference Configurations
• File Upload, Download, and Browser Rendering Risks

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