DEV Community: Alireza Hassankhani

What Is a Simple Request and When Does the Browser Send a Preflight Request?

Alireza Hassankhani — Wed, 15 Jul 2026 11:59:10 +0000

In the previous article, we learned that browsers sometimes send an OPTIONS request before the actual Cross-Origin request. This process is known as a CORS Preflight Request.

But does this happen for every request?

The answer is no.

Browsers only perform a Preflight Request when the request does not qualify as a Simple Request.

What Is a Simple Request?

A Simple Request is a Cross-Origin request that satisfies a specific set of conditions defined by the Fetch specification.

Since these requests are considered low risk, the browser sends them directly without performing a Preflight check.

CORS rules still apply to the response, but no preliminary OPTIONS request is needed.

Requirements for a Simple Request

A request is considered simple only if all of the following conditions are met.

1. HTTP Method

The request method must be one of:

GET
HEAD
POST

Methods such as PUT, PATCH, and DELETE automatically trigger a Preflight Request.

2. Request Headers

The request may only include CORS-safelisted request headers, such as:

Accept
Accept-Language
Content-Language

Adding headers like:

Authorization: Bearer <token>

X-API-Key: 123456

causes the browser to perform a Preflight Request.

3. Content-Type

If the request has a body, its Content-Type must be one of:

application/x-www-form-urlencoded
multipart/form-data
text/plain

Using a content type such as:

application/json

makes the request non-simple and triggers a Preflight Request.

This is one of the most common reasons developers see OPTIONS requests in modern web applications.

Examples

This request is simple:

fetch("/users")

No Preflight Request is sent.

This request is also simple:

fetch("/login", {
  method: "POST",
  headers: {
    "Content-Type": "text/plain"
  }
})

Again, no Preflight is required.

However, this request is not simple:

fetch("/login", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  }
})

The browser first sends an OPTIONS request.

The same happens here:

fetch("/profile", {
  headers: {
    "Authorization": "Bearer token"
  }
})

Because the Authorization header is not CORS-safelisted, a Preflight Request is required.

Summary

A browser sends a Preflight Request only when a Cross-Origin request does not meet the requirements of a Simple Request.

The most common triggers are:

Using methods such as PUT, PATCH, or DELETE
Including non-safelisted headers such as Authorization
Using content types like application/json

This is why seeing an OPTIONS request before the actual request is completely normal in many modern APIs.

Understanding CORS Preflight Requests

Alireza Hassankhani — Wed, 15 Jul 2026 11:32:55 +0000

In the previous article, we introduced the HTTP OPTIONS method and learned that it is commonly used to discover the capabilities of a resource.

Now it's time to understand why browsers sometimes send an OPTIONS request before the actual request.

This process is called a Preflight Request.

Isn't CORS Enough?

As we've already learned, CORS is a browser security mechanism.

If the server does not allow the requesting Origin, the browser prevents JavaScript from accessing the response.

However, this raises an important question.

What if the request itself could perform a sensitive operation on the server?

For example, imagine a Cross-Origin request using the DELETE or PUT method.

If the browser always sent the request first and only blocked the response afterward, the server might already have deleted or modified data before the browser enforced CORS.

To address this problem, browsers perform a Preflight Request for certain Cross-Origin requests.

How Does a Preflight Request Work?

Before sending the actual request, the browser first sends an OPTIONS request to the same endpoint.

The browser is essentially asking:

"Am I allowed to send the upcoming request with these characteristics?"

If the server responds with the appropriate CORS headers, the browser proceeds with the actual request.

Otherwise, the actual request is never sent.

Example

Suppose the application intends to send:

DELETE /users/15 HTTP/1.1
Origin: https://app.example.com

Instead of sending it immediately, the browser first sends:

OPTIONS /users/15 HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: DELETE

This informs the server that a DELETE request is about to be made.

If the server approves it, the browser sends the actual request.

Server Response

A typical response might look like:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: DELETE

