Cross-Origin Resource Sharing (CORS) is a browser mechanism that allows controlled access to resources on a server from scripts running on other origins (domains). Misconfigured CORS occurs when a web application improperly configures its CORS policy, allowing unintended or malicious origins to access sensitive resources. Attackers can exploit such misconfigurations to bypass the Same-Origin Policy (SOP) and perform unauthorized operations, steal sensitive data, or execute malicious scripts.

Common misconfiguration patterns:

• Using Access-Control-Allow-Origin: * on endpoints that return sensitive data or support authentication.
• Reflecting the Origin header from requests directly in Access-Control-Allow-Origin without validation.
• Allowing credentials (Access-Control-Allow-Credentials: true) for untrusted or all origins.
• Missing proper validation of allowed HTTP methods, headers, or exposed response headers.

Impacts of misconfigured CORS:

• Data Exfiltration: Attacker-controlled websites can read sensitive responses from vulnerable endpoints if credentials (cookies, tokens) are sent automatically.
• Account Takeover: If sensitive session tokens are exposed through XHR/fetch requests, attackers may perform actions on behalf of authenticated users.
• Cross-Site Request Forgery Enhancement: Misconfigured CORS can bypass SOP protections, enabling attackers to combine CSRF with data exfiltration.
• Sensitive Function Exposure: APIs or endpoints that should be internal-only may be accessible to external origins.

Detection indicators:

• Inspect response headers for improper Access-Control-Allow-Origin values, especially * in combination with Access-Control-Allow-Credentials: true.
• Use automated scanners to test CORS endpoints with malicious origins and verify if responses are accessible.
• Review server-side CORS implementation and frameworks for default behaviors that may override explicit policies.
• Monitor for anomalous cross-origin requests or unauthorized data access patterns.

Properly configuring CORS requires validating origins, limiting credentials, and exposing only necessary resources to trusted domains.

1. Restrict Allowed Origins
   Explicitly define a whitelist of trusted domains in Access-Control-Allow-Origin. Never echo the incoming Origin header directly without validation.

2. Limit Credentials Exposure
   Only allow Access-Control-Allow-Credentials: true for trusted origins. Avoid combining wildcard * with credentialed requests.

3. Validate HTTP Methods
   Limit Access-Control-Allow-Methods to only the required methods (GET, POST, etc.) and avoid allowing unsafe or unnecessary verbs.

4. Restrict Headers
   Use Access-Control-Allow-Headers to permit only required headers. Do not allow all headers by default unless necessary.

5. Expose Only Necessary Response Headers
   Control Access-Control-Expose-Headers to avoid revealing sensitive headers (e.g., session tokens, internal identifiers) to untrusted origins.

6. Environment-Specific Policies
   Apply stricter CORS policies in production environments. Development environments may require broader access, but ensure production is locked down.

7. Test and Monitor
   Include automated tests for CORS misconfigurations and monitor logs for suspicious cross-origin requests.

8. Framework-Specific Guidance
   Use framework-provided CORS middleware and ensure proper configuration rather than implementing custom CORS logic from scratch.

9. Principle of Least Privilege
   Only expose endpoints to external origins when absolutely necessary. Treat all external requests as untrusted.

10. Defense-in-Depth
    Combine CORS configuration with authentication, authorization, and input validation. CORS misconfiguration should not be the sole line of defense.

• Cross-Origin Resource Sharing (CORS)
• CWE-942: Permissive Cross-domain Policy with Untrusted Domains