【要約】SPAのトークン、localStorageに置いていい? OWASP ASVS 5.0で変わった答え [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がSPAの認証設計において、最新のセキュリティ基準と実装の妥当性の間で混乱が生じている。具体的には、以下の課題に直面している。
- ・旧来の知識（localStorageは一律NG）と最新のASVS 5.0との乖離。
- ・OIDC/OAuthに関連する膨大なRFC群を、実装レビュー時に網羅的に確認することの困難さ。
- ・セキュリティ統制と実装の正しさ（UXや遷移時の挙動）の混同。
// Approach
著者はASVS 5.0の変更点を整理し、設計レビューの効率化を図る手法を検証した。具体的には、以下のステップで検証を行った。
- ・ASVS 5.0のV9（自己完結トークン）、V10（OAuth/OIDC）、V14（データ保護）を主要な物差しとして定義。
- ・Claudeを用いたブラインドレビューを実施し、ASVS単体での指摘再現性を検証。
- ・ASVSのスコープと、アーキテクチャレビューの役割分担を明確化。
// Result
ASVS 5.0を適用することで、設計レビューの網羅性が大幅に向上することが示された。検証の結果、以下の成果が得られた。
- ・主要なセキュリティ指摘（aud/iss検証、Mix-up対策等）を高い精度で再現。
- ・著者の見落とし（PIIの保存、anti-cacheヘッダ不足）も検知。
- ・ASVSは「実装の正しさ」をスコープ外とするため、アーキテクチャレビューとの併用が不可欠であると判明。
Senior Engineer Insight
> セキュリティ基準のアップデートは、制約の緩和と統制の高度化を同時に求める。localStorageの容認はUX向上に寄与するが、XSS対策やタイムアウト管理の徹底が前提となる。ASVSを「RFCの辞書」としてではなく「レビューの入口」として使い、実装の妥当性はアーキテクチャレビューで補完するという、現実的な「守備範囲の切り分け」が、大規模開発におけるレビューコスト削減の鍵となる。