Once the browser receives this response, it knows that sending the actual request is permitted.

When Is a Preflight Request Sent?

Browsers do not send a Preflight Request for every Cross-Origin request.

Preflight is only required when the request is not a Simple Request.

We'll define what qualifies as a Simple Request in the next article.

CORS vs. Preflight

Although they're closely related, they serve different purposes.

CORS determines whether JavaScript is allowed to access the response.
Preflight determines whether the browser is allowed to send the actual request in the first place.

In other words, Preflight happens before the request, while CORS enforcement primarily affects access to the response.

In the next article, we'll explore what makes a request "simple" and why only certain requests require a Preflight check.

Understanding the HTTP OPTIONS Method

Alireza Hassankhani — Wed, 15 Jul 2026 10:55:34 +0000

So far, we've explored concepts such as Origin, CORS, and Fetch Credentials.

In the next article, we'll discuss Preflight Requests, but before that, it's important to understand the HTTP OPTIONS method, since browsers rely on it during the preflight process.

What is the OPTIONS Method?

OPTIONS is one of the standard HTTP request methods.

Unlike methods such as GET or POST, which retrieve or modify resources, the OPTIONS method is used to discover the communication capabilities of a server for a particular resource.

In simple terms, the client is asking:

"If I want to interact with this resource, what operations do you support?"

The server typically does not perform any business logic or modify data. Instead, it simply returns information about the resource's supported capabilities.

How is OPTIONS Different from Other HTTP Methods?

Common HTTP methods are designed to perform specific actions:

GET — Retrieve data
POST — Create a resource
PUT — Replace a resource
PATCH — Partially update a resource
DELETE — Remove a resource

The OPTIONS method is different.

Its purpose is not to manipulate resources but to describe what the server is willing to accept for a given endpoint.

For this reason, OPTIONS is generally considered an informational request.

Example Response

Suppose a client sends:

OPTIONS /users HTTP/1.1
Host: api.example.com

The server may respond with:

HTTP/1.1 204 No Content
Allow: GET, POST, PUT, DELETE, OPTIONS

The Allow header lists the HTTP methods supported by the resource.

In many modern APIs, an OPTIONS response may also include additional headers that are especially important for CORS, which we'll cover in the next article.

Do Developers Usually Send OPTIONS Requests?

In most applications, developers rarely send OPTIONS requests manually.

Instead, browsers automatically generate them in specific situations before sending the actual request.

The browser does this to verify whether the upcoming request is permitted.

This automatic verification process is known as a Preflight Request.

Why Should You Understand OPTIONS?

Many developers are surprised when they notice an OPTIONS request in the browser's Network tab and assume their application generated it.

In reality, it's usually the browser performing a protocol-level check before sending the actual request.

Understanding the purpose of the OPTIONS method makes it much easier to understand how CORS Preflight Requests work.

Understanding the credentials Option in the Fetch API

Alireza Hassankhani — Tue, 14 Jul 2026 11:27:09 +0000

In the previous article, we learned how credentials: "include" allows the browser to include eligible Cookies in Cross-Origin requests.

However, include is only one of the available credential modes.

In this article, we'll explore all three values of the credentials option, explain their behavior, and see how they relate to Cookies and CORS.

What is the credentials Option?

The credentials option tells the browser whether authentication-related information should be included with an HTTP request.

This includes:

Cookies
HTTP Authentication credentials
TLS Client Certificates

The Fetch API supports three credential modes:

omit
same-origin
include

Each mode behaves differently.

credentials: "omit"

When omit is used, the browser never includes credentials with the request.

fetch("https://api.example.com/profile", {
  credentials: "omit"
})

In this mode:

Cookies are never sent.
HTTP Authentication credentials are omitted.
TLS Client Certificates are not included.

Even if the user is authenticated, the request is treated as anonymous.

This mode is typically used when requesting public resources.

credentials: "same-origin"

This is the default behavior.

