Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を

Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命

Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る