| name | frontend-auth-session-security-review |
| description | Review client-side authentication and session-management code for token-storage location, cookie-flag correctness, CSRF/open-redirect exposure, and OAuth/OIDC flow choice for browser-based apps against OWASP ASVS and Session Management Cheat Sheet guidance, with the OAuth-for-browsers reference loaded only when an OAuth/OIDC flow is in scope. |
| allowed-tools | Read Grep Glob |
| metadata | {"author":"github: Raishin","version":"0.1.0","updated":"2026-07-02","category":"security"} |
Frontend Auth & Session Security Review
Purpose
Most client-side account-takeover incidents come from session-management shortcuts, not cryptographic flaws: tokens in localStorage exposed to any XSS, missing HttpOnly/Secure/SameSite cookie flags, client-only redirect validation enabling open redirects, or implicit-grant OAuth flows that current guidance has superseded. This skill reviews against OWASP ASVS session-management requirements and the current browser-based-app OAuth best practice, not outdated tutorial patterns. It exists so the review stays anchored to these four documented defect classes — token storage, cookie flags, CSRF/open-redirect, OAuth flow choice — instead of drifting into a general "auth code review."
When to use
Use this skill when the user asks to:
- review where and how auth tokens/session identifiers are stored client-side,
- audit cookie attributes (
HttpOnly, Secure, SameSite, Domain, Path) on session cookies,
- review a login/logout/session-refresh/redirect flow for CSRF or open-redirect exposure,
- review or design an OAuth 2.0/OIDC flow for a single-page or browser-based app,
- triage a session-fixation or account-takeover bug report.
Do not use this skill for:
- server-side authorization/access-control logic review (role checks, object-level permission enforcement) with no client-side session-handling angle — that is a backend authorization review, not a frontend session-security review,
- a DOM XSS or injection root-cause review with no session/auth angle — use a dedicated XSS/injection review skill; this skill treats "is there an XSS sink reachable from this token" only insofar as it changes the token-storage risk verdict, it does not hunt XSS sinks exhaustively,
- cryptographic algorithm or JWT signature-implementation review (choosing HS256 vs RS256, key-rotation mechanics) — that is a token-issuance/backend concern, not a client-side session-management concern,
- confirming that a session-fixation or CSRF bug has already been exploited in production — static review proves the structural risk, not confirmed exploitation; that requires live traffic analysis or a penetration test.
Context7 Documentation Protocol
- Resolve the OWASP Cheat Sheet Series library ID with
resolve-library-id (matched result: /owasp/cheatsheetseries) before citing any session-cookie-flag, CSRF-defense, or open-redirect-prevention claim; use query-docs against it to ground the exact flag/pattern being recommended (e.g., __Host- prefix requirements, SameSite=Strict vs Lax tradeoffs, synchronizer-token vs double-submit-cookie pattern).
- For OAuth/OIDC flow-choice claims (PKCE requirement for public clients, implicit-grant removal), resolve and query
/websites/datatracker_ietf_doc_draft-ietf-oauth-v2-1 (OAuth 2.1, which formalizes the browser-based-app guidance: implicit and hybrid flows removed, PKCE required for public clients). This is an IETF draft and its exact section numbers/text shift between draft revisions — label version-specific text as documentation-based, verify against current draft revision, not as ratified RFC text.
- Do not conflate the OAuth 2.1 draft's PKCE-for-public-clients requirement with a guarantee that a specific SDK or framework already implements it correctly — verify the actual library/SDK in use (via its own docs or Context7 entry, if one exists) before asserting the app's flow is compliant.
- If Context7 is unavailable for either library, fall back to the
official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.
- Read
package.json (and any auth-library config) first to confirm which auth pattern is actually wired up (cookie-session middleware, an OAuth/OIDC client SDK, a hand-rolled fetch-based token flow) before recommending a fix — do not prescribe a pattern the app's architecture cannot support without a larger refactor being made explicit.
Lean operating rules
- First classify the app architecture: traditional server-rendered app using cookies for session state, vs. SPA/browser-based app calling an API with bearer tokens. The correct token-storage and CSRF-defense pattern differs by architecture — a cookie-flag finding does not apply to a pure bearer-token SPA, and vice versa. State this classification explicitly before any other finding.
- Never bless
localStorage/sessionStorage for session or access tokens as a default recommendation. If the codebase already uses it, treat it as a finding (XSS-exposure risk: any injected script can read it) and only accept it as a deliberate, justified tradeoff if the user explicitly argues the tradeoff and no unresolved XSS-sink concern exists in the reviewed scope — this skill does not itself clear that bar, it flags it.
- Verify every session cookie has
HttpOnly, Secure, and an explicit SameSite value appropriate to the flow. SameSite=None is only acceptable paired with Secure and a documented cross-site necessity (e.g., a third-party embed); never accept SameSite=None without Secure, and never accept an unset SameSite (browser defaults vary and should not be relied on).
- For OAuth/OIDC in browser-based apps, flag the implicit grant (
response_type=token) as a finding — current guidance requires the authorization code flow with PKCE for public clients. Do not recommend implicit grant for new work under any circumstance.
- Verify redirect/return-URL parameters (post-login redirect, OAuth
redirect_uri, logout redirect) are validated against a server-side allow-list, not merely checked client-side. A client-only check (e.g., a JS regex before window.location.assign) is bypassable by directly hitting the server endpoint with the malicious parameter and is not a valid control on its own.
- Never ask for or print real tokens, cookies, session IDs, or OAuth client secrets during review; use placeholder or redacted values in every example and finding.
- Check that logout actually invalidates the session/token server-side (revocation call, server-side session-store deletion), not just clears client-side storage — a client-only logout leaves the token valid for replay until natural expiry.
- Load only the reference needed for the concern in scope; never load the OAuth reference when no OAuth/OIDC flow is present in the reviewed code.
References
Load these only when needed:
- Review workflow and findings contract — use for the step-by-step review procedure, the architecture-classification decision tree, and the required output shape.
- Token storage and cookie-flag review — load when the review scope includes where tokens/session IDs are stored or how session cookies are configured.
- CSRF, open-redirect, and OAuth/OIDC flow review — load when the review scope includes a state-changing request's CSRF defenses, a redirect/return-URL parameter, or an OAuth/OIDC authorization flow. Its OAuth/OIDC subsection applies only when an OAuth/OIDC flow is actually present in scope.
Response minimum
Return, at minimum:
- the app architecture classification (cookie-based vs SPA/bearer-token) driving the recommendation,
- token-storage location finding and its XSS-exposure implication,
- cookie-flag compliance table (
HttpOnly/Secure/SameSite) if cookies are in scope,
- CSRF-defense assessment (token pattern present/absent,
SameSite reliance) for state-changing requests in scope,
- redirect/return-URL validation finding (server-side allow-list present or absent) if a redirect parameter is in scope,
- OAuth/OIDC flow assessment (PKCE-based authorization code vs deprecated implicit) only if an OAuth/OIDC flow is in scope,
- evidence level per finding (
repo evidence, documentation-based, or inference),
- explicit statement that no live session hijacking, token replay, or CSRF exploitation was performed — this is a static review,
- verdict (approve / approve-with-notes / block) and open questions the review could not resolve statically.
