CORS response header analyzer
Paste HTTP response headers or Access-Control-* lines, add the Origin, method, request headers, credentials, and PNA context, and check locally whether the browser would expose this cross-origin response.
Local analysis only: no target URL request, no OPTIONS preflight, no current-page URL read, no upload, and no URL or browser storage writes. Input limit is 64 KiB. CORS controls whether browsers expose cross-origin responses; it is not authentication, authorization, or a complete security conclusion.
Request scenario (optional)
Origin, method, request headers, credentials, and PNA are used only for local browser-behavior simulation. Empty fields use the default GET scenario.
| Header | Value | Analysis | Notes |
|---|---|---|---|
| Waiting | |||
Findings and hints
Run analysis to show scenario blocks, review items, and hints.
CORS guide
CORS boundary
CORS controls whether browser scripts can read a cross-origin response. It does not replace server-side authentication, authorization, CSRF protection, or data classification.
Preflight triggers
Non-simple methods, non-CORS-safelisted request headers, POST application/json, and PNA contexts commonly involve browser CORS-preflight cache behavior.
Credentials and wildcard origins
With credentials, Access-Control-Allow-Origin cannot be *. Access-Control-Allow-Credentials is effective only when the value is exactly true.
PNA / LNA note
Access-Control-Allow-Private-Network: true remains useful as a PNA compatibility diagnostic. Chrome's current public direction is a Local Network Access permission prompt replacing the paused PNA preflight effort. Confirm behavior in the target browser, version, enterprise policy, and experiment state.
Server-side reminders
Dynamic or reflected Origin handling must start with a server allowlist and use Vary: Origin for shared cache isolation. Do not reflect arbitrary Origin values.