API Keys & CORS Basics

A key's permissions matter more than its price

An API key identifies a caller and may allow access, usage tracking or billing. Free does not mean safe to publish. A free-tier key may still grant account access, consume a limited quota, reveal private data or later incur costs.

Classify a credential from the provider's documentation, not its name or whether you paid for it:

A browser app is delivered to visitors. They can inspect source, network requests and localStorage. Minifying, encoding, hiding a value in .env or giving it an obscure variable name does not make a browser-delivered credential secret. Framework public prefixes explicitly export configuration to the client.

The server boundary

A secret-key service should normally be called through a controlled server endpoint:

Browser asks your endpoint → endpoint checks caller/input
→ endpoint uses server-only secret → external API replies
→ endpoint returns only the allowed result

The secret stays in the host's private configuration. Your endpoint still needs authentication/authorisation where appropriate, validation and abuse limits. Otherwise an unauthenticated proxy may let strangers consume your paid API indirectly. Moving a key to a server is necessary but not the whole security design.

For Level 4, choose an API that needs no secret key. You can build a real dashboard without paying for AI or exposing credentials. The full-stack level introduces server endpoints when your product needs a private integration.

What an origin is

An origin combines scheme, hostname and port. https://studio.example.com and https://api.example.com have different hostnames, so they are different origins. http://localhost:3000 and http://localhost:5173 have different ports. A path difference alone does not change origin.

The browser's same-origin protections prevent a page from freely reading every other site's private responses. CORS is a server's way of granting cross-origin browser access. A response header such as Access-Control-Allow-Origin tells the browser which origin may read that response.

Trace a CORS failure without blaming JSON

1. Your page sends fetch to a different origin.
2. The external server may receive and answer the request.
3. The browser checks the response's CORS permission.
4. If permission is missing or incompatible, the browser refuses to expose the response to your JavaScript. Console reports a CORS-related error.

Opening the URL as a top-level browser tab or calling it with curl is different: those tests do not prove cross-origin JavaScript access is allowed. CORS is not an API's authentication mechanism and does not stop all non-browser callers. Some requests can still reach a server despite the browser hiding the reply.

Preflight is a permission check

For some requests—such as certain non-simple headers or a JSON POST—the browser first sends an OPTIONS preflight. It asks whether the intended method and headers are allowed. The API must permit the origin, method and headers for the browser request to proceed. Do not assume an OPTIONS response is the data your product asked for.

Credentialed requests have additional rules; wildcard origin is not compatible with every credentialed case. Use the provider's documented configuration rather than copying Access-Control-Allow-Origin: * into a private service.

Diagnose with browser evidence

Open DevTools Console and Network, then reproduce the request. Record the requested URL, your page's origin, any preflight and the error category—never credentials. Check whether the API explicitly supports browser usage from your origin.

Useful distinctions:

• HTTP 401/403 means the server rejected the request's credentials/permissions; inspect auth requirements.
• HTTP 429 means rate limiting; wait and reduce requests rather than hammering retry.
• CORS denial means browser read permission is missing or incompatible; changing the field names you parse will not solve it.
• Mixed-content denial occurs when an HTTPS page attempts an insecure HTTP request; choose HTTPS.

Things not to try

mode: 'no-cors' does not unlock readable JSON: it generally produces an opaque response your code cannot inspect. Do not disable browser security, install an extension that disables CORS, or send keys/private data through a random public CORS proxy. Those are not product solutions.

If you own the API, configure a narrow allowed-origin policy in its server. If you do not, choose a documented CORS-friendly API or use your own correctly protected server integration when the service permits it. Respect the API's terms and access rules.

Guided decision practice

An API gives you a “free secret key” and works in curl but fails in your page. Decide two things separately: the key must stay server-side because it is secret; curl success does not establish CORS permission. Your safe Level 4 response is to choose a key-free browser-friendly endpoint, not paste the key into app.js.

Now compare that with a documented publishable database key: it may appear in browser config because ordinary access is limited by database grants/RLS. The key is not equivalent to a privileged server credential and does not by itself prove the data is public.

Before assessment

Explain origin, CORS, preflight and secret versus publishable credentials. Verify your chosen dashboard endpoint from an actual fetch on your local page, not only the address bar. Confirm no private keys appear in source, storage, commits or submitted output. These checks apply regardless of which branch you later choose.