CSRF 対策はいまだに Token が必須なのか?
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
Origin 解体新書
Web 技術解体新書 第一章 Origin 解体新書 Same Origin Policy とは Web において非常に重要なセキュリティモデルの 1 つだ fetch や XHR でリクエストを送信したときに、 CORS 違反で失敗したり、 Preflight という謎のリクエストが送信されたりして悩んだ経験があるかもしれない。これらは全て、ユーザを保護するために設けられた Same Origin Policy という制限を、ブラウザが遵守した結果なのだ。 本書はこの重要な Origin という概念について、そもそもなぜそんなものが必要なのかという背景や、それがユーザを保護するメカニズム、 JSONP はなぜ危険なのか、 Preflight が飛ぶ理由、 Service Worker など新しい API との連携、 Spectre によって発覚した脆弱性と CORP,COOP,COEP,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
