🌐 CORS Tester - Test Cross-Origin Policies

🌐 Request Configuration

URL to test CORS policy against

⚡ Quick Tests

📊 Test Results

{{ results.length }} test(s) completed
No tests run yet. Enter a URL and click "Test CORS" to begin.
{{ result.icon }}
{{ result.title }}
{{ result.timestamp }}
{{ result.status }}
{{ result.method }} {{ result.url }}
CORS Analysis:
  • {{ analysis.icon }} {{ analysis.text }}
Response Headers ({{ Object.keys(result.headers).length }})
{{ key }}: {{ value }}
Error:

📚 CORS Configuration Guide

✅ Allow All Origins (Development Only)
Access-Control-Allow-Origin: *
🔒 Specific Origin (Production)
Access-Control-Allow-Origin: https://myapp.com
🔑 With Credentials
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://myapp.com
⚡ Complex Requests
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
⚠️

ℹ️ About CORS Tester

Cross-Origin Resource Sharing (CORS) is the browser protocol that decides whether JavaScript running on one origin can read a response from another origin. This CORS tester helps check the headers a target API returns for simple requests, credentialed requests, and browser preflight checks before you wire a frontend to an API gateway, CDN, static asset host, or internal service.

Headers this CORS checker verifies

Response policy headers

  • Access-Control-Allow-Origin: the origin allowed to read the response, or * for non-credentialed public responses
  • Access-Control-Allow-Methods: methods approved for a preflighted request, such as GET, POST, or DELETE
  • Access-Control-Allow-Headers: request headers the browser may send after a successful preflight
  • Access-Control-Allow-Credentials: whether cookies, client certificates, or HTTP auth may be exposed to the requesting page

Request paths to test

  • Simple requests: browser-safe GET, HEAD, or limited POST requests
  • Preflight requests: automatic OPTIONS checks for non-simple methods, content types, or custom headers
  • Credentialed requests: requests using cookies or authentication where wildcard origins are not valid
  • Exposed response headers: custom headers that require Access-Control-Expose-Headers before frontend code can read them

Common CORS testing examples

  • Frontend API call: test https://api.example.com/v1/users from https://app.example.com and confirm the API reflects only trusted origins.
  • Authorization header: add Authorization: Bearer ... or X-API-Key to verify that the preflight response allows the header before the real request runs.
  • Cookie-backed session: enable credentials and confirm the response does not combine Access-Control-Allow-Credentials: true with Access-Control-Allow-Origin: *.
  • Non-simple method: try PUT, PATCH, or DELETE to see whether the target handles OPTIONS and returns the right allowed-method list.

Specifications and security limits

Current CORS behavior is defined by the WHATWG Fetch CORS protocol, including the CORS-preflight request. The origin model comes from RFC 6454, and HTTP method and header semantics are specified in RFC 9110.

Important limitations

  • CORS is a browser read-protection mechanism. It is not authentication, authorization, CSRF protection, or a server-side firewall.
  • A command-line HTTP client can still send requests even when a browser would block JavaScript from reading the response.
  • Allowing arbitrary reflected origins is risky for private APIs, especially when credentials or bearer tokens are involved.
  • Preflight results can be cached by browsers through Access-Control-Max-Age, so repeat tests may not always match a first-time visitor.
  • For broader hardening guidance, review OWASP's CORS security recommendations.
Ready