The best examples of CORS: practical examples with developer tools

Let’s start where most developers actually meet CORS: a browser tab, a failing fetch call, and the Network panel open in frustration. These real examples of CORS are based on everyday debugging patterns, not textbook theory.

Imagine a React app running at http://localhost:3000 calling an API at http://localhost:8080. Same machine, different ports, so they’re different origins. The first time you hit that API from the browser, you see a red error in the console:

Access to fetch at ‘http://localhost:8080/api/users’ from origin ‘http://localhost:3000’ has been blocked by CORS policy…

You open DevTools → Network → Fetch/XHR, click the failing request, and check the Response Headers. There’s no Access-Control-Allow-Origin header. That’s your first live example of CORS misconfiguration, and the developer tools just handed you the diagnosis.

From here, we’ll walk through more examples of CORS: practical examples with developer tools that show:

• How preflight OPTIONS requests appear and why they matter
• How Access-Control-Allow-Credentials changes browser behavior
• How API gateways, serverless platforms, and modern frameworks handle CORS in 2024–2025

Front-end focused example of CORS debugging with Chrome DevTools

A very common example of CORS in day-to-day work is a single-page app calling a JSON API.

You have:

• Front-end: https://app.example.com
• API: https://api.example.com

You write:

fetch('https://api.example.com/profile', {
  credentials: 'include',
});

In Chrome DevTools, under Network → Fetch/XHR, you see two entries:

• An OPTIONS request to /profile
• A GET request to /profile (which might be blocked)

Click the OPTIONS request. In Request Headers, you’ll see:

• Origin: https://app.example.com
• Access-Control-Request-Method: GET
• Access-Control-Request-Headers: authorization

In Response Headers, you might see something like:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type

This is a textbook example of CORS gone slightly wrong. The browser asked for permission to send the authorization header, but the server’s Access-Control-Allow-Headers doesn’t include authorization. In DevTools, the Console shows a CORS error, but the real story is in the Network panel: the preflight response is incomplete.

Fixing it is straightforward on the server:

Access-Control-Allow-Headers: Content-Type, Authorization

Refresh, repeat the call, and watch DevTools again. Now the OPTIONS request succeeds, the GET request completes, and the browser stops complaining. This is one of the best examples of how developer tools turn CORS from a mystery into a simple header mismatch.

API gateway example of CORS: practical examples with developer tools

Modern architectures often hide your API behind an API gateway (NGINX, AWS API Gateway, Azure API Management, Kong, etc.). That’s where a lot of real examples of CORS problems live.

Say you have:

• Front-end: https://dashboard.example.com
• API gateway: https://api.example.com
• Origin service: http://internal-service:4000

You configure the gateway to add:

Access-Control-Allow-Origin: https://dashboard.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

In DevTools, you test a PUT request from the front-end. You see:

• OPTIONS /items/123 → 200 OK
• PUT /items/123 → 500 Internal Server Error

But the browser does not show a CORS error. This is a subtle but important example of CORS behavior: CORS is not about whether the API works—it’s about whether the browser is allowed to see the response.

If the gateway returns correct CORS headers, the browser happily delivers the 500 error to your JavaScript. In the Network panel, your Response Headers still include Access-Control-Allow-Origin, so CORS is fine; your bug is in the application logic.

This is why, when debugging, you should always distinguish between:

• Network/CORS problems (blocked by browser)
• Application problems (server responded, but with an error)

Developer tools make that distinction obvious if you train yourself to always check the headers, not just the console error message.

Real examples of CORS with credentials and cookies

Another very common example of CORS trouble shows up when you try to send cookies or authorization headers.

You have:

• Front-end: https://client.example.com
• Auth API: https://auth.example.com

You call:

fetch('https://auth.example.com/session', {
  method: 'GET',
  credentials: 'include',
});

In DevTools → Network, you see the request go out with Cookie: session=.... But the response headers look like this:

Access-Control-Allow-Origin: *

Chrome’s console throws:

The value of the ‘Access-Control-Allow-Origin’ header in the response must not be ‘*’
when the request’s credentials mode is ‘include’.

This is one of the best examples of how a seemingly “relaxed” setting (*) actually breaks credentialed requests. The fix is to echo the specific origin and enable credentials:

Access-Control-Allow-Origin: https://client.example.com
Access-Control-Allow-Credentials: true

Reload, re-run the request, and watch in DevTools:

• The cookie is sent
• The response includes the updated headers
• The browser now exposes the response body to your JavaScript

If you want a deeper reference on HTTP and security models that underpin CORS, the MDN Web Docs are still among the most reliable sources: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Examples of CORS preflight behavior in 2024–2025

Browsers keep tightening security, and CORS preflight behavior is part of that story. In 2024–2025, you’ll keep seeing more emphasis on safe defaults and stricter cookie handling (SameSite, Secure, etc.), which interact with CORS.

A realistic example of CORS in this context:

Your front-end sends a PATCH request with custom headers:

fetch('https://api.example.com/user/123', {
  method: 'PATCH',
  headers: {
    'Content-Type': 'application/json',
    'X-Client-Version': 'web-2025.03',
  },
  body: JSON.stringify({ name: 'Jamie' }),
});

In DevTools, you’ll see:

• OPTIONS /user/123 with:
  • Access-Control-Request-Method: PATCH
  • Access-Control-Request-Headers: content-type, x-client-version

Your server responds with:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PATCH
Access-Control-Allow-Headers: Content-Type

