Forem: Aaron Yong

Why Postman Works But Your Browser Doesn't

Aaron Yong — Sun, 19 Apr 2026 15:43:22 +0000

It's 11pm. Your React frontend is running on localhost:5173. Your API is running on localhost:8080. You hit the endpoint from Postman — 200 OK, beautiful JSON, everything works. You hit the same endpoint from your frontend — red text in the console, something about "Access-Control-Allow-Origin," and an undefined response body. You paste the error into Google, add Access-Control-Allow-Origin: * to your server, and move on.

I've done this. You've done this. We've all done this. But that quick fix papers over a mechanism that's genuinely worth understanding — because when CORS breaks in production (and it will), the fix isn't always a wildcard.

Netscape Started This (In 1995)

To understand CORS, you have to understand the thing it relaxes: the Same-Origin Policy. SOP shipped in Netscape Navigator 2.0 in 1995, at the exact same time as JavaScript. The timing isn't a coincidence — the moment browsers could run scripts that make network requests and read the DOM, they needed a boundary to prevent one site from reading another site's data.

An "origin" is three things: scheme + host + port. https://example.com:443 is one origin. Change any of the three — swap https for http, change example.com to api.example.com, use port 8080 instead of 443 — and you've got a different origin.

That subdomain thing catches people: app.example.com and api.example.com are cross-origin, even though they share a root domain. This is the exact scenario that produces most CORS errors in the wild.

Without SOP, a malicious ad on a news site could silently fetch your Gmail inbox using your authenticated cookies. A phishing page could read your bank balance from another tab. SOP prevents that by blocking JavaScript from reading cross-origin responses. The web as a platform for banking, email, and private data depends on this one rule.

The Most Misunderstood Error on the Internet

Here's the thing that confuses everyone: CORS errors don't mean the server blocked your request. The request was sent. The server received it, processed it, and returned a response. The browser just won't let your JavaScript read that response because the server didn't include the right headers.

What actually happens:

1. Your JS calls fetch('https://api.example.com/data')
2. Browser sends the request (yes, it leaves your machine)
3. Server processes it, returns 200 OK with data
4. Browser checks: does the response have Access-Control-Allow-Origin?
5. Nope → browser hides the response from your JavaScript
6. Console: "has been blocked by CORS policy"

This is why Postman works. Postman isn't a browser — it doesn't enforce SOP. Neither does curl, nor server-to-server HTTP calls, nor mobile apps making direct API requests. CORS is exclusively a browser-enforced protocol, because browsers are the only environment that runs untrusted JavaScript from arbitrary origins.

The server's CORS headers are essentially a permission slip: "yes, I expect requests from https://app.example.com, and it's OK for their JavaScript to read my responses."

The OPTIONS Interrogation

Now for the part that really baffles people: sometimes the browser sends two requests instead of one. Before your actual PUT /api/users with Content-Type: application/json, the browser sends an OPTIONS /api/users — a "preflight" request asking the server for permission.

Not every request gets a preflight. The browser divides cross-origin requests into "simple" and "not simple":

Simple (no preflight): GET, HEAD, or POST — but only if the headers are basic (Accept, Content-Language, Content-Type) and the content type is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain.

Not simple (preflight required): anything else. PUT, DELETE, PATCH, any custom header like Authorization, or Content-Type: application/json.

Why this specific split? It's actually brilliant: the "simple" criteria match exactly what an HTML <form> could already do before JavaScript existed. A form could always POST application/x-www-form-urlencoded data to any URL. SOP never blocked that, so CORS doesn't add a preflight for it either. The preflight only kicks in for requests that JavaScript made newly possible — the ones that couldn't happen before the fetch API.

Here's the preflight dance:

