今回CORS（クロスオリジンリソースシェアリング）について理解が曖昧なため、AWS SAPレベルの問題内容で理解してく。
CORS は AWS 試験で派手なサービスではありませんが、
S3 / API Gateway / CloudFront / ALB 配下API / ブラウザAjax が絡むと、かなりの頻度で登場します。
特に SAP レベルでは、
「通信できない原因がネットワークではなくブラウザ制約」
であることを見抜けるかが重要です。
■ そもそも CORS とは？
CORS の役割
ブラウザ上の JavaScript から、別ドメイン（別オリジン）への HTTP リクエストを安全に許可する仕組み
同一オリジンポリシーとは？
ブラウザはデフォルトで、
- ドメイン
- スキーム（http / https）
- ポート
が異なる先への JavaScript リクエストを制限します。
例えば：
https://app.example.com
↓ Ajax
https://api.example.netこれは クロスオリジン です。
CORS で何を制御するのか
サーバー側がレスポンスヘッダーで、
- どのオリジンを許可するか
- どのメソッドを許可するか
- どのヘッダーを許可するか
- 認証情報を許可するか
を明示します。
代表例：
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, AuthorizationSAP試験での見抜きポイント
問題文に以下が出たら、CORS を最優先で疑います。
基本SAA試験でも同様
- ブラウザ
- Ajax / fetch / XMLHttpRequest
- 別ドメイン
- JavaScript から API 呼び出し
- S3 の静的Web + API Gateway
- preflight / OPTIONS
- 「curlでは成功するがブラウザでは失敗する」
ではこれらを踏まえて早速問題を見ていきましょう
■ 問題1：S3 静的Webサイトから API Gateway を呼び出せない
【問題】
ある企業は、S3 バケットでホストした静的 Web サイトを CloudFront 経由で配信しています。
フロントエンドは JavaScript の fetch を使用して、別ドメインで公開された Amazon API Gateway の REST API を呼び出します。
CLI や Postman では API 呼び出しに成功しますが、ブラウザではエラーになり、レスポンスを取得できません。
最小の変更でこの問題を解決し、必要なドメインからのみ API を利用可能にしたいと考えています。
この要件を満たす最適な実装はどれでしょうか。
■ 正解
✅ API Gateway で CORS を有効化し、S3 / CloudFront 側のフロントエンドドメインを Access-Control-Allow-Origin に明示的に設定する。
■ 構成イメージ
ユーザーのブラウザ
│
│ GET /index.html
▼
CloudFront
│
▼
S3 Static Website
│
│ fetch("https://api.example.net/items")
▼
API Gateway
┌──────────────────────────────┐
│ CORS有効化 │
│ Allow-Origin: app.example.com │
│ Allow-Methods: GET,POST │
└──────────────┬───────────────┘
▼
Lambda■ 解説
この問題の本質は API 自体は動いているが、ブラウザだけ失敗する 点です。
Postman や curl は同一オリジンポリシーの影響を受けないため成功しますが、ブラウザは CORS 制約を受けます。
したがって、解決策はネットワーク変更ではなく API Gateway 側の CORS 設定です。
SAP レベルでは、さらに
*ではなく必要なオリジンだけ許可- 最小変更で解決
を読み取れるかがポイントです。
■ 問題2：S3上の画像アップロードAPIで preflight が失敗する
【問題】
ある企業は、ブラウザから画像をアップロードできるアプリケーションを構築しています。
フロントエンドは https://portal.example.com で配信され、JavaScript から https://upload-api.example.com の API に対して PUT リクエストを送信しています。
認証トークンを HTTP ヘッダーに含めて送信する必要があります。
ブラウザの開発者ツールを見ると、実際の PUT の前に送られる OPTIONS リクエストが失敗しており、アップロードができません。
最小の修正でこれを解決するにはどうすればよいでしょうか。
■ 正解
✅ アップロード先 API で CORS を設定し、OPTIONS を許可したうえで、PUT メソッド・必要なカスタムヘッダー・許可オリジンを Access-Control-Allow-* ヘッダーで返すようにする。
■ 構成イメージ（コードベース図）
ブラウザ
│
│ OPTIONS /upload ← Preflight
▼
upload-api.example.com
┌─────────────────────────────────────┐
│ CORS設定 │
│ Allow-Origin: https://portal.example.com
│ Allow-Methods: PUT, OPTIONS
│ Allow-Headers: Authorization, Content-Type
└─────────────────────────────────────┘
│
│ PUT /upload
▼
バックエンドAPI■ 解説
PUT、Authorization ヘッダー、application/json などが絡むと、ブラウザは preflight（OPTIONS） を送ります。
この OPTIONS に正しく応答できないと、本体リクエストの前に失敗します。
SAP 試験では、
- 「PUT」
- 「Authorization ヘッダー」
- 「OPTIONS が失敗」
- 「ブラウザだけ失敗」
がセットで出たら、CORS preflight を疑うのが基本です。
■ 問題3：S3 バケット上の静的コンテンツから別ドメイン S3 バケットのJSONを読めない
【問題】
ある企業は、複数ブランド向けの静的サイトを Amazon S3 でホストしています。
各ブランドのトップページは別の S3 バケットから配信される JSON 設定ファイルをブラウザの JavaScript で取得してレンダリングします。
S3 バケットポリシーは適切に設定されており、オブジェクト自体は直接 URL で取得可能です。
しかし、ブラウザの JavaScript から取得するとエラーになります。
この問題を最小工数で解決するにはどうすればよいでしょうか。
■ 正解
✅ JSON 配信用 S3 バケットに CORS ルールを設定し、対象ブランドサイトのオリジンからの GET を許可する。
■ 構成イメージ
Brand Site A (S3 / CloudFront)
│
│ fetch("https://config-bucket.s3.amazonaws.com/site-a/config.json")
▼
Config S3 Bucket
┌──────────────────────────────┐
│ CORS Rule │
│ AllowedOrigin: brand-a.example.com
│ AllowedMethod: GET │
└──────────────────────────────┘■ 解説
S3 バケットポリシーで「取得できる」ことと、ブラウザ JavaScript から「読める」ことは別問題です。
後者には CORS 設定 が必要です。
これは SAP でも非常によくある引っかけで、
- S3 バケットポリシーはOK
- URL直打ちは成功
- JavaScript だけ失敗
なら、ほぼ CORS です。
■ 問題4：CloudFront 配下のSPAから ALB 配下API を呼ぶと一部環境だけ失敗する
【問題】
ある企業は、CloudFront 配下で SPA を配信し、バックエンド API は内部的に ALB 配下の EC2 インスタンス群で提供しています。
開発環境では同一ドメイン配下で動作していましたが、本番ではフロントエンドと API のホスト名を分離しました。
本番環境でのみ、ブラウザからの API 呼び出しが失敗し、ネットワークチームはセキュリティグループや NACL に問題がないことを確認しています。
最小の実装変更でこの問題を解決するにはどうすればよいでしょうか。
■ 正解
✅ ALB 配下 API のレスポンスに CORS ヘッダーを返すようにし、本番フロントエンドのオリジンを許可する。
■ 構成イメージ
ユーザー
│
▼
CloudFront (SPA)
│
│ fetch("https://api.example.com/orders")
▼
ALB
│
▼
EC2 API Servers
┌──────────────────────────────┐
│ Response Headers │
│ Access-Control-Allow-Origin │
│ Access-Control-Allow-Methods │
└──────────────────────────────┘■ 解説
同一ドメイン時は CORS を意識しなくて済みますが、
本番でフロントと API を分離した瞬間に クロスオリジン問題 が発生します。
この設問の見抜きポイントは、
- ネットワークは問題なし
- 本番だけ失敗
- ドメイン分離した
です。
つまり、原因は L3/L4 ではなく ブラウザ制約です。
■ 問題5：複数顧客ドメインから同一APIを利用させたいが、許可対象は限定したい
【問題】
SaaS 企業が、複数の顧客企業に対して埋め込み型の JavaScript ウィジェットを提供しています。
各顧客は自社ドメイン上にこのウィジェットを埋め込み、企業ごとの API へブラウザから直接アクセスします。
企業は、どの顧客サイトからでも使えるようにはしたいものの、無制限に全ドメインを許可したくありません。
また、顧客追加時の運用負荷も抑えたいと考えています。
この要件に対して、正しい方向性の実装はどれでしょうか。
■ 正解
✅ API 側で CORS を実装し、許可された顧客ドメインのみを動的または設定ベースで Access-Control-Allow-Origin に返す。
■ 構成イメージ
顧客Aサイト ─┐
顧客Bサイト ─┼──▶ SaaS API
顧客Cサイト ─┘
SaaS API
┌────────────────────────────────┐
│ Origin ヘッダーを確認 │
│ 許可済み顧客なら │
│ Access-Control-Allow-Origin を返す
└────────────────────────────────┘■ 解説
SAP レベルでは、単に「CORSを有効化」だけでなく、
*を返すのは危険- 顧客ごとに限定したい
- ただし顧客数が多く運用負荷も抑えたい
という、セキュリティと運用のバランスまで問われます。
この場合は、許可された Origin のみを返す実装が最適です。
■ CORSが正解になりやすい典型パターンまとめ
こんな問題ならまず CORS を疑う
・ブラウザだけ失敗する
・Postman / curl は成功する
・Ajax / fetch / XHR
・別ドメインにアクセスする
・OPTIONS / preflight が出てくる
・S3静的サイト + API Gateway
・CloudFront + 別ホストのAPI■ 一発で覚える
通信できない原因がAWSネットワークではなく
ブラウザ制約なら CORS■ まとめ
CORS は地味ですが、SAP レベルでは
- 原因切り分け
- 最小変更
- セキュリティを保った許可
- preflight 対応
まで問われます。
つまり、単なる用語暗記ではなく、
「これはネットワークの問題ではなく、ブラウザの同一オリジン制約だ」
と見抜けるかが勝負です。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
