CORS Checker
Test CORS headers for any URL and identify cross-origin resource sharing misconfigurations.
What is CORS Checker?
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls how web pages on one origin (domain) can request resources from a different origin. When a JavaScript application on app.example.com makes a fetch request to api.otherdomain.com, the browser checks the server's CORS headers to decide whether to allow the response. The server must explicitly include Access-Control-Allow-Origin headers listing which origins are permitted. CORS errors are one of the most frustrating and misunderstood issues in web development — the error occurs in the browser, not the server, and the fix is always on the server side. Misconfigured CORS (such as setting Access-Control-Allow-Origin: * on endpoints that accept credentials) also creates security vulnerabilities. This tool checks any URL's CORS configuration by making preflight and actual requests, reporting all relevant CORS headers and identifying common misconfigurations.
How to Use CORS Checker
- 1
Enter URL and Origin
Paste the API endpoint URL to check and optionally specify the origin domain you want to test (e.g. your frontend's domain). The tool sends both preflight (OPTIONS) and GET requests.
- 2
View CORS Headers
See all CORS-related response headers: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, and Access-Control-Max-Age.
- 3
Review Security Assessment
Get a security assessment of the CORS configuration: whether it is too permissive (wildcard origin with credentials), too restrictive (blocking legitimate origins), or correctly configured.
Use Cases
Debugging CORS Errors in Development
When a frontend application throws "Access to fetch at X from origin Y has been blocked by CORS policy", this checker identifies exactly which CORS headers are missing or misconfigured on the API server — enabling precise fixes rather than trial-and-error header additions.
API Security Audit
Verify that your API's CORS configuration is secure: that it only allows requests from your actual frontend origins (not *), that credentials are only allowed for explicitly trusted origins, and that the allowed methods and headers don't expose unnecessary attack surface.
Third-Party API Integration Testing
When integrating with a third-party API, check its CORS configuration before writing frontend code — verifying that it permits requests from your domain and supports the HTTP methods and headers your integration requires.
Features
Preflight Request Testing
Sends HTTP OPTIONS preflight requests to test CORS preflight responses — the first request browsers send for cross-origin requests with custom headers or non-simple methods.
All CORS Headers Displayed
Shows all seven CORS response headers with their values, explanations of what each header does, and whether each value represents a security risk or misconfiguration.
Security Risk Detection
Flags dangerous configurations: wildcard origin (*) combined with credentials (allows any website to make authenticated cross-origin requests), overly broad origin lists, and missing headers for requested methods.
Fix Recommendations
For each identified issue, provides specific server configuration fixes for Apache (.htaccess), Nginx, Express.js, and other common server environments.
Frequently Asked Questions
CORS exists because of the browser's same-origin policy — a fundamental security mechanism that prevents JavaScript on one domain from reading responses from requests to a different domain. Without this policy, a malicious website could use your logged-in session to make requests to your bank's API and read your account data. CORS is the mechanism that allows servers to opt in to cross-origin access when appropriate — explicitly listing which origins they trust. The key point: CORS is a browser security feature. The browser enforces it; the server configures it. Non-browser HTTP clients (curl, Postman) are not subject to CORS.
CORS is enforced by browsers as a security protection for web users — it prevents JavaScript code on malicious websites from silently making authenticated requests on your behalf. curl, Postman, and server-side HTTP requests don't have this restriction because they don't run in a browser security context with access to your cookies and session tokens. When a CORS error appears in your browser's console, the request did reach the server (the server returned a response), but the browser blocked your JavaScript code from reading the response.
For "non-simple" cross-origin requests (those using methods other than GET/POST/HEAD, or custom headers), browsers send a preflight OPTIONS request before the actual request. The preflight asks the server: "Will you allow an actual request from this origin with these headers and method?" The server responds with CORS headers either granting or denying permission. Only if the preflight succeeds does the browser send the actual request. Simple requests (basic GET or POST with standard headers) skip the preflight. The Access-Control-Max-Age header caches preflight results to reduce the overhead of pre-flighting every request.
It depends on the endpoint. For truly public read-only APIs with no authentication (public data APIs, CDN assets, public fonts), * is appropriate and common. It becomes a security risk when combined with Access-Control-Allow-Credentials: true — this combination theoretically allows any website to make authenticated cross-origin requests using the user's cookies. Browsers actually block this combination (they require explicit origin lists when credentials are involved), but misconfigured servers that try to set both create confusion and potential security issues depending on how credentials are handled.
Need a Professional Website?
JAIDOO EMPIRE builds fast, SEO-optimised websites for businesses worldwide. All free tools are built and maintained by our team.
Start Your Project