If you don't explicitly specify the credentials option, the browser automatically uses:

credentials: "same-origin"

With this mode:

Credentials are included only for Same-Origin requests.
Credentials are excluded from Cross-Origin requests.

For example, if a request is sent from:

https://app.example.com

to:

https://app.example.com/api

Cookies are included.

However, if the request targets:

https://api.example.com

Cookies are not included because the request is Cross-Origin.

credentials: "include"

The include mode allows the browser to consider credentials even for Cross-Origin requests.

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

This does not guarantee that Cookies will be sent.

Instead, the browser evaluates the Cookie based on attributes such as:

Domain
Path
SameSite
Secure

Only Cookies that satisfy these rules are included in the request.

Relationship with Cookies

The credentials option directly affects whether Cookies are eligible to be included in a request.

In summary:

omit → Never send Cookies.
same-origin → Send Cookies only with Same-Origin requests.
include → Allow eligible Cookies to be included in Cross-Origin requests.

It's important to remember that include only allows the browser to consider Cookies—it does not force them to be sent.

Relationship with CORS

When using:

credentials: "include"

the server should also return:

Access-Control-Allow-Credentials: true

In addition, the Access-Control-Allow-Origin header must contain the requesting Origin rather than a wildcard (*).

These headers determine whether JavaScript is allowed to access the response.

They do not necessarily determine whether the Cookie is sent.

It's entirely possible for the browser to send a Cookie, for the server to process the request successfully, and yet for JavaScript to be denied access to the response because the CORS policy was not satisfied.

Summary

The Fetch API provides three credential modes:

omit — Never send credentials.
same-origin — Send credentials only with Same-Origin requests (default).
include — Allow eligible credentials to be included in Cross-Origin requests.

Understanding these modes is essential when working with authentication, Cookies, Sessions, and CORS in modern web applications.

🍪 Cookies and CORS — When Are Cookies Actually Sent?

Alireza Hassankhani — Mon, 13 Jul 2026 09:45:19 +0000

In the previous article, we briefly discussed the relationship between Cookies and CORS.

In this article, we'll take a closer look at how browsers decide whether a Cookie should be included in a Cross-Origin request.

One of the most common misconceptions is that once CORS is configured correctly, Cookies are automatically sent with every request.

In reality, that's not how browsers work.

📌 Default Browser Behavior

When a Cross-Origin request is made using fetch() or XMLHttpRequest, browsers do not send Cookies, Authorization headers, or other credentials by default.

For example:

fetch("https://api.example.com/profile")

Even if the user is already logged into api.example.com, the browser will not include any Cookies with this request.

This default behavior helps prevent authentication data from being unintentionally leaked across different Origins.

📌 How Can We Send Cookies?

If you want the browser to include Cookies in a Cross-Origin request, you must explicitly use the credentials option.

For example:

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

Using credentials: "include" does not guarantee that Cookies will be sent.

Instead, it tells the browser:

"If there are any Cookies that are eligible to be sent with this request, include them."

📌 What Makes a Cookie Eligible?

Even with credentials: "include", the browser still evaluates the Cookie before sending it.

Some of the most important checks include:

Domain
Path
SameSite

For example:

If the Cookie's Domain doesn't match the request destination, it won't be sent.
If the request path doesn't satisfy the Cookie's Path attribute, it won't be sent.
If the Cookie's SameSite policy blocks Cross-Site requests, it won't be sent.

In other words, credentials is only the first requirement, not the final decision.

📌 Server Configuration Matters Too

If your application expects JavaScript to access the response while using Cookies, the server must also be configured correctly.

For example, the response should include:

Access-Control-Allow-Credentials: true

In addition, the server should return an explicit Origin in:

Access-Control-Allow-Origin

instead of using:

because wildcard Origins cannot be used together with credentials.

📌 An Important Distinction

Sending a Cookie and allowing JavaScript to access the response are two different things.

It's entirely possible for this sequence to happen:

