协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
token-storage-security在审查认证实现、设置新认证系统或评估当前令牌存储方式是否使应用暴露于基于 XSS 的令牌窃取时使用。
AI 翻译
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
localStorage is accessible to any JavaScript running on the page. A single XSS vulnerability — including one in a third-party script — can exfiltrate all tokens silently. httpOnly cookies are completely invisible to JavaScript; even if an attacker executes arbitrary code on the page, they cannot read the cookie. This single architectural choice eliminates the most common token theft vector.
Check whether authentication tokens are stored in httpOnly cookies or in JavaScript-accessible storage like localStorage. Verify that POST, PUT, PATCH, and DELETE requests also require a CSRF token or an equivalent anti-forgery control.
Move token storage from localStorage/sessionStorage to httpOnly cookies set by the server, and ensure the cookies have Secure and SameSite flags. Add CSRF protection to every state-changing route that relies on browser-sent credentials.
Explain why localStorage is vulnerable to XSS token theft and how httpOnly cookies mitigate this attack vector.
Review authentication flows, token storage calls, and API client code. Flag any use of localStorage.setItem, sessionStorage.setItem, or document.cookie for storing access tokens, JWTs, or session identifiers. Also flag credentialed mutations that lack a CSRF token, Origin check, or same-site enforcement.
For full implementation details, code examples, and framework-specific guidance,
see references/rule.md.
Rule page: https://frontendchecklist.io/rules/security/token-storage-security