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.\"
Use this skill when the user asks to:
\nHttpOnly, Secure, SameSite, Domain, Path) on session cookies,Do not use this skill for:
\nresolve-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)./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.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.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.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.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).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.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.Load these only when needed:
\nReturn, at minimum:
\nHttpOnly/Secure/SameSite) if cookies are in scope,SameSite reliance) for state-changing requests in scope,repo evidence, documentation-based, or inference),