CORS Misconfiguration Checker
Test whether your site's Cross-Origin Resource Sharing (CORS) policy can be abused. We send crafted Origin headers and inspect the Access-Control-Allow-Origin / Allow-Credentials response to catch the misconfigurations that let any website read your authenticated API responses.
Free check · no signup needed
3 free tool checks today · 3 left- ✓Arbitrary origin reflection — does the server echo any Origin back in ACAO?
- ✓Wildcard (*) Access-Control-Allow-Origin with credentials
- ✓null origin acceptance (sandboxed iframe / redirect abuse)
- ✓Subdomain-trick bypass — yourdomain.com.evil.com being trusted
- ✓HTTP-origin downgrade — http:// origins accepted on an HTTPS site
About this check
CORS is the browser mechanism that decides whether JavaScript running on one origin is allowed to read responses from another. Configured correctly, it's an essential part of how modern web apps talk to their APIs. Configured wrong, it's a data-leak waiting to happen: if your API reflects an attacker's Origin in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true, then any malicious site your logged-in user visits can make authenticated requests to your API and read the responses — session data, account details, anything the user can see.
The most dangerous pattern our checker catches is arbitrary origin reflection with credentials. Many frameworks make it easy to 'fix' a CORS error by echoing back whatever Origin the request carried — it silences the browser error and ships. But it means there is effectively no origin restriction at all. We send an Origin of https://evil.com and check whether your server reflects it; if it does and allows credentials, that's a critical finding.
We also test the subtler bypasses: a null origin (which a sandboxed iframe or a redirect chain can produce, and which some configs trust), a subdomain trick where yourdomain.com.evil.com is accepted because the allowlist used a naive substring/prefix match, and an HTTP-origin downgrade where an https:// site still trusts http:// origins. Each of these is a real way attackers defeat an allowlist that looked safe.
Fixing CORS safely: maintain an explicit allowlist of exact origins (scheme + host + port), never reflect the Origin header blindly, and only send Access-Control-Allow-Credentials: true for origins you fully trust — never together with a wildcard. A full SteelSuit scan tests CORS alongside the rest of your HTTP security posture: security headers, CSP source-list evaluation, cookie flags, and mixed-content — so you see how the whole browser-facing surface holds together.