JavaScript自身が正規オリジン上で動いているため、CSRFトークンやCookieを正しく付けて危険なリクエストを送る可能性があります。

従来型CSRFでは「攻撃者サイトが直接送る」のに対し、クライアントサイドCSRFでは「正規サイトのJavaScriptを誤動作させる」という違いがあります。

対策

• URLから任意のAPIパスを作らない

• 操作名と送信先を固定マッピングする

• 許可リストを使う

• スキーム、ホスト、パスを検証する

• 認証情報変更では再確認を要求する

3-8. Cross-Site WebSocket Hijacking

WebSocketのハンドシェイクでもCookie認証を使う場合があります。

サーバーがOriginを検証しないと、攻撃者サイトから被害者のCookieを伴うWebSocket接続を開ける可能性があります。

evil.example
   │
   │ WebSocket handshake
   │ Cookie: session=...
   ▼
wss://example.com/ws/chat/

これはCross-Site WebSocket Hijacking、略してCSWSHと呼ばれます。

PortSwiggerも、WebSocketハンドシェイクを対象にしたCSRFの一種として説明しています。

Django Channelsでの対策