Preflight requests behavior in Express - Deep Dive

Overview - Preflight requests behavior

What is it?

Preflight requests are special HTTP requests browsers send before the actual request when making cross-origin calls that might affect user data. They use the OPTIONS method to check if the server allows the real request with certain methods or headers. This helps browsers protect users by confirming permissions before sending sensitive data. Express is a popular Node.js framework where you can handle these preflight requests to control cross-origin resource sharing (CORS).

Why it matters

Without preflight requests, browsers would blindly send cross-origin requests that might be unsafe or violate server policies, risking user data and security. Preflight requests act like a permission check, preventing harmful or unauthorized interactions between websites and servers. For developers, understanding and handling preflight requests correctly ensures their APIs are secure and accessible only as intended, avoiding frustrating errors for users.

Where it fits

Before learning about preflight requests, you should understand basic HTTP methods and CORS concepts. After mastering preflight behavior, you can explore advanced CORS configurations, security best practices in Express, and how to optimize API responses for cross-origin calls.

Mental Model

Core Idea

A preflight request is a browser's way of asking permission before sending a risky cross-origin request.

Think of it like...

It's like knocking on a door and asking if it's okay to enter before actually walking in, ensuring the host is ready and willing to receive you.

Browser ──OPTIONS (Preflight)──▶ Server
  │                             │
  ◀─────────Allow?─────────────
  │                             │
Browser ──Actual Request──────▶ Server

Build-Up - 7 Steps

1

Foundation

Understanding Cross-Origin Requests

Concept: Cross-origin requests happen when a web page tries to get data from a different domain than its own.

When a website at example.com tries to fetch data from api.otherdomain.com, the browser treats this as a cross-origin request. Browsers restrict these requests for security reasons to prevent malicious sites from stealing data.

Result

You learn that browsers block or limit cross-origin requests unless the server explicitly allows them.

Understanding cross-origin requests is essential because preflight requests only happen in this context to protect users.

2

Foundation

Basics of HTTP OPTIONS Method

Concept: The OPTIONS method asks a server what HTTP methods and headers it supports for a given resource.

Unlike GET or POST, OPTIONS doesn't fetch data but checks permissions. Browsers use OPTIONS to send preflight requests to verify if the real request is safe to send.

Result

You see that OPTIONS requests return headers like Access-Control-Allow-Methods, telling the browser what is allowed.

Knowing the OPTIONS method helps you understand how preflight requests communicate permissions before actual data exchange.

3

Intermediate

When Browsers Send Preflight Requests

🤔Before reading on: do you think preflight requests happen for all cross-origin requests or only some? Commit to your answer.

Concept: Browsers send preflight requests only for cross-origin requests that use methods other than GET, POST, or have custom headers.

If a request uses methods like PUT, DELETE, or custom headers like Authorization, the browser sends an OPTIONS preflight first. Simple GET or POST requests with standard headers usually skip preflight.

Result

You understand that preflight requests are conditional, optimizing network traffic by avoiding unnecessary checks.

Knowing when preflight requests occur helps you design APIs and clients to minimize delays and errors.

4

Intermediate

Handling Preflight in Express

🤔Before reading on: do you think Express handles preflight requests automatically or do you need to add code? Commit to your answer.

Concept: Express does not handle preflight requests by default; you must add middleware to respond properly to OPTIONS requests.

You can use the cors package or write custom middleware to respond to OPTIONS requests with appropriate headers like Access-Control-Allow-Origin and Access-Control-Allow-Methods.

Result

Your Express server correctly replies to preflight requests, allowing browsers to proceed with actual requests.

Understanding Express's role in preflight handling prevents common CORS errors and improves API usability.

5

Intermediate

CORS Headers in Preflight Responses

Concept: Preflight responses include headers that tell the browser what is allowed for the actual request.

Headers like Access-Control-Allow-Origin specify which domains can access the resource. Access-Control-Allow-Methods lists allowed HTTP methods. Access-Control-Allow-Headers lists allowed custom headers. These headers guide the browser's decision.

Result

You see how servers communicate permissions clearly to browsers before sensitive requests.

Knowing these headers helps you configure servers to balance security and accessibility.

6

Advanced

Optimizing Preflight Requests in Production

🤔Before reading on: do you think reducing preflight requests improves performance or is negligible? Commit to your answer.

Concept: Reducing unnecessary preflight requests improves user experience by lowering latency and server load.

You can optimize by using simple requests when possible, caching preflight responses with Access-Control-Max-Age, and minimizing custom headers. Express middleware can be tuned to send minimal headers and cache preflight results.

Result

Your application feels faster and scales better under load.

Understanding preflight optimization is key for building responsive, scalable web APIs.

7

Expert

Surprising Preflight Behavior and Edge Cases

🤔Before reading on: do you think changing request headers after preflight affects browser behavior? Commit to your answer.

Concept: Browsers strictly match preflight requests to actual requests; mismatches cause failures. Also, some proxies or servers may strip OPTIONS requests, breaking preflight.

If the actual request differs from the preflight in headers or method, the browser blocks it. Some network tools or firewalls may block OPTIONS, causing silent failures. Express apps must ensure OPTIONS requests are handled early and consistently.

Result

You avoid subtle bugs that cause CORS errors only in certain environments or after code changes.

Knowing these edge cases prevents frustrating debugging and ensures robust cross-origin support.

Under the Hood

