Free CORS Checker
A client-side CORS checker sends cross-origin fetch requests from the user's browser against a target URL, inspects Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Credentials response headers when the browser exposes them, and flags misconfigurations such as wildcard origins with credentials enabled or overly permissive method allowances.
Enter a public API or web app URL into ScanSuite's CORS checker and run the test. Your browser sends a cross-origin GET (with custom headers to trigger preflight) using this page's fixed Origin header, reporting which CORS headers are returned, whether credentials are permitted, and whether the target allows access from the ScanSuite origin.
Introduction to Cross-Origin Resource Sharing Testing
Cross-Origin Resource Sharing (CORS) is a browser-enforced security mechanism that controls whether JavaScript running on one origin can read responses from another origin. Misconfigured CORS policies are among the most common API security flaws, frequently exposing sensitive user data to untrusted third-party websites through overly permissive Access-Control-Allow-Origin directives.
ScanSuite's free CORS checker runs entirely in your browser. It sends cross-origin requests from the ScanSuite page origin and reports Access-Control headers the browser exposes when the target allows this origin. HTTP targets cannot be tested from this HTTPS page due to mixed-content blocking.
Combine CORS scan results with the security headers checker for broader HTTP hardening, the SSL checker to validate TLS on API endpoints, and the port scanner to discover exposed services that may serve cross-origin resources without adequate policy controls.
What Is a CORS Checker?
A CORS checker (also called a CORS tester or cross-origin scanner) evaluates how a web server responds to requests bearing Origin headers from domains other than its own. Browsers send Origin on cross-site fetch, XHR, and XMLHttpRequest calls; servers reply with Access-Control-Allow-Origin and related directives that tell the browser whether the response may be read by client-side scripts on the requesting origin.
ScanSuite sends a cross-origin GET from your browser with custom headers to trigger preflight. The Origin header is always this page's origin — arbitrary origins cannot be simulated in JavaScript. The checker flags dangerous patterns: wildcard Access-Control-Allow-Origin combined with Access-Control-Allow-Credentials: true and permissive Access-Control-Allow-Methods values.
Unlike manual browser DevTools inspection, a dedicated CORS scanner documents reproducible results with severity labels, making it suitable for penetration test reports, API security reviews, and pre-release regression checks after backend deployments.
Why Test CORS From Your Browser?
CORS is enforced by browsers, not servers alone. Testing from the same browser environment your users experience shows whether JavaScript on the ScanSuite origin can actually read responses from a target API.
Development teams frequently copy permissive CORS snippets from Stack Overflow—allowing all origins with credentials—to unblock local testing, then forget to tighten policies before production release. ScanSuite surfaces these gaps before attackers discover them, providing concrete header values and remediation guidance aligned with OWASP API Security recommendations.
Regular CORS audits complement SPF and DKIM checks for email authentication, DNS lookups for subdomain enumeration, and security header scans for defense-in-depth across your entire external attack surface.
Who Uses CORS Checkers?
Frontend and full-stack developers verify that SPAs, mobile web views, and third-party widget integrations receive correct Access-Control-Allow-Origin values after deploying API gateway or Cloudflare Workers changes.
API security engineers and penetration testers document CORS flaws during authorized assessments, demonstrating how reflected origins or wildcard credentials enable cross-origin token theft from authenticated sessions.
DevSecOps and platform teams enforce CORS baselines in CI pipelines, blocking releases when staging scans detect origin reflection or missing preflight handling on state-changing endpoints.
How the CORS Checker Works
When you submit a target URL, your browser normalizes it and sends a cross-origin GET with custom headers to trigger preflight. ScanSuite reads Access-Control-* response headers when the target allows this page's origin.
Results compare Access-Control-Allow-Origin against this page's Origin, check Access-Control-Allow-Credentials, and evaluate Access-Control-Expose-Headers and Access-Control-Max-Age when visible to JavaScript.
Each finding receives a severity rating: critical for credentials with reflected or wildcard origins, high for origin reflection on authenticated endpoints, medium for overly broad method or header allowances, and informational for missing CORS headers on public read-only resources that do not require cross-origin access.
Secure CORS Configuration Example
A properly configured API returns Access-Control-Allow-Origin: https://app.example.com (exact match, not wildcard) when the request Origin matches the allowlist.
For credentialed requests, Access-Control-Allow-Credentials: true appears only alongside a specific origin—never with Access-Control-Allow-Origin: *.
Preflight OPTIONS responses include Access-Control-Allow-Methods: GET, POST and Access-Control-Allow-Headers: Content-Type, Authorization limited to required values.
CORS Misconfiguration Severity Comparison
| Pattern | Risk Level | Typical Impact | |
|---|---|---|---|
| Wildcard origin with credentials | Critical | Any site can steal authenticated API responses | |
| Origin reflection | High | Attacker origin receives full API response body | |
| Wildcard origin without credentials | Medium | Public data readable cross-origin; may leak metadata | |
| Strict origin allowlist | Low | Only trusted frontends can read responses |
Why Does My CORS Scan Show No Access-Control Headers?
Same-origin requests do not require CORS headers. Ensure you are testing a cross-origin scenario by specifying a different origin than the target URL's scheme, host, and port.
Some APIs return CORS headers only on OPTIONS preflight, not on GET responses. Review preflight results separately from simple request results in the scan report.
Related tools
- Security Headers — Generate secure headers
- CSP Generator — Build Content Security Policy
- SSL Checker — Validate TLS certificates
- Security Headers Checker — Audit HSTS, CSP, and related HTTP security headers alongside CORS.
- SSL Checker — Validate TLS certificates on API endpoints serving cross-origin resources.
- DNS Lookup — Resolve API hostnames and discover subdomains for comprehensive scanning.
- Port Scanner — Discover exposed services that may serve APIs with weak CORS policies.
- JWT Debugger — Inspect token claims when testing authenticated API CORS behavior.
- URL Parser — Break down API URL components before configuring origin allowlists.
Frequently Asked Questions
How do I test CORS on an API?
Enter the endpoint URL and the origin to test. The tool runs a browser-side fetch (which may trigger a preflight when custom headers are used) and shows what Access-Control-Allow-* behaviour your browser observes, plus curl/http PoC snippets for OPTIONS checks.
What causes the "No 'Access-Control-Allow-Origin' header" error?
The server did not include an `Access-Control-Allow-Origin` header that matches your page's origin. Fix it on the server. Nothing in front-end code can override it.
Is Access-Control-Allow-Origin: * safe?
It is fine for public, unauthenticated data. It cannot be used with credentials (cookies), and reflecting any origin back while allowing credentials is a serious misconfiguration.
What is a CORS preflight request?
It is an OPTIONS request the browser sends before "non-simple" requests (custom headers, or PUT/DELETE) to ask whether the real request is allowed.
What is CORS?
Cross-Origin Resource Sharing is a browser mechanism where servers use Access-Control-* headers to permit or deny JavaScript on one website from reading responses fetched from another origin.
What does Access-Control-Allow-Origin do?
It tells the browser which origins may read the response. A specific origin, null, or wildcard * are valid values with different security implications.
Why is Access-Control-Allow-Origin: * dangerous with credentials?
Browsers block this combination, but misconfigured servers that reflect origins while allowing credentials enable any website to read authenticated API data.
What is origin reflection in CORS?
Origin reflection occurs when a server returns Access-Control-Allow-Origin matching whatever Origin header the client sends, effectively allowing any website cross-origin access.
Do CORS headers protect against CSRF?
No. CORS controls response readability by JavaScript, not whether requests are sent. CSRF requires anti-CSRF tokens, SameSite cookies, or custom header requirements.
Which requests trigger CORS preflight?
Requests using methods other than GET, HEAD, or POST, POST with non-simple content types, or custom headers like Authorization typically trigger preflight OPTIONS.
What is Access-Control-Allow-Credentials?
When true, the browser includes cookies and authorization headers on cross-origin requests and requires a specific non-wildcard Access-Control-Allow-Origin value.
Can I test CORS on localhost APIs?
ScanSuite tests public URLs reachable from scan nodes. Expose staging APIs via HTTPS tunnels or deploy to a reachable staging domain for remote CORS validation.
How does CORS relate to Content-Security-Policy?
CSP connect-src restricts which origins JavaScript may fetch, while CORS controls whether responses are readable. Both layers should align for defense in depth.
What is Access-Control-Expose-Headers?
It lists response headers beyond the CORS-safelisted defaults that JavaScript is permitted to read via getResponseHeader().
Why do I see CORS errors in the browser but the checker shows headers?
Browser extensions, cached responses, or redirects may alter headers. Compare scan results with DevTools Network tab on a clean browser profile.
Should public APIs allow Access-Control-Allow-Origin: *?
Wildcard is acceptable for truly public read-only APIs without credentials, but explicit allowlists are safer when responses contain user-specific or sensitive metadata.
How often should I scan CORS configuration?
Scan after every API deployment, gateway migration, or CDN rule change, and include CORS checks in quarterly external security assessments.
Does CORS apply to server-to-server requests?
No. CORS is enforced only by browsers. Server-side HTTP clients ignore Access-Control headers entirely.
What is the Vary: Origin header?
It instructs caches to store separate responses per Origin, preventing a CDN from serving one origin's CORS header to a different origin.
Can CORS misconfiguration lead to data breaches?
Yes. Origin reflection on authenticated endpoints has been exploited to exfiltrate personal data, account details, and API tokens to attacker-controlled websites.
Is this CORS checker free?
Yes. ScanSuite provides unlimited free CORS scans on public URLs without registration or daily limits.
Summary
ScanSuite's free CORS checker tests cross-origin resource sharing from your browser on any public HTTPS URL, analyzing Access-Control-Allow-Origin, credentials flags, and method exposure when headers are visible. Detect wildcard misconfigurations and understand whether the ScanSuite origin can read API responses.