CORS (Cross-Origin Resource Sharing) is an HTTP-header mechanism that lets a server permit browser scripts from other origins to read its responses. It explains why a fetch call inside a page can fail while the same URL works in a server-side scraper — the browser enforces a cross-origin reading policy that ordinary HTTP clients do not.
A page on https://app.example and an API on https://api.example have different origins, even though they share a parent domain. When page JavaScript requests that API, the browser checks the response's Access-Control-Allow-Origin header before exposing it to the script.
CORS is separate from authentication and anti-bot scoring. A missing CORS header can prevent JavaScript from reading a successful response; a target can also reject a request at the server regardless of what CORS permits. Inspect the console and network panel together before classifying the failure.
Some cross-origin requests first send OPTIONS with the proposed method and header names. JSON POST bodies and custom request headers commonly trigger this preflight. The server must allow the origin, method, and requested headers before the browser sends the actual request.
Other requests can be sent without a preflight, with the response still subject to CORS checks. A CORS error therefore does not prove that the server never received the request. Retrying a state-changing operation blindly can repeat an action whose response the page could not read.
A fetch executed inside a Playwright page follows browser CORS rules. A backend HTTP client is outside that page's origin policy, but still faces the target's authentication, rate limits, and access controls. Moving a request to a backend changes the client context; it does not grant permission to the resource.
Credentialed browser requests require an explicit allowed origin and Access-Control-Allow-Credentials: true; Access-Control-Allow-Origin: * is insufficient. Cookie policies still apply. Setting mode: no-cors is not a way to obtain readable JSON: it yields an opaque response for a cross-origin fetch.
How Crawlora handles this
Call Crawlora's documented APIs from your backend when building an extraction workflow, and keep API credentials there. A browser console CORS error should be diagnosed separately from the upstream fetch result or the API's own error response.
Related reading
Glossary
FAQ
Those clients do not enforce a browser page's CORS policy. The server can still deny their requests through authentication, origin checks, rate limiting, or anti-bot controls.
No. A cross-origin no-cors fetch returns an opaque response whose body and headers are unavailable to page JavaScript.
No. CORS is enforced by the browser and can hide a 200 response. A 403 is a server response; it can also lack CORS headers, causing both symptoms at once.
Beyond CORS (Cross-Origin Resource Sharing), Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.