CORSの認証情報設定に矛盾がないとは？Access-Control-Allow-Credentialsの正しい使い方・診断基準・設定例

CORSの認証情報設定に矛盾がないとは（Access-Control-Allow-Credentialsの確認）

CORSの認証情報設定に矛盾がないとは、Access-Control-Allow-Credentials: true を、全オリジンを意味する * や、誰でも作り出せる null オリジンと組み合わせていない状態のことです。セキュリティAIチェッカーはこの項目（headers.cors-credentials）で、トップページの応答にこの危険な組み合わせがないかを確認します。

CORSでは、Cookieやログイン情報（認証情報、credentials）を伴うクロスオリジン要求の応答を外部サイトに読ませるかどうかを、Access-Control-Allow-Credentials: true ヘッダーで制御します。このヘッダーを返すということは、「ログイン中の利用者の権限で取得したデータを、許可したオリジンのJavaScriptに渡してよい」という強い許可を意味します。

そのため、認証情報の許可は、信頼できる具体的なオリジンだけと組み合わせなければなりません。

認証情報付きCORSの仕組み（Fetch StandardのCORS check）

WHATWG Fetch StandardのCORS checkでは、次の順で判定されます。

1. Access-Control-Allow-Origin がなければ失敗。
2. 認証情報なしの要求で値が * なら成功。
3. 値が要求元オリジンのシリアライズ結果と一致しなければ失敗。
4. 認証情報なしなら成功。
5. 認証情報ありの場合、Access-Control-Allow-Credentials が true なら成功、それ以外は失敗。

MDNも、ワイルドカードと認証情報を併用しようとするとエラーになり、Access-Control-Allow-Credentials の有効な値は大文字小文字を区別する true のみで、不要な場合は false を送らずヘッダー自体を省略すべきだとしています。

CORSの認証情報設定で「矛盾」とされる2つの危険な組み合わせ

null の組み合わせについては、WSTG-CLNT-07が、null オリジンを単純に反射し、特に認証情報を許可している場合、汎用ワイルドカードと同様の脆弱性になると説明し、サンドボックス化 iframe と credentials: 'include' を使った攻撃例を示しています。

具体的なオリジン＋認証情報は問題ないのか

Access-Control-Allow-Origin: https://app.city.example.lg.jp と Credentials: true の組み合わせは、仕様どおりの正しい使い方です。

ただし、その値が「要求の Origin をそのまま返した結果」であれば、任意のサイトに認証情報付きの読み取りを許すことになり最も危険です。この「反射」は Origin を付けた要求を送らないと観測できないため、関連項目「任意Originを反射しない」（未許可Originを付けたGETで反射の有無を確認）で評価します。

認証情報付きCORSについてよくある誤解

• 「* と credentials はブラウザが拒否するから無害」：その応答自体は読めませんが、設定意図の誤りを示します。修正の過程で * を「要求Originの反射」に置き換えてしまい、本当に悪用可能な状態になる事例が典型です。
• 「Access-Control-Allow-Credentials: false を返せば安全」：false は有効な値ではありません。不要ならヘッダーを出力しないのが正しい設定です。

認証情報を伴わない * / null の許可そのものは「危険なCORSワイルドカードがない」で評価します。このページの項目は、認証情報の許可との組み合わせ（矛盾）に集中しています。

CORSの認証情報設定に矛盾がないの診断基準（セキュリティAIチェッカー）

取得対象

• 入力URLへのGET（Origin ヘッダーは付けない、リダイレクト最大4回追跡）で得た最終ページの応答ヘッダー Access-Control-Allow-Origin と Access-Control-Allow-Credentials。
• Access-Control-Allow-Credentials は、値が true（大文字小文字を区別しない）のとき「認証情報を許可」とみなします。仕様上は小文字の true のみが有効ですが、True 等の表記でも許可の意図があるものとして扱います。

判定条件

• Access-Control-Allow-Origin がない応答では、認証情報の設定が有効に働く余地がなく、「矛盾がない」と積極的に評価する材料もないため対象外とします。多くの自治体公式サイトのトップページはこの状態です。
• 根拠欄には観測した Access-Control-Allow-Origin の値と、認証情報の許可有無を表示します。

自治体サイトでの判定例

CORSの認証情報設定に矛盾があるとどんなリスクがあるか

• ログイン中の個人データの窃取：null ＋認証情報、または反射＋認証情報の構成では、利用者が攻撃者のページを開いただけで、そのページのJavaScriptが利用者のCookie付きで電子申請やマイページのAPIを呼び出し、氏名・住所・申請内容などを読み取って外部へ送信できます。
• CSRFトークンの窃取：応答に含まれるCSRFトークンを読み取られると、CSRF対策が無効化され、なりすまし操作につながります。
• 設定の連鎖的な誤り：* ＋認証情報の設定は、それ自体は読み取りを許さなくても、「動かない」ことを理由に反射方式へ書き換えられ、本当に危険な状態になりがちです。