When a browser detects a cross-origin request with special methods or headers, it sends an OPTIONS request to the server with headers describing the intended actual request. The server responds with headers indicating allowed origins, methods, and headers. The browser compares this response to its intended request. If allowed, it sends the actual request; otherwise, it blocks it. Express servers must listen for OPTIONS requests and respond with correct CORS headers to satisfy the browser's checks.

Why designed this way?

Preflight requests were designed to protect users from malicious cross-site requests that could steal data or perform unwanted actions. By requiring explicit permission before sending sensitive requests, browsers enforce security policies without blocking all cross-origin communication. This design balances security and flexibility, allowing safe cross-origin interactions while preventing attacks like CSRF.

┌───────────────┐       OPTIONS Request       ┌───────────────┐
│   Browser     │ ──────────────────────────▶ │    Server     │
└───────────────┘                            └───────────────┘
        ▲                                            │
        │                                            │
        │          Access-Control-Allow-* Headers   │
        │ ◀─────────────────────────────────────────┤
        │                                            │
        │                                            ▼
┌───────────────┐       Actual Request (GET/POST)  ┌───────────────┐
│   Browser     │ ───────────────────────────────▶ │    Server     │
└───────────────┘                            └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think preflight requests happen for every cross-origin request? Commit to yes or no.

Common Belief: Preflight requests happen for every cross-origin request regardless of method or headers.

Reality: Preflight requests only happen for cross-origin requests that use methods other than GET, POST, or have custom headers.

Why it matters: Assuming all requests preflight leads to unnecessary debugging and performance worries.

Quick: Do you think Express automatically handles preflight OPTIONS requests? Commit to yes or no.

Common Belief: Express automatically handles preflight requests without extra code.

Reality: Express does not handle OPTIONS requests by default; you must add middleware or use packages like cors.

Why it matters: Not handling OPTIONS causes CORS errors and blocked requests in browsers.

Quick: Do you think changing headers after preflight is allowed? Commit to yes or no.

Common Belief: You can change request headers after the preflight request without issues.

Reality: The actual request must match the preflight request's headers exactly; otherwise, the browser blocks it.

Why it matters: Mismatch causes silent failures that are hard to debug.

Quick: Do you think caching preflight responses is unsafe? Commit to yes or no.

Common Belief: Caching preflight responses risks security and should be avoided.

Reality: Caching preflight responses with Access-Control-Max-Age improves performance without compromising security if configured correctly.

Why it matters: Avoiding caching leads to unnecessary network overhead and slower user experiences.

Expert Zone

1

Preflight requests can be cached by browsers, but the cache duration depends on Access-Control-Max-Age, which varies by browser and server configuration.

2

Some corporate proxies or firewalls block OPTIONS requests, causing preflight failures that are unrelated to server code but affect production environments.

3

Express middleware order matters: OPTIONS handlers must run before other middleware that might block or modify requests to ensure correct preflight responses.

When NOT to use

Preflight requests are a browser security feature and cannot be disabled. However, if you control both client and server, you can avoid preflights by using simple requests (GET/POST with standard headers). For APIs that require complex headers or methods, preflight handling is mandatory. Alternatives include JSONP or server-side proxies, but these have their own limitations and security concerns.

Production Patterns

In production, Express apps often use the cors package configured with specific origins, methods, and headers to handle preflight automatically. They also set Access-Control-Max-Age to cache preflight responses. Monitoring logs for OPTIONS requests helps detect blocked preflights. Some teams implement middleware to respond quickly to OPTIONS requests without full authentication to reduce latency.

Connections

Cross-Origin Resource Sharing (CORS)

Preflight requests are a core part of the CORS protocol.

Understanding preflight behavior deepens comprehension of how CORS enforces web security policies.

HTTP Methods and Headers

Preflight requests check which HTTP methods and headers are allowed before sending the actual request.

Knowing HTTP methods and headers helps predict when preflights occur and how to configure servers.

Security Permission Checks in Operating Systems

Preflight requests are like permission checks before accessing protected resources, similar to OS file permission dialogs.

Recognizing preflight as a permission step helps appreciate its role in preventing unauthorized access.

Common Pitfalls

#1 Not handling OPTIONS requests in Express causes CORS errors.

Wrong approach:

app.use((req, res) => { res.send('Hello'); }); // No OPTIONS handler

Correct approach:

app.options('*', cors()); // Handle preflight with cors middleware

Root cause:

Express does not automatically respond to OPTIONS requests, so browsers block cross-origin calls without proper handling.

#2 Sending different headers in actual request than in preflight causes failures.

Wrong approach:

Preflight allows Authorization header, but actual request omits it or adds extra headers.

Correct approach:

Ensure actual request headers exactly match those declared in preflight.

Root cause:

Browsers enforce strict matching between preflight and actual requests to prevent security risks.

#3 Not setting Access-Control-Allow-Origin or setting it incorrectly blocks requests.

Wrong approach:

res.setHeader('Access-Control-Allow-Origin', ''); // Empty or missing origin

Correct approach:

res.setHeader('Access-Control-Allow-Origin', 'https://example.com');

Root cause:

The server must explicitly allow origins; empty or missing headers cause browsers to block responses.

Key Takeaways

Preflight requests are browser-sent OPTIONS requests that check server permissions before risky cross-origin calls.

They only happen for certain HTTP methods or custom headers, not all cross-origin requests.

Express requires explicit middleware to handle preflight requests and send correct CORS headers.

Proper handling and optimization of preflight requests improve security, performance, and user experience.

Understanding preflight edge cases and browser behavior prevents common CORS errors in production.