Victor Jeman Academy

Why does the browser block your request?

The browser blocks cross-origin requests until the server opts in. Keep base URLs in per-environment config, and keep secrets out of anything that ships to the browser.

Two origins, one wall

Your frontend on localhost:3000 and your API on api.example.com are different origins. An origin is scheme plus host plus port; change any one of them and it counts as cross-origin. The browser will not let a page read a cross-origin response unless that origin opts in.

My frontend at [frontend origin] fetches [API origin] and the browser blocks the response. Why does it block it, and exactly which response header must the API send to let my page read it?

The preflight check

A custom header or a method other than GET triggers an extra OPTIONS request before the real one. The browser proceeds only if the server answers it correctly.

Explain a CORS preflight request for a fetch call made from a Next.js App Router client component to an external API: when the browser sends one, and which headers the server must return.

Base URLs and secrets

Keep the API base URL in an environment variable so it changes between local, staging, and production without touching code. Anything prefixed NEXT_PUBLIC_ ships to the browser, so a secret must never carry that prefix.

In my Next.js App Router project, where do I set the API base URL so it differs across local, staging, and production with no code change, and why would putting [a secret like an API key] in a NEXT_PUBLIC_ variable leak it?

The browser blocks cross-origin reads until the server opts in, and any NEXT_PUBLIC_ value is public, so keys and credentials stay server-side only.

Additional Resources

Explore these carefully curated resources to deepen your understanding and practice the concepts covered in this lesson.