Browser                              Server
  │                                    │
  │── OPTIONS /api/users ─────────────>│  "Can I PUT with JSON + Auth?"
  │   Origin: https://app.com          │
  │   Access-Control-Request-Method:   │
  │     PUT                            │
  │   Access-Control-Request-Headers:  │
  │     Content-Type, Authorization    │
  │                                    │
  │<── 204 ────────────────────────────│  "Yes, here's what I allow"
  │   Access-Control-Allow-Origin:     │
  │     https://app.com               │
  │   Access-Control-Allow-Methods:    │
  │     GET, POST, PUT, DELETE        │
  │   Access-Control-Max-Age: 86400   │
  │                                    │
  │── PUT /api/users ─────────────────>│  (actual request, now permitted)
  │   { "name": "Aaron" }             │

That Access-Control-Max-Age: 86400 header tells the browser to cache the preflight result for 24 hours. Without it, every single non-simple request fires two HTTP calls — your API traffic doubles for no reason. (Chrome caps the cache at 2 hours regardless of what you set, because of course it does.)

The Credentials Trap

By default, cross-origin requests don't send cookies or auth headers. If you want them included:

// Client: explicitly opt in
fetch("https://api.example.com/data", {
  credentials: "include", // now cookies are sent cross-origin
});

But this comes with a hard rule: the server cannot respond with Access-Control-Allow-Origin: * when credentials are involved. It must be the specific origin:

Access-Control-Allow-Origin: https://app.example.com  # specific, not *
Access-Control-Allow-Credentials: true

This is deliberate. If * worked with credentials, any website on the internet could make authenticated requests to your API and read the responses. That's not a CORS misconfiguration — that's a data breach waiting to happen.

The Config Across Stacks

I've set up CORS in Spring Boot, Express, and nginx at this point, and the patterns are similar but the gotchas are stack-specific.

In Express, the cors package handles OPTIONS automatically — you barely think about it:

import cors from "cors";
app.use(
  cors({
    origin: "http://localhost:5173", // Vite dev server
    credentials: true,
  }),
);

In Spring Boot, forgetting to include OPTIONS in allowedMethods is a classic silent failure — preflights just return 403 and the console error gives you nothing useful:

registry.addMapping("/api/**")
    .allowedOrigins("http://localhost:5173")
    .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")  // don't forget OPTIONS
    .allowCredentials(true);

And in nginx, the sneakiest bug is configuring CORS in both nginx and the app server, which produces duplicate Access-Control-Allow-Origin headers. The browser rejects that too. Pick one place to handle CORS — never both.

"Wait, We Don't Even Need CORS?"

Here's the plot twist most tutorials skip: in production, you often don't need CORS at all. If your frontend and API are served from the same origin via a reverse proxy, there's no cross-origin request:

Development (CORS needed):
  localhost:5173  ──fetch──>  localhost:8080  ← different ports = different origin

Production (no CORS):
  example.com  ──fetch──>  example.com/api/
       │                        │
       └── nginx serves         └── nginx proxies to backend:8080
           static files