The browser quietly blocks the actual PATCH because X-Client-Version wasn’t allowed. You may not even see the blocked PATCH in the Network panel; instead, you get a CORS error in the Console.

In many frameworks (Express, Spring Boot, ASP.NET Core), the fix is to explicitly list custom headers in your CORS config. For example, in Express with the cors middleware:

app.use(cors({
  origin: 'https://app.example.com',
  methods: ['GET', 'POST', 'PATCH'],
  allowedHeaders: ['Content-Type', 'X-Client-Version'],
}));

Then verify in DevTools that:

• The OPTIONS response includes Access-Control-Allow-Headers: Content-Type, X-Client-Version
• The PATCH request is now visible and returns a real response

As browsers continue to evolve security defaults (see the W3C and WHATWG specs), expect more traffic to go through preflight checks, not less. CORS isn’t going away.

For the official specification, the W3C CORS recommendation is still the canonical reference: https://www.w3.org/TR/cors/

Examples of CORS with serverless and edge functions

In 2024–2025, a lot of APIs live on serverless platforms or edge runtimes (AWS Lambda, Cloudflare Workers, Vercel Functions, Netlify Functions). These platforms often require you to set CORS headers manually.

Consider a Cloudflare Worker example of CORS handling:

export default {
  async fetch(request) {
    const origin = request.headers.get('Origin');

    const response = new Response(JSON.stringify({ ok: true }), {
      headers: {
        'Content-Type': 'application/json',
        'Access-Control-Allow-Origin': origin || '*',
        'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
        'Access-Control-Allow-Headers': 'Content-Type, Authorization',
      },
    });

    if (request.method === 'OPTIONS') {
      return response;
    }

    return response;
  },
};

In DevTools, you can test this from:

• A local front-end on http://localhost:5173
• A deployed front-end on https://myapp.example.com

Watch how the Origin header changes per environment, and how your worker echoes it back. This is a concrete example of CORS behavior that you can observe in real time across staging and production.

When debugging serverless CORS issues, a useful pattern is to:

• Hit the function directly from curl or an API client (no CORS there)
• Then hit it from the browser and compare headers in DevTools

If it works in curl but fails in the browser, you’re almost certainly looking at a CORS problem, not an application bug.

Examples include local development CORS headaches

Local development is where many of the best examples of CORS misunderstandings happen.

You run:

• Front-end dev server: http://localhost:3000
• API dev server: http://localhost:5000

Your browser treats these as different origins because the port is part of the origin. That means CORS rules apply even on your laptop.

You hit the API from your front-end, see a CORS error, and you’re tempted to disable security in your browser or install a shady extension. Don’t. Instead, use this as a learning opportunity.

Open DevTools → Network, filter by XHR or Fetch, and inspect:

• The Origin header on the request
• The presence (or absence) of Access-Control-Allow-Origin on the response

Then configure your dev API to allow the front-end origin. For example, in Express:

import cors from 'cors';

app.use(cors({
  origin: 'http://localhost:3000',
}));

Reload and confirm in DevTools that the response now includes:

Access-Control-Allow-Origin: http://localhost:3000

This is one of the simplest, most reproducible examples of CORS: practical examples with developer tools that every new front-end or full-stack developer should walk through at least once.

Security-focused example of CORS: why “just allow everything” is a bad idea

Because CORS errors are annoying, teams sometimes respond by setting:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Modern browsers reject this combination, but the intent is clear: “make the errors go away.” From a security standpoint, that’s a bad tradeoff.

A better pattern is to:

• Maintain an allowlist of origins (e.g., https://app.example.com, https://admin.example.com)
• Dynamically echo back only the requesting origin if it’s on the list

Then, in DevTools, you can verify that:

• Requests from approved origins get Access-Control-Allow-Origin set correctly
• Requests from unapproved origins either lack the header or return a 403

If you’re working in regulated domains (health, finance, education), this matters even more. For example, if you’re building a patient portal that surfaces data from APIs, CORS is part of your broader web security posture. Organizations like the National Institute of Standards and Technology (NIST) publish guidance on web application security that aligns with careful CORS configuration: https://csrc.nist.gov

FAQ: common questions and examples of CORS in practice

Q: Can you give a simple example of CORS in a single sentence?
A: A simple example of CORS is a web app at https://shop.example.com using fetch() to call an API at https://api.example.com, where the API must return Access-Control-Allow-Origin: https://shop.example.com or the browser blocks the response.

Q: How do I quickly see CORS headers in developer tools?
A: Open DevTools, go to the Network tab, trigger your request, click it, and look under Response Headers for Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Credentials. Those headers are your primary CORS indicators.

Q: Are there examples of CORS issues that only appear in production?
A: Yes. A classic pattern is allowing http://localhost:3000 during development but forgetting to add https://app.example.com in production. In DevTools on the live site, you’ll see the production origin in the Origin request header, but the response will either lack Access-Control-Allow-Origin or still be set to localhost.

Q: Do API clients like Postman or curl care about CORS?
A: No. CORS is enforced by browsers. Postman, curl, and server-side code can call any URL regardless of origin. That’s why an API can work fine in Postman but fail in the browser—developer tools help you see that the difference is CORS.

Q: Where can I find more technical background on CORS behavior?
A: The MDN Web Docs CORS page is an excellent starting point, and the W3C CORS recommendation defines the behavior browsers implement. For broader security context, NIST’s web application security resources provide helpful background.

When you treat these examples of CORS as practical examples with developer tools—rather than abstract rules—you start to see CORS as just another part of HTTP. Open DevTools, watch the headers, and you’ll usually find the answer in under a minute.