Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
One origin per line, up to ten. Useful for checking that local, staging and production are all on the allowlist. The results appear as a table in the Headers tab.
These requests are sent from POLPROG servers to the endpoint you name, because a browser cannot run this diagnosis on itself: CORS is what would block it. No cookie of yours is forwarded, no request body is ever sent, response bodies are discarded, and nothing is stored once the report reaches you.
A browser rule, not a server one. When JavaScript on one origin asks for a resource on another, the browser sends the request but refuses to hand the response to your code unless the server says, in its response headers, that the requesting origin may read it. Cross-Origin Resource Sharing is the set of headers used to say that.
If a request works in curl, Postman, Insomnia or from your own backend, that tells you nothing about whether browser JavaScript can read it. Those clients apply no CORS rules at all. The server usually behaves identically in both cases; the difference is entirely in what the caller does with the response.
For anything but the simplest requests, the browser first sends an OPTIONS request asking whether the real one is permitted. It carries Origin, Access-Control-Request-Method and, if needed, Access-Control-Request-Headers. If the answer does not permit the request, the real one is never sent, so the endpoint never sees it and your server logs show nothing.
A request is simple only when its method is GET, HEAD or POST and every header it sets is CORS-safelisted: Accept, Accept-Language, Content-Language, Content-Type and Range. The value matters too. Content-Type stays safelisted only for application/x-www-form-urlencoded, multipart/form-data and text/plain.
It is not on the list of three safelisted content types. That is the whole reason. A POST with a JSON body is a preflighted request, which is why adding a JSON API to an existing page suddenly produces an OPTIONS request nobody wrote, and errors from a route that only handles POST.
Either a single origin or *. Never a list, never a value with a path, never a wildcard inside a hostname. The comparison against the requesting origin is exact, so a trailing slash, a default port written out, or http where the request used https will all fail while looking identical to a person.
Needed when the request sends cookies or HTTP authentication. Its only accepted value is the exact lowercase string true. A credentialed request also cannot be satisfied by Access-Control-Allow-Origin: *, and for the same request an asterisk in Allow-Methods, Allow-Headers or Expose-Headers stops being a wildcard and becomes a literal name.
If the server picks the Allow-Origin value from the incoming request, the response depends on the Origin header, and any shared cache needs telling. Without Vary: Origin a CDN or reverse proxy can store a response naming one origin and serve it to another, so requests fail for reasons that never appear in the application.
A cross-origin response exposes only seven headers to script: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified and Pragma. Anything else, including your own X- headers and Location, reads as null unless it is named in Access-Control-Expose-Headers. That header is about the response and is unrelated to Allow-Headers, which is about the request.
It decides which origins may read a response in a browser. It does not decide who may call an endpoint, it grants no permissions, and it does not stop cross-site request forgery: a CSRF attack does not need to read the response, so a strict CORS policy leaves it untouched. Keep authentication, authorization and CSRF tokens exactly as they were.
Every verdict here comes from an actual exchange with the endpoint you named, evaluated against the Fetch standard rules a browser applies. It describes the endpoint as it answered POLPROG infrastructure at that moment: a server that varies its response by network, by region or by authentication may answer your browser differently. Timings are observed from our infrastructure and are not a browser measurement. Actual-request testing is off by default for methods that can change data, and no request body is ever sent.
Because CORS is enforced by browsers and by nothing else. Postman, curl, Insomnia and your own backend apply no CORS rules at all, so they receive the response whatever headers it carries. The server usually behaves identically in both cases. The difference is entirely in what the caller does with the answer, and a browser refuses to hand it to your JavaScript unless the response says that origin may read it.
An OPTIONS request the browser sends before the real one, to ask whether the real one is allowed. It carries Origin, Access-Control-Request-Method and, when needed, Access-Control-Request-Headers. If the answer does not permit the request, the real one is never sent, so your endpoint never sees it and your server logs show nothing. Only requests that are not simple are preflighted.
Content-Type is CORS-safelisted only for application/x-www-form-urlencoded, multipart/form-data and text/plain. Those three, and nothing else. A JSON body puts the request outside the safelist, so the browser announces it in advance. That is why adding a JSON API to an existing page suddenly produces an OPTIONS request nobody wrote.
Because a response tied to a signed-in user must not be readable by every site that user visits. When a request sends cookies or HTTP authentication, the server has to name the origin it is trusting, and a browser rejects a wildcard outright, even alongside Access-Control-Allow-Credentials: true. The same applies to an asterisk in Allow-Methods, Allow-Headers and Expose-Headers: for a credentialed request each one is read as a literal header name rather than as a wildcard.
No. CORS decides which origins may read a response inside a browser. It is not authentication, it grants no permissions, and it does not stop cross-site request forgery, because a CSRF attack does not need to read the response. Any client that is not a browser ignores it completely. Keep your authentication, your authorization checks and your CSRF tokens exactly as they are.
From POLPROG servers to the endpoint you name, because a browser cannot run this diagnosis on itself: CORS is what would block it. Only the headers needed for the analysis are sent, no cookie of yours is forwarded, no request body is ever sent, and response bodies are discarded. Nothing is stored once the report reaches you, and values of sensitive headers such as Authorization are never displayed or exported.
An enterprise asks for “one security scanner”, but the real requirement normally contains several independent problems:
HTTP security headers let a server tell the browser how scripts may be loaded, whether a page may be embedded, which device capabilities may be used, how much referrer information should be sent, how MIME types must be interpreted and whether the site may ever be reached over plain HTTP. A well-designed policy reduces the impact of several classes of attacks, including cross-site scripting, clickjacking, MIME confusion, XS-Leaks and unsafe cross-origin embedding.
A good website audit is not a single Lighthouse score or a list of several dozen automated warnings. It should answer four questions: can a search engine correctly discover and understand the website, can a user complete their task efficiently, is the website fast enough, and does it expose the owner or visitors to unnecessary risk?
We build custom software and solutions tailored to your needs.