Free · No account needed · 30 seconds

CORS Tester

Why is my request blocked by CORS?

A CORS error means the server didn't send the headers a browser needs before it lets your frontend read the response. Enter the URL and the origin you're calling from, and this CORS tester shows which header is missing or wrong, and whether the server trusts origins it shouldn't.

Our server sends four requests: a GET with your origin, a GET with an unknown origin, a GET with a null origin, and an OPTIONS preflight. No cookies, no request body, and response bodies are never read.

What this CORS tester checks

Access-Control-Allow-Origin

Whether the response allows your exact origin, a wildcard, or nothing at all, and whether it lists more than one origin, which browsers reject.

Preflight requests

For PUT, PATCH, DELETE, JSON bodies, and Authorization headers: whether OPTIONS returns a 2xx with the methods and headers you need.

Cookies and credentials

When your frontend sends cookies: the exact-origin and Access-Control-Allow-Credentials rules browsers enforce on credentialed requests.

Reflected origins

Whether the server echoes back any Origin it's sent, the misconfiguration that lets any website read your signed-in users' data.

Read more →

The null origin

Whether Origin: null is trusted. Any website can send it from a sandboxed iframe, so trusting it means trusting everyone.

Redirects and caching

Redirects that make preflights fail, and a missing Vary: Origin that makes CORS errors come and go behind a CDN.

How the CORS Tester works

  1. Step 1

    Enter the URL and your origin

    The endpoint your frontend calls, the origin it calls from, the method, and any custom headers such as Authorization.

  2. Step 2

    We send four requests

    A GET with your origin, a GET with an unknown origin, a GET with a null origin, and an OPTIONS preflight. They come from our server with no cookies and no body, and only the headers are read.

  3. Step 3

    Read the answer and the fix

    Allowed or blocked from your origin, the reason in plain English, and the header to change, plus any origin the server trusts that it shouldn't.

Frequently asked questions

What is a CORS error?

A CORS error is the browser refusing to let JavaScript on one origin read a response from another, because the response didn't include an Access-Control-Allow-Origin header matching your page. For simple requests the request still reaches your server and runs; for requests that need a preflight, the browser stops before sending it. That's why the same call works in Postman or curl and fails in the browser: CORS is enforced by browsers, not by servers.

How do I test CORS?

Send the request with an Origin header and read the response headers. From a terminal, run curl -i -H "Origin: https://yourapp.com" followed by your API URL, and look for Access-Control-Allow-Origin. For PUT, DELETE, JSON bodies, or an Authorization header, also send the preflight: curl -i -X OPTIONS with Access-Control-Request-Method and Access-Control-Request-Headers. This tester does both, adds the security checks, and explains the result.

What is a preflight request?

A preflight is an OPTIONS request the browser sends before the real one when the request isn't simple: any method other than GET, HEAD, or POST, a JSON Content-Type, or a custom header like Authorization. The server has to answer with a 2xx status and headers that allow your origin, method, and headers, or the real request is never sent. A common cause of failures is auth middleware that rejects the OPTIONS request because it carries no token.

Is Access-Control-Allow-Origin: * safe?

It's fine for genuinely public data, such as an open API, fonts, or a CDN, because browsers never send cookies with wildcard requests. It's the wrong choice for anything that depends on who's asking. The dangerous setup is a different one: echoing back whatever Origin arrives together with Access-Control-Allow-Credentials: true, which lets any website read your signed-in users' data. This tester checks for that by sending an origin your server has never seen.

Is it free? Do I need to sign in?

Yes. It's free, with no account and no sign-in. There's a rate limit to stop the tool being abused, and that's the only limit. Ubserve makes money from its paid security report, not from this page. The full scan it pairs with is free to run too: you get a grade, an issue count, and up to two findings in full before anything is asked of you.

What does the tester send to my server?

Four requests from Ubserve's servers: three GETs with different Origin headers and one OPTIONS preflight. None of them carries cookies, credentials, or a body, whichever method you pick; the method you choose is only named in the preflight, never actually sent. We read the response headers and discard the body. Only public addresses on standard ports can be tested, so the tool can't reach private or internal networks.

What founders say

5.0 out of 5 - Ubserve, from 3 reviews

“Helped me find a critical database issue that would've done real damage. I recommend it for every founder.”
Juan
“Caught a critical CSP issue on my frontend within minutes. Don't ship without a scan.”
Zenix
“The free scan took under 60 seconds to find real issues in my project.”
George P.

Check what your live app serves

Anything you check here only covers what you hand it. What an attacker sees is what your deployed app serves, so paste your URL and check that too.

https://

Free, no account needed. We only read what your app already serves publicly.