認証情報付きCORSの正しい設定方法（Apache・nginx・Express・PHP）

基本方針

1. 認証情報付きのクロスオリジン利用が本当に必要か確認する（同一オリジンで完結するなら、CORSヘッダー自体を出力しない）。
2. 必要な場合は、許可オリジンを固定のリストで管理し、要求の Origin がリストと完全一致したときだけ、その値と Access-Control-Allow-Credentials: true を返す。
3. *、null、部分一致（endsWith("example.lg.jp") 等）での許可を使わない。
4. 応答が Origin によって変わるので Vary: Origin を付ける。

Apache（.htaccess）

<IfModule mod_headers.c>
  # まず誤った一括設定を除去（生成元により格納先が異なるため両方を指定）
  Header unset Access-Control-Allow-Origin
  Header always unset Access-Control-Allow-Origin
  Header unset Access-Control-Allow-Credentials
  Header always unset Access-Control-Allow-Credentials
  # 許可リストに一致したときだけ付与
  SetEnvIf Origin "^(https://app\.city\.example\.lg\.jp)$" CORS_ALLOW=$1
  Header always set Access-Control-Allow-Origin "%{CORS_ALLOW}e" env=CORS_ALLOW
  Header always set Access-Control-Allow-Credentials "true" env=CORS_ALLOW
  Header always merge Vary "Origin"
</IfModule>

nginx

# mapはhttpコンテキスト、locationはserverコンテキストに記述
map $http_origin $cors_allow {
    default "";
    "https://app.city.example.lg.jp" $http_origin;
}
map $cors_allow $cors_cred {
    default "true";
    "" "";
}
location /api/ {
    add_header Access-Control-Allow-Origin $cors_allow always;
    add_header Access-Control-Allow-Credentials $cors_cred always;
    add_header Vary Origin always;
}

値が空文字の add_header は出力されないため、許可リストに一致しない要求にはCORSヘッダーが付きません。location 内に add_header を書くと server レベルの add_header（他のセキュリティヘッダーを含む）は継承されないため、必要なヘッダーは同じ location にも記述してください。

Node.js（Express＋cors）

const cors = require('cors');
const ALLOWED = ['https://app.city.example.lg.jp'];
app.use('/api', cors({
  origin: (origin, cb) => cb(null, ALLOWED.includes(origin) ? origin : false),
  credentials: true,
}));

origin: true（要求Originをそのまま反射）や origin: '*' と credentials: true の組み合わせは使わないでください。

PHP

<?php
$allowed = ['https://app.city.example.lg.jp'];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
header('Vary: Origin');
if (in_array($origin, $allowed, true)) {
    header('Access-Control-Allow-Origin: ' . $origin);
    header('Access-Control-Allow-Credentials: true');
}

確認方法（curl）

curl -sI https://www.city.example.lg.jp/ | grep -i '^access-control-allow-'
curl -sI -H 'Origin: null' https://www.city.example.lg.jp/api/me | grep -i '^access-control-allow-'
curl -sI -H 'Origin: https://evil.example' https://www.city.example.lg.jp/api/me | grep -i '^access-control-allow-'

2行目・3行目で null や https://evil.example と Access-Control-Allow-Credentials: true が同時に返る場合は、直ちに修正が必要です。修正後はセキュリティAIチェッカーで再診断します。

サイトを壊さないための注意点（ガードレール）

• 認証情報の許可を外すと、別オリジンの業務画面（例：申請フロントとAPIが別ドメイン）が動かなくなる場合があります。利用中のフロントエンドのオリジンを洗い出し、許可リストに登録してから不要な設定を外してください。
• CookieにSameSite属性（Lax／Strict）を設定すると、クロスサイトの認証情報付き要求自体が送られにくくなり、CORS設定の誤りに対する多層防御になります。

よくある質問（FAQ）

参考資料

• WHATWG Fetch Standard（CORS check）
• MDN Access-Control-Allow-Credentials
• MDN Access-Control-Allow-Origin
• OWASP WSTG-CLNT-07 Cross Origin Resource Sharing
• OWASP ASVS 5.0.0 V3 Web Frontend Security
• PortSwigger Web Security Academy, CORS

「CORSの認証情報設定に矛盾がない」と関連する診断項目

• 危険なCORSワイルドカードがないhigh
• 任意Originを反射しないhigh
• CORSプリフライトの許可範囲high
• 動的CORSでVary: Originを返すmedium