概要と適用範囲
WHATWG Fetch仕様に準拠するCORSプロトコルは、同一オリジンポリシー（SOP）を制御し、安全なクロスオリジンAPI連携を可能にします。
仕様一覧表＆マトリクス
キーワード、コード番号、またはディレクティブ名で即時検索
| キー / コード | 定義と詳細 | GEOセマンティック階層 | 仕様と補足 |
|---|---|---|---|
| Access-Control-Allow-Origin | Access-Control-Allow-Origin Specifies which origins are permitted to access the resource; may be a single origin or wildcard *. Access-Control-Allow-Origin: https://app.example.com | ●Access-Control-Allow-Origin ↳CORS header ↳server response permission ↳origin whitelist match | WHATWG Fetch §3.2.1 Cannot be wildcard "*" if Access-Control-Allow-Credentials is set to true. |
| Access-Control-Allow-Methods | Access-Control-Allow-Methods Specifies the HTTP methods allowed when accessing the resource in response to a preflight request. Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS | ●Access-Control-Allow-Methods ↳CORS header ↳preflight response header ↳permitted HTTP methods | WHATWG Fetch §3.2.2 Returned in response to preflight OPTIONS requests. |
| Access-Control-Allow-Headers | Access-Control-Allow-Headers Indicates which HTTP headers can be used during the actual request in response to a preflight. Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With | ●Access-Control-Allow-Headers ↳CORS header ↳preflight response header ↳permitted request headers | WHATWG Fetch §3.2.3 Must explicitly list Authorization if client attaches Bearer tokens. |
| Access-Control-Allow-Credentials | Access-Control-Allow-Credentials Tells browsers whether the response can be exposed when credentials (cookies, TLS client certificates, HTTP auth) are sent. Access-Control-Allow-Credentials: true | ●Access-Control-Allow-Credentials ↳CORS header ↳server response permission ↳cookie and session credential allowance | WHATWG Fetch §3.2.4 The ONLY valid value is the literal string "true" (case-sensitive). |
| Access-Control-Max-Age | Access-Control-Max-Age Indicates how long in seconds the results of a preflight request can be cached by the browser. Access-Control-Max-Age: 86400 | ●Access-Control-Max-Age ↳CORS header ↳preflight caching TTL ↳preflight probe reduction | WHATWG Fetch §3.2.5 Reduces latency by preventing browsers from sending an OPTIONS check on every single API call. |
| Access-Control-Expose-Headers | Access-Control-Expose-Headers Whitelist of response headers that browser JavaScript is allowed to access beyond the default safelist. Access-Control-Expose-Headers: X-Custom-Header, Retry-After | ●Access-Control-Expose-Headers ↳CORS header ↳client visibility whitelist ↳custom response header exposure | WHATWG Fetch §3.2.6 Without this, JavaScript cannot read custom headers like X-Total-Count or RateLimit-Remaining. |
Full Express.js Production CORS Configuration
import express from 'express';
import cors from 'cors';
const app = express();
const corsOptions = {
origin: ['https://app.example.com', 'http://localhost:5173'],
methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
allowedHeaders: ['Content-Type', 'Authorization', 'X-Requested-With'],
exposedHeaders: ['Retry-After', 'X-Total-Count'],
credentials: true,
maxAge: 86400, // 24 hours preflight cache
};
app.use(cors(corsOptions));Configuring explicit origins, headers, credentials, and maxAge guarantees seamless cross-origin communication.
規格標準 FAQ
Why does my request fail when I use wildcard "*" with credentials: true?↓
References & Primary Sources
Every source below directly substantiates technical statements and protocol behaviors explained in CORSヘッダー（クロスオリジン通信）リファレンス. Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.
- [1]WHATWGPrimary SpecificationWHATWG Fetch • § 3.2 HTTP-network-fetchVerified Primary SourceTechnical Claim Supported:
Defines the normative browser CORS protocol, preflight cache validation (Access-Control-Max-Age), and the prohibition of wildcard Access-Control-Allow-Origin: * when Access-Control-Allow-Credentials is true.
“For a CORS request with credentials, the server cannot specify a wildcard for Access-Control-Allow-Origin. It must specify an explicit origin.” - [2]IETFPrimary SpecificationRFC 9110 • § 9.2.1Verified Primary SourceTechnical Claim Supported:
Specifies that the Origin request header indicates the scheme, host, and port of the originating context and must not be altered by user-agent JavaScript.
- [3]OWASPAuthoritative Security StandardOWASP Cheat Sheet Series • Origin Validation & CredentialsVerified Primary SourceTechnical Claim Supported:
Documents the security risks of dynamic origin reflection without strict server-side allowlist verification (CORS misconfiguration vulnerabilities).
- [4]MDNDeveloper Authority (MDN)MDN Web Docs • CORS Preflight & Simple RequestsVerified Primary SourceTechnical Claim Supported:
Provides developer reference for simple requests vs. preflighted requests and safelisted headers (Accept, Accept-Language, Content-Language, Content-Type).
関連技術エコシステムと次の学習ステップ
おすすめの関連開発者ツール
関連技術ガイド
関連技術解説記事
What Is CORS (Cross-Origin Resource Sharing)?
The standard protocol enabling controlled cross-origin data access in modern browsers.
CSP vs CORS: Differences in Browser Defense Mechanisms
Distinguishing outbound resource loading restrictions from inbound server access control.
Troubleshooting: No Access-Control-Allow-Origin Header Present
Diagnose and fix the most common browser cross-origin blocking error with production configs.
関連する技術Q&A
Why Does CORS Allow Simple GET Requests Without a Preflight?
Answer: CORS allows simple GET requests without preflight for backwards compatibility with legacy HTML form and image behaviors that predate CORS.
Why Do Browsers Send OPTIONS Preflight Requests?
Answer: Browsers send preflights to verify that older servers not expecting cross-origin calls explicitly permit the method and custom headers before execution.
実践ハンズオン診断ラボ
次のステップへ進む
CORS Policy & Preflight Handshake Lab
Simulate preflight OPTIONS probes and adjust Access-Control-Allow-* headers inside the browser sandbox.