1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

CORS対応

1
Posted at

前提:CORSとは

CORS は

👉 別ドメインからのアクセスをブラウザが制御する仕組み

です。

例👇

  • フロント:https://app.example.com
  • API:https://api.example.com

👉 別オリジン → CORSが必要


通常の流れ

本来は👇

👉 オリジンサーバー(APIやS3)がCORSヘッダを返す


CloudFrontがCORSハンドリングするとは

Amazon CloudFront を使うと👇

👉 オリジンの代わりにCloudFrontがCORSレスポンスを制御できる


具体的に何をするのか

CloudFrontはレスポンスにこういうヘッダを付けます👇

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

👉 ブラウザはこれを見て許可判断する


どうやってやる?

主に2パターン👇


① Response Headers Policy(推奨)

CloudFrontの設定で👇

👉 CORSポリシーを設定するだけ

例:

  • 全オリジン許可
  • 特定ドメインのみ許可

② Lambda@Edge / CloudFront Functions

👉 より細かい制御

  • 動的にOrigin判定
  • 条件分岐

メリット

👉 オリジン側を変更しなくていい

例えば👇

  • Amazon S3
  • 外部API

👉 そのままでもCORS対応できる


よくある誤解

❌ CloudFrontがCORSそのものを判断する

→ 実際に判断するのはブラウザ

👉 CloudFrontは「ヘッダを付けるだけ」


❌ オリジン設定は不要

→ ケースによる

👉 認証や複雑な処理はオリジン側も必要


いつ使う?

👉 こういうとき便利

  • S3の静的サイト+フロント分離
  • API Gatewayの前段
  • 複数オリジン統一

まとめ

👉 CloudFrontのCORSハンドリング =

  • レスポンスヘッダをCloudFrontで付与
  • ブラウザのCORSチェックを通すための調整
  • オリジンの代替として機能

一言で

👉 「CORS対応をオリジンではなくCloudFront側でやる」


結論から言うと、
👉 **S3+CloudFrontの正しいCORS構成は「責務を分けること」**です。

  • S3:実体(データ)と最小限のCORS
  • CloudFront:配信と最終的なCORS制御

この形にすると、トラブルが一番少ないです。


✔ 全体構成(まずイメージ)

ブラウザ
   ↓
CloudFront(CORS制御)
   ↓
S3(オリジン)

✔ 正しい役割分担

■ Amazon S3

👉 基本はシンプルに

  • 必要最低限のCORSだけ設定
  • もしくは未設定でもOK(CloudFrontで吸収する場合)

■ Amazon CloudFront

👉 ここでCORSを“完成させる”

  • Response Headers Policyで制御
  • ブラウザに返す最終ヘッダを管理

✔ 推奨構成(実務で安定)

① CloudFrontにCORS設定(これがメイン)

CloudFrontで👇

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

を設定

👉 これが「CORSハンドリング」


② Origin Request Policy(重要)

👉 Origin ヘッダをS3に転送

これをやらないと👇

❌ CORS判定がズレる


③ OPTIONS(プリフライト)対応

👉 CloudFrontで許可

  • GET / HEAD だけじゃなく
  • OPTIONS も通す

✔ S3側の設定(最低限)

例👇

[
  {
    "AllowedOrigins": ["https://example.com"],
    "AllowedMethods": ["GET"],
    "AllowedHeaders": ["*"]
  }
]

👉 ただし

👉 CloudFrontで完全制御するなら緩めでもOK


✔ よくある失敗(かなり重要)

❌ ① S3だけでCORSやろうとする

👉 CloudFront通るとヘッダ変わる


❌ ② Originヘッダを転送していない

👉 ブラウザ:
「CORS NG」


❌ ③ OPTIONSを許可していない

👉 プリフライトで落ちる


❌ ④ ワイルドカード乱用

Access-Control-Allow-Origin: *

👉 認証付きだとNG


✔ 安全な設定パターン

■ シンプル(静的サイト)

  • Allow-Origin:フロントのURL
  • Methods:GET, HEAD
  • Headers:*

■ API連携あり

  • Allow-Origin:特定ドメイン
  • Methods:GET, POST, OPTIONS
  • Credentials:true(必要なら)

✔ 一言でまとめ

👉 CORSはCloudFrontで統一管理、S3は最小限


✔ 実務での最適解

👉
「CloudFrontのResponse Headers PolicyでCORSを定義し、Originヘッダを転送した上で、S3は最小限の許可設定にする」


✔ 最後に(重要)

CORSは

👉 “どこでやるか”を決めないいけない


1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?