S3 CORS設定の各要素とレスポンスヘッダーの対応関係

  • AWS
  • S3
  • CORS

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

S3のCORS設定でハマったので、要素の対応関係を整理しておく。

設定要素とレスポンスヘッダーの対応

CORS設定の各要素は、実際のレスポンスヘッダーに次のように対応する。

設定要素 レスポンスヘッダー 備考
AllowedOrigin Access-Control-Allow-Origin * で全オリジン許可、特定オリジン指定も可
AllowedMethod Access-Control-Allow-Methods GET/PUT/POST/DELETE/HEADが指定可能
AllowedHeader Access-Control-Allow-Headers * で全ヘッダー許可も可
MaxAgeSeconds Access-Control-Max-Age プリフライト(OPTIONS)結果をブラウザがキャッシュする秒数

GETのみを許可する設定はこんな感じになる。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
        <AllowedHeader>Accept</AllowedHeader>
        <AllowedHeader>Content-Type</AllowedHeader>
        <AllowedHeader>Origin</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

読み取り専用で公開するバケットなら、こういう最小構成で十分。プリフライトが飛ぶリクエスト(カスタムヘッダー付きなど)を投げるなら、AllowedHeader に必要なヘッダーを足しておく必要がある。

AllowedOriginにnullを入れたくなる件

ブラウザは file:// からのリクエストやサンドボックス化されたiframeなどで、Origin: null というヘッダーを送ることがある。これに対応しようとして AllowedOrigin に null を追加したくなるケースがあるが、AWSの案内では非推奨とされている。

理由は単純で、null を許可リストに入れると、意図しない場所からのリクエスト(ローカルファイルを開いただけ、など)まで拾ってしまい、セキュリティ上のリスクになるから。「廃止された機能」というより「セキュリティ上入れるべきではない値」というニュアンスで理解しておくのが正確そう。

AllowedHeaderのワイルドカード

AllowedHeader は1つの文字列につき * を1つだけ含められる。たとえば x-amz-* と書けば、Amazon固有のヘッダーをまとめて許可できる。全部許可したいだけなら * 単体でよい。