Skip to content
HackIndex logo

HackIndex

CORS Misconfiguration Testing

3 min read Apr 24, 2026

CORS misconfigurations allow attacker-controlled origins to make authenticated cross-origin requests to an API. When Access-Control-Allow-Origin reflects an attacker-supplied origin and Access-Control-Allow-Credentials: true is present, a malicious page can read API responses using the victim's session cookies. Detection confirms the misconfiguration exists — impact assessment determines whether sensitive data is accessible through the affected endpoints.

Reflected Origin Test

Send an arbitrary Origin header and check whether it is reflected in the response. This is the most common CORS misconfiguration:

┌──(kali㉿kali)-[~]
└─$ curl -skI https://$DOMAIN/api/v1/user -H 'Origin: https://attacker.com' | grep -i 'access-control' 
access-control-allow-origin: https://attacker.com
access-control-allow-credentials: true

Reflected origin with credentials allowed is a confirmed exploitable misconfiguration. Any origin can read API responses using the victim's cookies — no restriction is applied. This enables cross-origin reading of profile data, tokens, and other authenticated API responses.

Null Origin Test

Some applications trust a null origin for legacy compatibility. Sandboxed iframes can send null origins, making this exploitable:

┌──(kali㉿kali)-[~]
└─$ curl -skI https://$DOMAIN/api/v1/user -H 'Origin: null' | grep -i 'access-control' 
access-control-allow-origin: null
access-control-allow-credentials: true

Subdomain Trust Test

Some applications restrict CORS to subdomains of their own domain. If any subdomain is compromised or has XSS, it can be used to make credentialed cross-origin requests:

┌──(kali㉿kali)-[~]
└─$ curl -skI https://$DOMAIN/api/v1/user -H "Origin: https://evil.$DOMAIN" | grep -i 'access-control' 
access-control-allow-origin: https://evil.example.com
access-control-allow-credentials: true
┌──(kali㉿kali)-[~]
└─$ curl -skI https://$DOMAIN/api/v1/user -H "Origin: https://$DOMAIN.attacker.com" | grep -i 'access-control'

A suffix match bypass like example.com.attacker.com being trusted indicates the application uses a vulnerable contains or endsWith check rather than exact origin matching.

Wildcard Without Credentials

A wildcard Access-Control-Allow-Origin: * without Allow-Credentials is not directly exploitable for authenticated requests but confirms the API returns data to any origin — useful for unauthenticated data gathering:

┌──(kali㉿kali)-[~]
└─$ curl -skI https://$DOMAIN/api/v1/public -H 'Origin: https://attacker.com' | grep -i 'access-control' 
access-control-allow-origin: *

Test Multiple Endpoints

CORS configuration often differs between endpoints. The main domain may be hardened while API and auth endpoints are not. Test all discovered API paths:

┌──(kali㉿kali)-[~]
└─$ for endpoint in /api/v1/user /api/v1/profile /api/v1/orders /api/v2/account /graphql; do echo -n "$endpoint: "; curl -skI https://$DOMAIN$endpoint -H 'Origin: https://attacker.com' | grep -i 'access-control-allow-origin' | tr -d '\n'; echo; done 
/api/v1/user: access-control-allow-origin: https://attacker.com
/api/v1/profile: access-control-allow-origin: *
/api/v1/orders: 
/graphql: access-control-allow-origin: https://attacker.com

References