✅ The browser sends the request.
✅ The Cookie is included in the request.
✅ The server receives the Cookie and processes the request.
✅ The server generates a valid response.
❌ The browser blocks JavaScript from reading that response because the CORS policy is not satisfied.

So, a CORS error does not necessarily mean that the Cookie wasn't sent.

It may simply mean that the browser refused to expose the response to JavaScript.

📌 Summary

For a Cookie to be included in a Cross-Origin request, several conditions must be met:

The request must use credentials: "include".
The Cookie itself must satisfy its own rules (Domain, Path, SameSite, etc.).
The server must return Access-Control-Allow-Credentials: true.

Finally, even if the Cookie is successfully sent, an incorrect CORS configuration may still prevent JavaScript from accessing the response.

What is CORS and Why Does It Exist?

Alireza Hassankhani — Mon, 13 Jul 2026 09:40:31 +0000

In the previous article, we learned that an Origin consists of three components:

Scheme (Protocol)
Host
Port

Browsers use these three components to determine whether a request is Same-Origin or Cross-Origin.

Whenever a web page attempts to access resources from a different Origin, a security mechanism called CORS (Cross-Origin Resource Sharing) comes into play.

📌 Why Does a CORS Error Occur?

Suppose your web application is running at:

https://app.example.com

Now it tries to fetch data from:

https://api.example.com

Although both URLs belong to example.com, their Hosts are different.

That means they have different Origins.

As a result, the browser treats this as a Cross-Origin request.

If the destination server does not explicitly allow this Origin, the browser prevents JavaScript from accessing the response, resulting in what we commonly call a CORS Error.

💡 Important: CORS is a browser security mechanism, not a server security mechanism.

⚠️ A Common Misconception About CORS

Many developers believe that a CORS error means the request never reached the server.

In most cases, that's simply not true.

Typically:

✅ The browser sends the request.
✅ The server receives it.
✅ The server generates and returns a response.
❌ The browser blocks JavaScript from accessing that response.

In other words, the request was successful—the browser simply refuses to expose the response to your application because the CORS policy was not satisfied.

This is why sending the exact same request using tools like Postman or curl usually works without any problems.

Those tools are not browsers, so they do not enforce browser security policies like CORS.

📦 How Does the Server Handle CORS?

To allow JavaScript to access the response, the server must include the appropriate CORS headers.

The most important one is:

Access-Control-Allow-Origin: https://app.example.com

This header tells the browser that JavaScript running on https://app.example.com is allowed to read the response.

✅ Examples

Suppose your Front-end is running at:

https://app.example.com

and the server responds with:

Access-Control-Allow-Origin: https://app.example.com

The browser allows JavaScript to access the response. ✅

Now suppose the Front-end is running at:

https://admin.example.com

but the server still responds with:

Access-Control-Allow-Origin: https://app.example.com

The browser blocks access to the response because the Origin does not match. ❌

Another example:

Front-end:

https://evil.com

Server response:

Access-Control-Allow-Origin: https://app.example.com

Again, the browser blocks the response because evil.com is not an allowed Origin.

If the server instead responds with:

Access-Control-Allow-Origin: *

then every Origin is allowed to access the resource.

However, this should only be used for public resources. APIs that require authentication or expose sensitive data should never rely on a wildcard Origin.

📌 CORS and Cookies

When Cookies or other authentication credentials need to be included in a Cross-Origin request, configuring only Access-Control-Allow-Origin is not enough.

Additional settings are required, including:

Access-Control-Allow-Credentials
The credentials option in the Fetch API

We'll cover these in detail in the next article.

📌 Summary

Whenever a request is made to a different Origin, the browser applies the Same-Origin Policy.

If the server explicitly allows the requesting Origin using the appropriate CORS headers, JavaScript is allowed to access the response.

Otherwise, the browser hides the response from JavaScript and reports a CORS error.

This is why fixing CORS issues is usually a Back-end configuration task—not a Front-end one.

