セキュリティ・認証 / Webセキュリティ
ACAOとは
Access-Control-Allow-Origin。どのOriginからのブラウザアクセスを許可するか示すCORSヘッダーです。
用語集内のカードを見るセキュリティ・認証 / Webセキュリティ
Access-Control-Allow-Origin。どのOriginからのブラウザアクセスを許可するか示すCORSヘッダーです。
用語集内のカードを見るACAOを、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。
実務メモ
ACAOはSPAからAPIを呼ぶ構成、認証付きAPI、管理画面、SaaS連携、CDN配信で効きます。curlは成功するのにブラウザだけ失敗するCORS調査で重要です。
証跡にはリクエストOrigin、API URL、ACAO値、Credentials有無、Vary: Origin、OPTIONS応答、本リクエスト応答、CDNキャッシュ条件、ブラウザエラー全文を残します。
認証情報付きでACAOに*は使えません。Originの動的反射を許可リストなしで行うと広すぎる許可になり、Vary: OriginがないとCDN経由で別Origin向け応答が混ざることがあります。
ACAO(Access-Control-Allow-Origin)は、どのOriginからのブラウザアクセスを許可するかを示すCORS応答ヘッダーです。API公開、SPA、管理画面、SaaS連携で確認します。
実務では、Origin、許可リスト、Access-Control-Allow-Credentials、Vary: Origin、プリフライト、CDNキャッシュ、動的反射、認証Cookieとの関係を確認します。
証跡には、リクエストOrigin、API URL、ACAO値、Credentials有無、Varyヘッダー、OPTIONS応答、本リクエスト応答、ブラウザエラー全文を残します。
認証情報を含まない単純な公開APIでは、ACAOに*を使う設計もあります。一方、CookieやAuthorizationを使う認証付きリクエストでは、Credentialsと*は併用できません。
認証付きAPIでは、許可Originを明示して返します。フロントエンドのOriginとAPI側の許可リストが完全一致しているかを確認します。
リクエストのOriginをそのままACAOへ反射する実装は、許可リストなしだと広すぎる許可になります。反射する場合でも、信頼済みOriginだけに限定します。
OriginごとにACAOを変える場合は、Vary: Originを返さないとCDNやプロキシで別Origin向けの応答が再利用されることがあります。再現が不安定なCORS障害の原因になります。
ACAOは本リクエストだけでなく、OPTIONSプリフライト応答にも必要です。Allow-MethodsやAllow-Headersが不足していると、ACAOが正しくてもブラウザは本リクエストへ進みません。
WAF、認証ミドルウェア、API GatewayがOPTIONSを拒否していないかを確認します。ブラウザNetworkでOPTIONSと本リクエストを分けて見ます。
ACAO対応では、許可Origin、対象API、認証情報有無、Vary、プリフライト、CDN設定、変更理由を残します。フロントエンドとAPIのどちらで直したかが後から分かるようにします。
引き継ぎでは、API担当、フロントエンド担当、認証基盤担当、関連語としてCORS、Origin、Vary、Cookie、SameSiteを残すと確認しやすくなります。
同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。