CORS Misconfiguration Vulnerability Explained | OWASP TOP 10 2021 : Broken Access Control


CORS or Cross-origin Resource Sharing allows web developers to work around the same-origin policy. The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission.

Cross-origin resource sharing (CORS) allows web-pages to access resources on different domains. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy. CORS defines a way in which a browser and server can interact to determine whether or not it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests.

How CORS works ?

Suppose there are two websites and, now try to access resources. Then sends OPTIONS preflight-request with an Origin HTTP header to

Origin: will respond with an Access-Control-Allow-Origin header in its response indicating which origin sites are allowed or not. If access allowed then the response header will be :


And if the server does not allow the cross origin requests then then an error page will return.

An Access-Control-Allow-Origin header with a wildcard that allows all domains.

Access-Control-Allow-Origin: *

A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site.

CORS Misconfiguration

The CORS Misconfiguration is checked by sending preflight requests to target web server. We can use curl for this

curl -I -s -H "Origin:" 

HTTP/1.1 200 OK
Server: gunicorn/19.7.0
Date: Sun, 13 Dec 2020 08:21:23 GMT
Connection: close
Content-Length: 61752
Access-Control-Allow-Credentials: true
Expires: Sun, 13 Dec 2020 08:21:23 GMT
Vary: Authorization, Cookie, Accept-Encoding
X-Homer: I like my beer cold, my TV loud and my homosexuals flaming.
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Content-Type: text/html; charset=utf-8
X-gunicorn-server: app02
Strict-Transport-Security: max-age=0; includeSubDomains

At above response we can see the Access-Control-Allow-Credentials: true , which means that the server allows cookies (or other user credentials) to be included on cross-origin requests.

CORS header is considered misconfigured in three cases

Case 1


When the Access-Control-Allow-Origin: header will return origin header name sign along with Access-Control-Allow-Credentials: true header, then this is the best scenario to steal users credentials/data by malicious web pages.

Access-Control-Allow-Credentials: true    

A POC Example from portswigger lab.

Case 2

POORLY Implemented and Exploitable

When the Access-Control-Allow-Origin: header will return null with Access-Control-Allow-Credentials: true header, then this is also exploitable scenario.

Access-Control-Allow-Origin: null   
Access-Control-Allow-Credentials: true   

A POC Example from portswigger lab.

Case 3

BAD Implementation but Not Exploitable

When the Access-Control-Allow-Origin: will return * sign along with Access-Control-Allow-Credentials: true header

Access-Control-Allow-Origin: *   
Access-Control-Allow-Credentials: true   
// or  
Access-Control-Allow-Origin: *

However this misconfigured is not exploitable due to CORS implementation the browser discard the server response (because Access-Control-Allow-Origin is “*” and Access-Control-Allow-Credentials is true).

CORS Misconfig Automation

I wrote a shell script which checks for CORS misconfiguration on web applications.

Github Link :

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.