Audit Frontend Token Security

---
name: "token-security-in-frontend"
description: "Threat-model and review browser token storage, transport, renewal, logout, and XSS or CSRF defenses, then produce prioritized frontend and backend remediation."
---

# Audit Frontend Token Security

Use this skill when reviewing how a browser application stores, sends, renews, and invalidates authentication tokens or when comparing authentication architectures.

## Begin with a threat model

Identify token types, privileges, lifetimes, storage locations, origins, third-party scripts, XSS exposure, CSRF exposure, deployment transport, SSR boundaries, and server-side revocation capabilities. Do not recommend storage in isolation from this model.

## Preferred baseline

- Use short-lived access tokens.
- Keep access tokens in memory when the architecture allows it.
- Store refresh tokens in `Secure`, `HttpOnly`, narrowly scoped cookies.
- Use `SameSite` plus a deliberate CSRF defense appropriate to the deployment.
- Rotate refresh tokens and detect reuse on the server.
- Clear and revoke the server session on logout.
- Enforce authorization server-side on every protected operation.

## Audit workflow

1. Trace token creation, storage, reads, transport, refresh, logging, and deletion.
2. Search for tokens in `localStorage`, `sessionStorage`, URLs, analytics, error reports, and serialized page data.
3. Review cookie flags, CORS, credential mode, CSP, dependency exposure, and unsafe HTML injection.
4. Inspect refresh concurrency, retry limits, failure handling, rotation, and session revocation.
5. Verify that client-side route guards do not substitute for API authorization.
6. Rank findings by exploitability, privilege, exposure duration, and affected users.
7. Separate frontend fixes from backend or infrastructure requirements.

## Important distinctions

- `sessionStorage` remains readable by injected scripts.
- `HttpOnly` reduces token theft by JavaScript but does not eliminate XSS impact.
- Cookie authentication introduces CSRF considerations.
- CSP is defense in depth, not permission to render untrusted HTML unsafely.
- JWT validation and authorization belong on trusted servers, not in browser code.

## Report format

For each finding include evidence, attack scenario, severity, affected boundary, recommended remediation, and a verification step. Avoid claiming that any single storage mechanism makes an application fully secure.