How to remediate – Insecure ‘Access-Control-Allow-Origin’ Header

1. Introduction

The ‘Access-Control-Allow-Origin’ vulnerability occurs when a web application incorrectly configures Cross-Origin Resource Sharing (CORS) headers, specifically by setting them to allow all origins (‘*’) or null. This allows any website to make requests to the application, potentially exposing sensitive data. Businesses face risks of data breaches and unauthorized access if this configuration is exploited. Systems commonly affected include web servers and applications using JavaScript that interact with APIs or other resources across different domains. A successful exploit could compromise confidentiality, integrity, and availability of application data.

2. Technical Explanation

The vulnerability stems from the browser’s Same Origin Policy, which restricts cross-domain requests for security reasons. CORS allows developers to selectively relax this policy. When ‘Access-Control-Allow-Origin’ is set to ‘*’, it bypasses these restrictions entirely. An attacker can then make requests from a malicious website and read responses from the vulnerable application as if they were authorized.

• Root cause: The ‘Access-Control-Allow-Origin’ header is configured with an overly permissive value, such as ‘*’ or null, instead of specific trusted domains.
• Exploit mechanism: An attacker hosts a malicious webpage that sends requests to the vulnerable application’s API endpoints. Because CORS allows all origins, the browser does not block these requests and returns the responses to the attacker.
• Scope: Web applications using JavaScript and APIs accessible from different domains are affected. This includes applications running on various platforms like Apache, Nginx, IIS, or cloud services such as AWS, Azure, and GCP.

3. Detection and Assessment

You can confirm a vulnerable system by inspecting the ‘Access-Control-Allow-Origin’ header in HTTP responses. A thorough assessment involves testing from different domains to verify unrestricted access.

• Quick checks: Use your browser’s developer tools (Network tab) to inspect the response headers for any API calls made by the application. Look for ‘Access-Control-Allow-Origin: *’ or missing header.
• Scanning: Burp Suite and OWASP ZAP can be used with active scanning rules focused on CORS misconfigurations. These are examples only, as results may vary depending on scanner configuration.
• Logs and evidence: Examine web server access logs for requests originating from unexpected domains. Look for patterns indicating cross-domain requests without proper authentication.

curl -I https://your-application-url/api/endpoint

4. Solution / Remediation Steps

Fix the issue by configuring ‘Access-Control-Allow-Origin’ to allow only known and trusted domains, or disabling it if cross-domain requests are not required.

4.1 Preparation

• Ensure you have a list of all legitimate domains that need to access the application’s APIs. A roll back plan involves restoring the original configuration file.
• Change windows may be needed for production systems, requiring approval from security and operations teams.

4.2 Implementation

1. Step 1: Identify the web server configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
2. Step 2: Locate the section that configures CORS headers for the affected API endpoints.
3. Step 3: Replace ‘Access-Control-Allow-Origin: *’ with a comma separated list of trusted domains (e.g., ‘Access-Control-Allow-Origin: https://trusted-domain1.com,https://trusted-domain2.com’). If no cross-origin access is needed, remove the header entirely.
4. Step 4: Restart the web server to apply the changes.

4.3 Config or Code Example

Before

# Apache httpd.conf
Header set Access-Control-Allow-Origin "*"

After

# Apache httpd.conf
Header set Access-Control-Allow-Origin "https://trusted-domain1.com,https://trusted-domain2.com"

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact of a successful exploit by limiting access only to trusted domains. Secure headers enforce browser security policies and block malicious requests. A regular patch cadence ensures that known vulnerabilities are addressed promptly.

• Practice 1: Implement least privilege for API access, granting permissions only to authorized users and domains.
• Practice 2: Configure secure HTTP headers like ‘Access-Control-Allow-Origin’ with specific trusted origins instead of wildcards.

4.5 Automation (Optional)

If using infrastructure as code tools, you can automate the configuration of CORS headers.

# Example Ansible task to set Access-Control-Allow-Origin header
- name: Set Access-Control-Allow-Origin header
  apache2_module:
    name: headers
    state: present
  become: true
- name: Add CORS configuration to Apache virtual host
  lineinfile:
    path: /etc/apache2/sites-available/your-site.conf
    regexp: '^Header set Access-Control-Allow-Origin .*'
    line: 'Header set Access-Control-Allow-Origin "https://trusted-domain1.com,https://trusted-domain2.com"'
  become: true
  notify: Restart Apache

5. Verification / Validation

Confirm the fix by inspecting HTTP responses and testing from untrusted domains. A service smoke test ensures that legitimate functionality remains operational.

• Post-fix check: Use curl or your browser’s developer tools to inspect the ‘Access-Control-Allow-Origin’ header for API calls. Expected output should show only trusted origins listed, or no header if CORS is disabled.
• Re-test: Repeat the quick checks from section 3 and verify that requests from untrusted domains are now blocked by the browser.
• Monitoring: Monitor web server logs for any unexpected cross-domain requests originating from unknown domains.

curl -I https://your-application-url/api/endpoint

6. Preventive Measures and Monitoring

Update security baselines to include specific CORS header configurations. Implement checks in CI/CD pipelines to prevent insecure settings from being deployed. Establish a regular patch review cycle for all web server components.

• Baselines: Update your organization’s security baseline or policy to require specific ‘Access-Control-Allow-Origin’ values instead of wildcards.
• Pipelines: Add static analysis (SAST) tools to your CI/CD pipeline to scan for insecure CORS configurations in configuration files and code.
• Asset and patch process: Review web server configurations regularly as part of a vulnerability management program, ensuring that all components are patched and secure settings are applied.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the original web server configuration file from your