# CORS Policy Configuration
Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which origins can access resources on a web server. CORS extends the Same-Origin Policy by allowing servers to specify permitted origins, methods, and headers through HTTP response headers, enabling legitimate cross-origin requests while preventing unauthorized access.
The Same-Origin Policy, enforced by web browsers since the 1990s, restricts web pages from making requests to a different domain, protocol, or port than the one serving the page. This policy prevents malicious websites from reading sensitive data from other sites through JavaScript. However, it also blocks legitimate use cases: single-page applications serving content from multiple domains, APIs hosted separately from frontend applications, and modern web architectures where resources are distributed across content delivery networks and microservices.
CORS emerged as the controlled relaxation of same-origin restrictions. Rather than an all-or-nothing approach, CORS allows servers to explicitly declare which external origins can access their resources. A server can specify that only https://app.example.com can read its API responses, while blocking access from all other domains. This granular control enables modern web applications while preserving cross-origin security boundaries.
CORS sits at the intersection of browser security policies and server configuration. Browsers enforce the mechanism by checking server-provided headers before allowing cross-origin requests to proceed. The server declares its access policy through specific HTTP headers, and the browser acts as the enforcement point. Misconfigurations at the server level can completely undermine the protection, making CORS policy management a critical security control for any organization exposing web APIs or resources.
CORS operates through two distinct request flows: simple requests and preflight requests. The browser determines which flow applies based on the HTTP method, headers, and content type of the outgoing request.
Simple requests include GET, POST, and HEAD methods with standard headers and content types that would be possible through HTML forms. When a web page at https://app.example.com makes a simple cross-origin request to https://api.service.com, the browser includes an Origin header indicating the requesting domain. The request proceeds immediately to the target server.
GET /api/data HTTP/1.1
Host: api.service.com
Origin: https://app.example.comThe server processes the request and includes CORS headers in its response. The critical header is Access-Control-Allow-Origin, which specifies which origins can read the response:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json
{"data": "sensitive information"}The browser compares the Access-Control-Allow-Origin value against the requesting origin. If they match, the response is delivered to the JavaScript code. If not, the browser blocks access to the response data and logs a CORS error to the console.
Preflight requests apply to all other cross-origin requests: those using PUT, DELETE, or PATCH methods, requests with custom headers like Authorization or X-API-Key, or POST requests with JSON content types. For these requests, the browser first sends an OPTIONS request to the target server to determine if the actual request is permitted.
OPTIONS /api/data HTTP/1.1
Host: api.service.com
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization, Content-TypeThe server responds with its CORS policy for that endpoint:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, PUT, POST
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400If the preflight response permits the intended request, the browser proceeds with the actual request. If not, the request is blocked before any data is transmitted.
Credential handling adds complexity. By default, cross-origin requests do not include cookies, HTTP authentication, or client certificates. To include credentials, the client-side code must explicitly set the withCredentials flag or credentials option. The server must respond with Access-Control-Allow-Credentials: true, and Access-Control-Allow-Origin cannot be a wildcard when credentials are involved.
The wildcard () in Access-Control-Allow-Origin allows any origin to read the response, but only for requests without credentials. This creates a common misconfiguration where developers attempt to combine Access-Control-Allow-Origin: with Access-Control-Allow-Credentials: true. Browsers reject this combination, but developers sometimes work around the restriction by dynamically reflecting the Origin header value, which eliminates all cross-origin protection.
Preflight caching through Access-Control-Max-Age reduces the performance overhead of CORS checks. The browser caches the preflight response for the specified duration, allowing subsequent matching requests to proceed without additional OPTIONS requests. However, caching also means that CORS policy changes may not take effect immediately for clients that have cached previous responses.
CORS misconfigurations rank among the most common and dangerous web application vulnerabilities. The OWASP Top 10 API Security Risks specifically calls out server-side request forgery enabled by permissive CORS policies. The fundamental risk is that CORS errors break the same-origin security model that protects user data from cross-site attacks.
The most critical misconfiguration is reflecting the Origin header without validation. When a server automatically sets Access-Control-Allow-Origin to match whatever value appears in the Origin header, it effectively disables all cross-origin protection. An attacker can host a malicious page that makes authenticated requests to the vulnerable application, stealing user data or performing unauthorized actions. This pattern appears frequently in applications where developers encounter CORS errors during testing and implement a quick fix that reflects all origins.
Consider a banking application with this misconfiguration. A user visits a malicious website while remaining logged into their online banking session in another tab. The malicious site makes a cross-origin request to the bank's API. Because the server reflects the Origin header, the browser allows the request to proceed with the user's banking session cookies. The attacker can now read account balances, transaction history, or initiate transfers.
Wildcard misuse represents another common failure mode. Setting Access-Control-Allow-Origin: * opens resources to any website on the internet. While acceptable for truly public APIs, this configuration becomes dangerous when applied to endpoints that return user-specific data or accept state-changing operations. The combination with credential support (Access-Control-Allow-Credentials: true) is impossible with wildcards, but developers often work around this limitation in ways that break security.
Null origin allowlisting creates subtle attack vectors. The null origin appears in several scenarios: sandboxed iframes, data URLs, and file:// scheme documents. Attackers can craft pages that generate null origins and access applications that mistakenly allow them. This attack vector is particularly effective because null origins often bypass origin validation logic that checks for specific domain patterns.
Regular expression errors in origin validation enable bypass attacks. A configuration intended to allow https://app.example.com might use a regex pattern that also matches https://malicious-app.example.com.evil.com or similar variations. These pattern-matching errors are difficult to catch in testing but create reliable attack vectors for knowledgeable adversaries.
The business impact extends beyond data theft. CORS vulnerabilities enable cross-site request forgery attacks against APIs, potentially allowing unauthorized transactions, configuration changes, or data manipulation. In regulated industries, CORS misconfigurations can lead to compliance violations when customer data becomes accessible to unauthorized origins. The vulnerability is particularly damaging because it often affects applications' most sensitive endpoints: user profile APIs, financial transaction interfaces, and administrative functions.
CORS policy configuration falls squarely within the Vulnerable Software Development (VSD) domain of CDA's Principled Defense Model. Poor CORS implementation represents a fundamental breakdown in secure development practices, where security controls are retrofitted after functionality rather than designed into the application architecture from the beginning.
CDA's approach to CORS assessment differs significantly from conventional vulnerability scanning. Standard security tools often miss CORS misconfigurations because they require understanding the intended access patterns for each application. A wildcard CORS policy might be appropriate for a public documentation site but catastrophic for a user management API. CDA's C-BUILD methodology addresses this through application-specific threat modeling that maps each endpoint's intended access patterns against its actual CORS configuration.
During C-BUILD web application security assessments, CDA operators manually test CORS policies using crafted requests that expose common misconfigurations. This includes testing for origin reflection by submitting requests with attacker-controlled domains, checking for null origin acceptance through sandboxed iframe attacks, and verifying that credential-enabled endpoints properly restrict allowed origins. The testing goes beyond automated scanning to understand how CORS policies interact with application authentication and session management.
CDA's Continuous Surface Reduction methodology applies directly to CORS configuration. The principle "Every surface you expose is a surface we eliminate" translates to minimizing cross-origin access to the smallest set of origins and endpoints necessary for legitimate functionality. Rather than configuring CORS reactively when cross-origin errors appear, CDA advocates for proactive access control design that starts with zero cross-origin permissions and adds only the minimum necessary exceptions.
This approach contrasts sharply with the industry standard practice of implementing CORS as an afterthought to resolve browser errors. Most organizations discover CORS requirements during integration testing when cross-origin requests fail. The typical response is to add increasingly permissive CORS headers until the application works, often resulting in wildcard configurations or origin reflection patterns that eliminate security protections.
CDA's security posture reviews include CORS configuration auditing as a standard deliverable. This involves reviewing application architecture documentation to understand intended cross-origin relationships, auditing server configurations for CORS header implementation, and testing actual browser behavior with various origin combinations. The review identifies gaps between intended access patterns and implemented policies, often revealing that applications grant far broader cross-origin access than their architecture requires.
The VSD domain ownership ensures that CORS fixes integrate into the software development lifecycle rather than being treated as operational security patches. CDA works with development teams to implement CORS policies during the design phase, using explicit origin allowlists, avoiding dynamic origin reflection, and implementing automated testing that validates CORS behavior as part of the continuous integration pipeline.
CDA's perspective recognizes that CORS is fundamentally an access control mechanism that requires the same rigor as any other security boundary. The browser enforcement provides a false sense of security because misconfigured server policies can completely bypass the protection. Effective CORS security requires understanding the trust relationships between different application components and implementing server-side policies that reflect those relationships accurately.
• CORS misconfigurations disable same-origin protections and enable cross-site data theft attacks against authenticated users • Origin header reflection without validation is the most dangerous CORS misconfiguration, effectively allowing any website to access protected resources • Wildcard Access-Control-Allow-Origin policies should never be used with credential-enabled endpoints or sensitive data APIs • CORS policies must be designed proactively based on application architecture rather than reactively added to fix browser errors • Regular auditing of CORS configurations is essential because policy changes can introduce vulnerabilities in previously secure applications
• Same-Origin Policy Enforcement • Web Application Security Assessment • API Security Configuration • Continuous Surface Reduction Methodology • Vulnerable Software Development Controls
• NIST SP 800-95, "Guide to Secure Web Services" - Section 4.2.3 Cross-Origin Resource Sharing Controls • OWASP API Security Top 10 2023 - API7:2023 Server Side Request Forgery • W3C Cross-Origin Resource Sharing Specification - https://www.w3.org/TR/cors/ • CIS Controls Version 8 - Control 16.3 Secure Application Development • MITRE ATT&CK Framework - T1056.001 Cross-Origin Resource Sharing Policy Bypass