WHATWG, Fetch詳しくないので間違いがあればご指摘下さい
Content Security Policy(CSP)やHPKPやExpect-CTでは、ユーザエージェントはセキュリティの違反を検出した際に、指定したURLにレポートを送信できる。
例えば、下記のようにHTTPレスポンスヘッダにreport-uriでレポート先を指定します (詳細は それぞれの仕様及び、Reporting APIの仕様を参照)。
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
expect-ct: enforce;max-age=3600;report-uri=https://example.com/report-uri
もちろん、ブラウザが今開いてるURLとは別ドメインのURLを指定することも出来る。これは、特に証明書に関わるセキュリティ違反が起こったときにレポートを送信するので、そのドメインは信頼できないということもある。
expect-ctに関しては、以前書いたとおり
asnokaze.hatenablog.com
report-uriとCORS
今年 7月のIETF99において、expect-ctの標準化に伴いレポート時のCORSに関するISSUEがとりあえげられた(発表資料はコチラ)。
レポート機能におけるCORSをどうするか、preflightを送るのか？送るのであればoriginヘッダに何を設定するかという話である。
選択肢として
- a. preflight を送る(Originヘッダはnull)
- b. ホワイトリストに含まれる text/plain で送る
- c. CORSを違反する
その後の議論によって、expect-ctの仕様ではなくFetch側での議論に場所を移す。
(余談だが、W3C側のCORSの仕様はFetchの方がデファクトになっているため、廃止が検討されている。Proposed Obsolete for CORS)
Document CORS safelist exceptions
Github場でのIssueもFetch側に移行し
- Form-encode Expect-CT report bodies? · Issue #356 · httpwg/http-extensions · GitHub
- What to do about requests that should (maybe) preflight but don't? · Issue #567 · whatwg/fetch · GitHub
その後、一部のContent-Typeを例外扱いにするプルリクエストが出されている（現時点ではマージされていない）
github.com
そのなかでは、「application/csp-report」「application/expect-ct-report+json」「application/report」「application/ocsp-request」を例外としてしている。
これによってレポートを送る際にCORSは不必要にな方向に向かいそうだ。
今月行われるW3C TPACK 2017のWebAppSec WGのアジェンダにもCORSが上げられているのでそこでも議論されるものと思われる。
