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.

Practice

1. What is the main purpose of a preflight request in Express when handling cross-origin requests?

easy

A. To check if the server allows the actual request method and headers before sending it

B. To send the actual data to the server immediately

C. To close the connection after the first request

D. To authenticate the user credentials

Solution

1. Step 1: Understand preflight request role

   A preflight request uses the OPTIONS method to ask the server if the actual request is safe to send.

2. Step 2: Identify what preflight checks

   It checks allowed methods and headers to prevent unauthorized cross-origin requests.

3. Final Answer:

   To check if the server allows the actual request method and headers before sending it -> Option A

4. Quick Check:

   Preflight checks permissions = B [OK]

Hint: Preflight = permission check before real request [OK]

Common Mistakes:

• Thinking preflight sends actual data
• Confusing preflight with authentication
• Assuming preflight closes connection

2. Which Express method is used to handle preflight OPTIONS requests?

easy

A. app.options()

B. app.post()

C. app.get()

D. app.use()

Solution

1. Step 1: Recall HTTP methods in Express

   Express provides methods matching HTTP verbs like get, post, options, etc.

2. Step 2: Identify method for preflight

   Preflight requests use the OPTIONS method, so Express uses app.options() to handle them.

3. Final Answer:

   app.options() -> Option A

4. Quick Check:

   OPTIONS method handled by app.options() [OK]

Hint: Preflight uses OPTIONS, so use app.options() [OK]

Common Mistakes:

• Using app.get() or app.post() for OPTIONS requests
• Confusing app.use() as handler for OPTIONS
• Not handling OPTIONS method at all

3. Consider this Express code snippet handling CORS preflight:

app.options('/data', (req, res) => {
  res.header('Access-Control-Allow-Origin', '*');
  res.header('Access-Control-Allow-Methods', 'GET,POST');
  res.sendStatus(204);
});

What will the server respond to an OPTIONS request to '/data'?

medium

A. Status 404 Not Found

B. Status 204 with headers allowing any origin and GET, POST methods

C. Status 200 with no headers

D. Status 500 Internal Server Error

Solution

1. Step 1: Analyze headers set in response

   The code sets 'Access-Control-Allow-Origin' to '*' allowing any origin, and 'Access-Control-Allow-Methods' to 'GET,POST'.

2. Step 2: Check response status

   res.sendStatus(204) sends HTTP status 204 (No Content) with the headers.

3. Final Answer:

   Status 204 with headers allowing any origin and GET, POST methods -> Option B

4. Quick Check:

   Preflight responds 204 + CORS headers = C [OK]

Hint: 204 status with CORS headers means preflight success [OK]

Common Mistakes:

• Expecting status 200 instead of 204
• Missing CORS headers in response
• Confusing 404 or 500 errors

4. You wrote this Express code to handle preflight requests:

app.options('/api', (req, res) => {
  res.header('Access-Control-Allow-Origin', 'https://example.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT');
  res.end();
});

But the browser still blocks the actual request. What is the likely problem?

medium

A. Access-Control-Allow-Origin should be '*'

B. Using res.end() instead of res.sendStatus(204)

C. Missing Access-Control-Allow-Headers header for custom headers

D. Incorrect URL path in app.options()

Solution

1. Step 1: Understand preflight header requirements

   If the actual request uses custom headers, the server must respond with Access-Control-Allow-Headers listing them.

2. Step 2: Check code for missing headers

   The code does not set Access-Control-Allow-Headers, so browser blocks the request due to missing allowed headers.

3. Final Answer:

   Missing Access-Control-Allow-Headers header for custom headers -> Option C

4. Quick Check:

   Missing allowed headers header blocks request = D [OK]

Hint: Always include Access-Control-Allow-Headers if custom headers used [OK]

Common Mistakes:

• Assuming res.end() causes the block
• Thinking Access-Control-Allow-Origin must be '*' always
• Ignoring missing allowed headers header

5. You want to allow cross-origin requests only from 'https://trusted.com' with methods GET and POST, and allow custom header 'X-Custom-Auth'. Which Express preflight handler is correct?

hard

A. app.options('/resource', (req, res) => {
res.header('Access-Control-Allow-Origin', 'https://trusted.com');
res.header('Access-Control-Allow-Headers', 'X-Custom-Auth');
res.sendStatus(404);
});

B. app.options('/resource', (req, res) => {
res.header('Access-Control-Allow-Origin', '*');
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT');
res.sendStatus(200);
});

C. app.options('/resource', (req, res) => {
res.header('Access-Control-Allow-Origin', 'https://trusted.com');
res.header('Access-Control-Allow-Methods', 'GET');
res.sendStatus(204);
});

D. app.options('/resource', (req, res) => {
res.header('Access-Control-Allow-Origin', 'https://trusted.com');
res.header('Access-Control-Allow-Methods', 'GET, POST');
res.header('Access-Control-Allow-Headers', 'X-Custom-Auth');
res.sendStatus(204);
});

Solution

1. Step 1: Match allowed origin and methods

   app.options('/resource', (req, res) => { res.header('Access-Control-Allow-Origin', 'https://trusted.com'); res.header('Access-Control-Allow-Methods', 'GET, POST'); res.header('Access-Control-Allow-Headers', 'X-Custom-Auth'); res.sendStatus(204); }); sets Access-Control-Allow-Origin to 'https://trusted.com' and methods to 'GET, POST' as required.

2. Step 2: Include custom headers and correct status

   It includes Access-Control-Allow-Headers for 'X-Custom-Auth' and sends status 204 (No Content), which is correct for preflight.

3. Final Answer:

   app.options('/resource', (req, res) => { res.header('Access-Control-Allow-Origin', 'https://trusted.com'); res.header('Access-Control-Allow-Methods', 'GET, POST'); res.header('Access-Control-Allow-Headers', 'X-Custom-Auth'); res.sendStatus(204); }); -> Option D

4. Quick Check:

   Correct origin, methods, headers, and 204 status = A [OK]

Hint: Include origin, methods, headers, and send 204 for preflight [OK]

Common Mistakes:

• Using '*' origin when only one domain allowed
• Missing Access-Control-Allow-Headers for custom headers
• Sending wrong status code like 200 or 404