Content Security Policy(CSP) レポートのCORSと、Fetchの仕様変更

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側に移行し

その後、一部のContent-Typeを例外扱いにするプルリクエストが出されている(現時点ではマージされていない)
github.com

そのなかでは、「application/csp-report」「application/expect-ct-report+json」「application/report」「application/ocsp-request」を例外としてしている。

これによってレポートを送る際にCORSは不必要にな方向に向かいそうだ。

今月行われるW3C TPACK 2017のWebAppSec WGのアジェンダにもCORSが上げられているのでそこでも議論されるものと思われる。