Cookieを使わず、JavaScriptがメモリ上のアクセストークンを明示的にAuthorizationヘッダーへ付ける構成では、古典的CSRFは成立しにくくなります。

ただし、トークンをCookieへ保存して自動送信している場合や、CORSを誤設定している場合は別です。

2. CSRFの歴史

2-1. 1990年代後半から2000年代

初期のWebアプリケーションでは、認証Cookieがあれば本人の操作と判断する実装が一般的でした。

当時は次のような設計も珍しくありませんでした。

GET /account/delete?id=123
GET /admin/add-user?name=attacker
GET /transfer?to=attacker&amount=100000

攻撃者は、画像タグやリンクを利用してGETリクエストを送信させられました。

<img src="https://example.com/account/delete?id=123">

この時代は、状態変更をGETで実行する設計と、送信元を検証しない設計が大きな原因でした。

CSRFは「Session Riding」「One-Click Attack」などの呼び方でも知られるようになりました。

2-2. OWASP Top 10での扱い

CSRFは、OWASP Top 10の過去版で独立したリスクとして扱われていました。