the Difference Between Site and Origin

Alireza Hassankhani — Mon, 13 Jul 2026 09:37:32 +0000

🌐 Understanding the Difference Between Site and Origin

Before diving into topics like CORS, the Access-Control-Allow-Origin header, the credentials option in the Fetch API, or even Cookie behavior, it's important to understand two fundamental concepts:

Site
Origin

Many of the errors developers encounter when communicating between the Front-end and Back-end are directly related to these two concepts.

Once you understand the difference between them, browser behavior regarding Cross-Origin and Cross-Site requests becomes much easier to understand.

🌍 Let's Start with Domain and Subdomain

Every website is identified by a Domain.

For example:

example.com

This is a Domain.

If you place another label before the Domain, it becomes a Subdomain.

For example:

api.example.com

In this example:

example.com → Domain
api → Subdomain

Here are a few more examples:

mail.google.com

google.com → Domain
mail → Subdomain

blog.example.com

example.com → Domain
blog → Subdomain

shop.example.com

example.com → Domain
shop → Subdomain

Each Subdomain can host an entirely different service, application, or API—even on a different server or port.

📌 What is an Origin?

An Origin consists of three components:

Scheme (Protocol)
Host
Port

For example:

https://api.example.com:443

Here:

Scheme → https
Host → api.example.com
Port → 443

When determining whether two URLs share the same Origin, the browser compares all three components.

If any one of them changes, the Origin changes.

For example:

https://example.com

and

http://example.com

These are different Origins because the Scheme is different.

Another example:

https://example.com

and

https://api.example.com

These are different Origins because the Host is different.

And finally:

https://example.com

and

https://example.com:8080

These are different Origins because the Port is different.

🌐 What is a Site?

Unlike Origin, a Site is less strict.

A Site consists of:

Scheme (Protocol)
Registrable Domain (eTLD+1)

The Registrable Domain is the main domain that can actually be registered.

For example:

api.example.com

and

blog.example.com

Both belong to the same Registrable Domain:

example.com

Therefore, they are considered Same-Site.

However:

example.com

and

example.org

are Cross-Site because the Registrable Domain is different.

Also remember that the Scheme is part of the Site comparison.

For example:

http://example.com

and

https://example.com

are considered different Sites in modern browsers (Schemeful Same-Site).

⚖️ Site vs Origin

In summary:

Origin compares:

Scheme
Host
Port

Site compares:

Scheme
Registrable Domain

Because of this, two URLs can be:

✅ Same-Site
❌ Different-Origin

For example:

https://api.example.com

and

https://blog.example.com

Result:

✅ Same-Site
❌ Different-Origin

Another example:

https://example.com

and

https://example.com:8080

Result:

✅ Same-Site
❌ Different-Origin

📌 Why Does This Matter?

Browsers rely on these concepts to enforce several important security mechanisms, including:

Same-Origin Policy (SOP)
CORS
Access-Control-Allow-Origin
Fetch API credentials
Cookie SameSite

Understanding the difference between Site and Origin makes it much easier to understand why browsers allow or block certain requests.

In the next article, we'll explore Same-Origin Policy (SOP) and CORS, and see exactly how browsers decide whether a cross-origin request should be accessible to JavaScript.

Cookie attributes

Alireza Hassankhani — Sun, 12 Jul 2026 20:34:50 +0000

🍪

A Deeper Look at Cookie Attributes

📦 Set-Cookie Header

When a server wants to create or update a cookie, it uses the Set-Cookie header in the response.

Example of this header:

Set-Cookie: session_id=ab12cd34ef56; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

At first glance, one might think a cookie is just a Key=Value pair:

session_id=ab12cd34ef56

But in reality, that's only the core part of the cookie.

What the browser actually receives is the Set-Cookie header, which—alongside the main value—includes a set of attributes. These attributes determine:

