Remediating Over-Permissive CORS Whitelist Findings

Over-Permissive Cross-Origin Resource Sharing (CORS) Whitelist Findings are scanned as part of the Security Misconfiguration Vulnerabilities Security Tests used to evaluate the Web Application Security Risk Vector.

We assess whether the web server responds with an Access-Control-Allow-Origin header that includes a wildcard value (*), allowing any origin to access the resource.

Need to fix?

• Review your CORS policy for the Access-Control-Allow-Origin header.
• Remove the wildcard * and only allow trusted, required domains.
• Set CORS permissions to the minimum set of sites and permissions needed for your application.

Example:

Access-Control-Allow-Origin: https://your-trusted-domain.com

This reduces the risk of malicious sites abusing user credentials or sessions.

What is the risk? Using a wildcard in CORS headers creates a highly permissive environment where any external site can interact with your resources, which can:

• Lead to unauthorized access to APIs,
• Increase the risk of data leakage,
• Weaken the overall access control of your web services.

How can I check for overly permissive CORS whitelist in my web application? Use Chrome Developer Tools (Network tab) to inspect the response headers of your web application. Look for the Access-Control-Allow-Origin header. If its value is *, update your configuration to restrict it to only trusted domains.

Does this impact my WAS Risk Vector Grade? Yes.

Possible Grades:

• Good: Weight = 0
• Warn: CORS policy is overly permissive; Weight = 10

What will I see in the Portal?

Details: The web application uses a cross-domain policy file that includes domains that should not be trusted. This allows malicious websites to abuse customer credentials and sessions and perform any action on behalf of a user.