Same scheme, same host, same port. Same origin. No CORS headers needed. The browser never even checks. This is the pattern most production deployments end up using — nginx (or Cloudflare, or your platform's edge proxy) sits in front of everything, making the frontend and API appear as one origin.

CORS configuration then becomes a development-only concern: your Vite dev server on port 5173 and your API on port 8080 are different origins. Once you deploy behind a proxy, the problem dissolves.

Don't Do This (Please)

A few CORS configurations that will make your security team cry:

Reflecting any origin: Server blindly echoes back whatever Origin header the browser sends, with credentials: true. This is equivalent to no security at all. Any malicious site can read your authenticated API responses.

Trusting null origin: The null origin sounds harmless, but attackers can trigger it from sandboxed iframes. If your server trusts Origin: null with credentials, you have a vulnerability.

Suffix matching: if (origin.endsWith('.example.com')) also matches evil-example.com. Always validate the full origin string, not just a suffix.

Origin Story (Pun Intended)

CORS is one of those things that seems like a nuisance until you understand what it's protecting. The Same-Origin Policy has been the security backbone of the web since 1995 — before cookies had SameSite, before CSP existed, before CSRF tokens were standard practice. CORS doesn't weaken that protection; it gives servers a structured way to poke specific, controlled holes in it.

Next time you see that red console error, at least you'll know: your server got the request just fine. It's the browser that's looking out for you.

The Data Structure That's Okay With Being Wrong

Aaron Yong — Thu, 02 Apr 2026 03:04:08 +0000

The Million-Row Problem

You're building a URL shortener. Every time someone creates a short link, you generate a random code and check if it already exists in the database. One database query per attempt. At 1,000 URLs, this is fine — the query takes a millisecond, the index is tiny, nobody notices.

At 100 million URLs, you're generating codes that collide more often (birthday paradox), each collision triggers another database round trip, and those round trips add up under high throughput. You're not slow because your code is bad — you're slow because you're asking the database a question it doesn't need to answer.

What if you could check "does this code already exist?" without touching the database at all?

A Bit Array With an Attitude

A Bloom filter is a bit array (say, 20 bits, all starting at 0) combined with a handful of hash functions. Let me walk through the full lifecycle:

Starting state — empty bit array:

  [0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
   0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19


Check "abc123" — is it in the set?
  hash1 → position 3  → 0 ❌
  → "Definitely not" (one zero = guaranteed absent, no need to check other hashes)


Insert "abc123":
  hash1 → position 3
  hash2 → position 8
  hash3 → position 14

  [0][0][0][1][0][0][0][0][1][0][0][0][0][0][1][0][0][0][0][0]
            ^               ^                 ^
            3               8                14


Check "abc123" — is it in the set now?
  hash1 → position 3  → 1 ✅
  hash2 → position 8  → 1 ✅
  hash3 → position 14 → 1 ✅
  → "Probably exists" ✓ (correct — we just inserted it)


Check "xyz789" — is it in the set?
  hash1 → position 3  → 1 ✅ (set by abc123!)
  hash2 → position 6  → 0 ❌
  → "Definitely not" (one zero = guaranteed absent)


Insert "xyz789":
  hash1 → position 3  (already 1 — shared with abc123)
  hash2 → position 6
  hash3 → position 17

  [0][0][0][1][0][0][1][0][1][0][0][0][0][0][1][0][0][1][0][0]
            ^        ^     ^                 ^        ^
            3(shared) 6    8                14       17


Check "def456" — is it in the set? (we NEVER inserted it)
  hash1 → position 3  → 1 ✅ (set by abc123)
  hash2 → position 6  → 1 ✅ (set by xyz789)
  hash3 → position 14 → 1 ✅ (set by abc123)
  → "Probably exists" ✗ FALSE POSITIVE!
    (all bits happen to be set by OTHER elements)


Check "nope00" — is it in the set?
  hash1 → position 2  → 0 ❌
  → "Definitely not" ✓ (correct — one zero bit = guaranteed absent)

The "def456" check is the key insight. It was never inserted, but all three of its hash positions were coincidentally set by other elements. That's a false positive — the Bloom filter is wrong, but it's wrong in a predictable, controllable way.

Two possible answers:

"Definitely not in the set" — 100% correct, every time
"Probably in the set" — correct most of the time, occasionally wrong (false positive)

It never gives false negatives. If it says no, you can trust it completely.

Why Would You Want an Inaccurate Data Structure?

Because it's absurdly small and fast.

	Hash Set	Database Query	Bloom Filter
Memory	O(n) — stores all values	0 (on disk)	Fixed size bit array
Lookup speed	O(1)	~1ms (network + index)	O(1) — a few hash computations
Accuracy	100%	100%	~99%+ (configurable)
Can delete?	Yes	Yes	No
Network call?	No	Yes	No

A Bloom filter storing 1 million items with a 0.1% false positive rate uses about 1.8 MB of memory. A HashSet storing the same 1 million strings uses 50-100 MB. The database stores them on disk but needs a network round trip for every check.

The Bloom filter trades a tiny amount of accuracy for a massive reduction in memory and the elimination of network calls. For many use cases, that trade-off is more than worth it.

The URL Shortener, Optimized

Here's how this applies to the problem from the intro:

import { BloomFilter } from "bloom-filters";

const bloom = BloomFilter.create(1_000_000, 0.001); // 1M capacity, 0.1% false positive

function generateUniqueCode(): string {
  for (let i = 0; i < MAX_RETRIES; i++) {
    const code = randomBase62(6);

    if (bloom.has(code)) continue; // in-memory check (~1μs)

    // Bloom says "definitely not exists" — verify with DB as safety net
    const exists = await db.url.findUnique({ where: { shortCode: code } });
    if (!exists) {
      bloom.add(code);
      return code;
    }
  }
  throw new Error("Failed to generate unique code");
}

The Bloom filter handles the common case: the code doesn't exist (which is true for the vast majority of attempts). Only when the Bloom filter says "probably exists" — either correctly or as a false positive — do we fall back to the database. At 100 million URLs, this eliminates 99%+ of database queries for code generation.

The database is still the source of truth. The Bloom filter is a fast, cheap pre-filter that prevents unnecessary round trips. It's the same principle as caching — avoid the expensive operation when you already know the answer.

The Tuning Knob

You control the false positive rate. Lower rate = more memory:

Items	False Positive Rate	Memory
1M	1%	~1.2 MB
1M	0.1%	~1.8 MB
1M	0.01%	~2.4 MB
10M	0.1%	~18 MB
100M	0.1%	~180 MB

Even at 100 million items with 0.1% false positives, you're using 180 MB — less than a single Chrome tab. A HashSet storing 100 million strings would need several gigabytes.

Where Bloom Filters Show Up in Production

This isn't a theoretical data structure. It's used at massive scale:

Google Chrome checks every URL you visit against a local Bloom filter of known malicious sites. If the Bloom filter says "not malicious" (which is almost always), Chrome skips the network call to the Safe Browsing API entirely. Only on a "probably malicious" hit does it make the API call to confirm.

Cassandra and HBase use Bloom filters to check if a row exists in an SSTable before reading from disk. Disk reads are expensive. A Bloom filter that says "definitely not in this file" saves a disk seek.

Medium uses Bloom filters to track which articles a user has already seen, so recommendations don't show duplicates. Storing "user X has seen articles [1, 2, 3, ..., 10000]" for millions of users as full sets would be massive. Bloom filters compress this to a few KB per user.

Bitcoin SPV (Simplified Payment Verification) nodes use Bloom filters to request only relevant transactions from full nodes without downloading the entire blockchain.

When to Use It

Scenario	Bloom Filter?	Why
Pre-filter before expensive lookup (DB, disk, API)	Yes	Eliminates most unnecessary lookups
Web crawler ("have I visited this URL?")	Yes	Millions of URLs, memory-efficient
Spell checker ("is this a real word?")	Yes	Dictionary is static, fast lookup
Cache miss prevention	Yes	Avoid DB query when key isn't cached
Duplicate detection in streams	Yes	Can't store all seen items in memory

When NOT to Use It

You need to delete elements — standard Bloom filters don't support deletion (flipping a bit to 0 might affect other elements). Counting Bloom filters exist but add complexity.
False positives are unacceptable — financial transactions, access control, anything where "probably yes" isn't good enough.
The dataset fits in a regular Set — if you have 10,000 items, just use a HashSet. Bloom filters shine at millions+.
You need to retrieve the actual values — Bloom filters only answer "exists?" They don't store or return the elements themselves.

The Pattern

Bloom filters fit into the same optimization philosophy as caching and indexing: avoid the expensive operation when a cheaper check can give you the answer first.

Request comes in
  → Check Bloom filter (nanoseconds, in-memory)
    → "Definitely not" → skip the expensive lookup
    → "Probably yes" → do the actual lookup to confirm

It's not about replacing your database or your cache. It's about putting a cheap, fast guard in front of them so they only do work when it matters. Another tool in the optimize before you scale toolkit.