· Which domain the cookie is valid for
· Which paths it should be sent to
· How long it remains valid
· Whether it should only be sent over HTTPS
· Whether it's accessible via JavaScript
· Whether it should be sent in cross-site requests

Let's examine each of these attributes individually.

🔒 HttpOnly

The HttpOnly attribute specifies that the cookie can only be accessed via the HTTP/HTTPS protocol.

When this attribute is enabled:

· JavaScript cannot access the cookie
· The cookie cannot be read via document.cookie
· The cookie is only sent by the browser when making requests to the server

Why does HttpOnly exist?

One of the most common web attacks is XSS (Cross-Site Scripting).

In this attack, the attacker manages to inject and execute their own JavaScript code on the page. If the cookie does not have HttpOnly set, the attacker can read the user's session cookie and send it to their own server.

Enabling HttpOnly means that even if malicious JavaScript is executed, the session cookie cannot be stolen.

💡 HttpOnly reduces the risk of cookie theft in XSS attacks, but it is not a replacement for preventing the XSS vulnerability itself.

🔐 Secure

The Secure attribute specifies that the cookie should only be sent over a secure HTTPS connection.

If the user is using HTTP, the browser will not send the cookie.

Why does Secure exist?

If a cookie is sent over an unencrypted connection (HTTP), an attacker positioned between the user and the server (Man-in-the-Middle) can eavesdrop on the traffic and view or steal the cookie.

Enabling Secure ensures the cookie is only transmitted over an encrypted connection, drastically reducing the risk of it being stolen in transit.

🌍 Domain

The Domain attribute specifies which domain the cookie is valid for.

For example:

Domain=example.com

In this case, the cookie will be usable for the main domain and, typically, its subdomains as well.

However, if Domain is set to another domain, the browser will not send the cookie for that domain.

This attribute defines the scope of the cookie's validity.

📂 Path

The Path attribute determines which URL paths on the website the cookie should be sent to.

For example:

Path=/admin

In this case, the cookie will only be sent for requests that fall under the /admin path.

This feature ensures the cookie is only used in parts of the site where it's actually needed.

⏳ Expires

The Expires attribute specifies the exact expiration date and time of the cookie.

For example:

Expires=Wed, 01 Jan 2027 00:00:00 GMT

After this date is reached, the browser will delete the cookie.

⌛ Max-Age

The Max-Age attribute specifies the lifetime of the cookie in seconds.

For example:

Max-Age=3600

This means the cookie will be deleted exactly one hour after it was created.

Difference Between Max-Age and Expires

Both are used to determine when the cookie should be deleted, but they have an important difference:

· Expires stores a specific date and time.
· Max-Age specifies the remaining lifetime from the moment the cookie is created.

For this reason, Max-Age is generally considered more reliable, as it does not depend on the user's system clock.

🛡️ SameSite

The SameSite attribute specifies whether the cookie should be sent in requests originating from other sites.

The main purpose of this attribute is to reduce the risk of CSRF (Cross-Site Request Forgery) attacks.

Its common values are:

· Strict → The cookie is only sent in same-site requests.
· Lax → The cookie is sent in most normal requests, but restricts many cross-site requests.
· None → The cookie is sent in all requests; in this case, using Secure is also mandatory.

Proper use of SameSite can be one of the most important defense layers against CSRF attacks.

📌 Summary

Each cookie attribute is designed to solve a specific security or functionality issue:

· HttpOnly → Reduces the risk of cookie theft in XSS attacks
· Secure → Prevents the cookie from being sent over insecure connections and reduces Man-in-the-Middle risks
· SameSite → Reduces the likelihood of successful CSRF attacks
· Domain → Defines which domains are allowed for the cookie
· Path → Defines which URL paths are allowed to receive the cookie
· Expires → Defines the expiration date
· Max-Age → Defines the cookie's lifetime in seconds

Understanding these attributes is one of the most important prerequisites for learning web security, because many common vulnerabilities are directly related to misconfiguring these very options.