Cross-Origin Resource Sharing (CORS) Misconfiguration

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Security Misconfiguration / Access Control
Typical Severity High
OWASP A01:2021 – Broken Access Control; A05:2021 – Security Misconfiguration
CWE CWE-942 – Permissive Cross-domain Policy with Untrusted Domains
Relevant Standards W3C CORS Specification (Fetch Standard); RFC 6454 (Origin)
Also known as CORS wildcard misconfiguration, permissive CORS policy, ACAO misconfiguration
Affected systems Web APIs, REST endpoints, SPAs, any HTTP server that sets CORS response headers

Overview

The Same-Origin Policy (SOP) is a browser security mechanism that prevents JavaScript on one origin (scheme + host + port) from reading responses from a different origin. The Cross-Origin Resource Sharing (CORS) protocol, defined in the WHATWG Fetch Standard, provides a controlled mechanism to relax this restriction: a server can explicitly declare which foreign origins are allowed to read its responses by setting Access-Control-Allow-Origin and related response headers.

A CORS misconfiguration occurs when a server grants cross-origin access too broadly — for example, reflecting any requested origin, trusting all subdomains without validation, or combining Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true in a way that exposes authenticated responses. An attacker who can direct a victim's browser to their site can then read the server's responses as if they were the victim, bypassing the protection the Same-Origin Policy was designed to provide.

How it works

When a browser makes a cross-origin request, it includes an Origin request header. The server's CORS policy determines whether the response is exposed to the requesting script. Common misconfiguration patterns include:

  • Origin reflection: The server reads the incoming Origin header and echoes it back verbatim in Access-Control-Allow-Origin, combined with Access-Control-Allow-Credentials: true. Any origin — including a fully attacker-controlled domain — is effectively trusted.
  • Wildcard with credentials: Returning Access-Control-Allow-Origin: * alongside Access-Control-Allow-Credentials: true. Although browsers reject this combination per the spec, some server-side frameworks do so inadvertently and misconfigured reverse proxies may alter headers downstream.
  • Weak origin validation: Checking only whether the Origin value contains or ends with a trusted string (e.g., example.com), allowing bypasses via evil-example.com or notexample.com.
  • Null origin trust: Allowing Origin: null, which can be sent by sandboxed iframes, data URIs, and certain redirects — all controllable by an attacker.
  • Trusting arbitrary subdomains: Allowing *.example.com without considering that a compromised or user-controlled subdomain (e.g., via subdomain takeover) would be implicitly trusted.

Exploitation follows a straightforward cross-site request pattern: the attacker hosts JavaScript on their domain that fetches the target API endpoint, reads the response body (which may contain session tokens, PII, or business-critical data), and exfiltrates it. Because the browser attaches the victim's cookies to the request, the response is fully authenticated.

Business impact

A successfully exploited CORS misconfiguration on an authenticated endpoint can lead to:

  • Account takeover: Stealing session tokens, OAuth tokens, or API keys returned in responses.
  • Sensitive data exposure: Reading personal data, financial records, internal configuration, or intellectual property from JSON APIs — a direct breach under GDPR, HIPAA, PCI-DSS, and similar regulations.
  • Privilege escalation: On internal APIs only accessible to privileged roles, an attacker who tricks an administrator into visiting a malicious page can read admin-only data.
  • Reputational and regulatory harm: Data breaches attributable to application-layer misconfigurations are increasingly scrutinised by regulators and carry significant financial penalties.

How to fix it

  1. Maintain an explicit allowlist of trusted origins. Compare the incoming Origin header against a server-side set of known-good origins using exact string matching. Never use substring or suffix checks alone.
  2. Never reflect the request Origin header without validation. If the logic is response.setHeader('Access-Control-Allow-Origin', request.headers.origin) without any check, every origin in the world is trusted.
  3. Do not allow the null origin for production endpoints. Treat null as untrusted unless there is an explicit, documented requirement.
  4. Use a wildcard (*) only for fully public, unauthenticated resources. Never combine Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true.
  5. Set Access-Control-Allow-Credentials: true only when strictly necessary and only in conjunction with a specific, validated origin in Access-Control-Allow-Origin.
  6. Restrict Access-Control-Allow-Methods and Access-Control-Allow-Headers to the minimum set actually required by the application.
  7. Set the Vary: Origin response header whenever the Access-Control-Allow-Origin value is dynamically computed, so that caches do not serve one origin's response to another.
  8. Audit third-party libraries and reverse proxy configurations (e.g., nginx, API gateways) that may add or override CORS headers independently of application logic.
  9. Apply CORS policies server-side, not in client-side code. Browser-side workarounds are not a security control.

Sensagraph automatically detects permissive and misconfigured CORS policies during continuous scanning of web applications.

References

Frequently asked questions

Yes. While CORS preflight (OPTIONS) applies to non-simple requests, simple GET and POST requests with certain content types are sent directly. If the server's CORS policy is permissive, the browser will expose the response body to the requesting script regardless of the HTTP method used.

Not inherently. A wildcard is safe for fully public, unauthenticated resources such as a public CDN or an open dataset API. It becomes dangerous when used for endpoints that serve authenticated or user-specific data, or when browsers receive credentials (cookies, HTTP auth) with the request.

No. Exploitation requires a victim's browser to visit an attacker-controlled page and initiate the cross-origin request. CORS mitigations are enforced by the browser, so server-to-server requests are unaffected. The attack vector is therefore social engineering or malvertising to direct users to the attacker's site.

CORS controls whether a browser exposes a server's response to cross-origin JavaScript. CSP controls which resources (scripts, styles, etc.) a page is allowed to load. They address different aspects of cross-origin security and should both be configured correctly; one does not substitute for the other.

When a server dynamically sets Access-Control-Allow-Origin based on the requesting origin, the response is origin-specific. The Vary: Origin header instructs caches to store separate response copies per origin. Without it, a cache might serve a response permitting origin A to a request from origin B, silently widening the CORS policy.