Public read
- Input
- GET https://api.github.com/repos/octocat/hello-world
- Expected output
- Access-Control-Allow-Origin: *
Works from any site, no authentication needed, and it is a simple request: GET never triggers a preflight.
example of an API with open CORS
Not every API blocks cross-origin calls. Public read APIs, built to be consumed by any site or app, often open up CORS on purpose, and GitHub's REST API is one of the best-known examples of that.
Works from any site, no authentication needed, and it is a simple request: GET never triggers a preflight.
Most APIs don't expose extra headers by default; without this header, the page's JavaScript can only read Content-Type, Cache-Control and other safelisted ones.
That's exactly the symptom of a CORS block: the browser rejects the fetch() promise before handing any data to JavaScript, without detailing why. The catch is that this same generic message also shows up for DNS, TLS or connectivity failures, so the browser does not distinguish the two for the script that made the call.
The public read endpoints, yes. Endpoints that require authentication or modify data have their own rules and may behave differently depending on the authentication method used.
For public, credential-free data, yes, it's a common and safe pattern. Never combine * with Access-Control-Allow-Credentials: true, the browser itself rejects that combination.
No. GET is one of the three safe methods and the call does not use any header outside the Fetch safelist, so the browser never sends OPTIONS, it resolves the real request straight away as "simple".
Your browser makes the real request to the URL you enter, exactly like any page would. If the call completes, the current origin was authorized. If it's blocked, the browser never shows the page any data, that alone is the result.
This request only uses a method and headers CORS considers "safe" (GET/HEAD/POST with a simple Content-Type and standard headers), so the browser sends it directly, with no OPTIONS check first.
The test request leaves your browser directly for the URL you entered, the J-Kit server never sees, resolves or intermediates that address. It's the same kind of call any script on your own page would make.