Forem: Parmesh B

If a backend endpoint is public (allowed from any origin), browsers don’t send cookies by default. And if you try to send cookies, you’ll likely face a CORS error unless the backend is properly configured. I wrote a full blog with details 👇

Parmesh B — Sat, 04 Oct 2025 12:50:26 +0000

Parmesh B

Oct 4 '25

Understanding Cookie Transmission in Cross-Origin API Requests

#frontend #backend #learning #development

Comments

5 min read

Understanding Cookie Transmission in Cross-Origin API Requests

Parmesh B — Sat, 04 Oct 2025 12:40:35 +0000

The Problem That Cost Me 2 Hours

Picture this: Your frontend is calling a public API endpoint. No authentication barriers, no token requirements—just a simple, open endpoint. Everything should work smoothly, right?

Wrong.

I spent over 2 hours pulling my hair out because my cookies weren't being sent with the requests. The API was public, my code looked fine, but the browser simply refused to include the cookies I needed.

After diving deep into browser behavior, CORS policies, and cookie attributes, I finally understood what was happening. Here's everything I learned so you don't have to waste your afternoon debugging the same issue.

The Big Misconception: Public ≠ Cookie Freedom

Here's the crucial insight that took me way too long to understand:

Just because an endpoint is public doesn't mean the browser will freely send cookies to it.

A "public API" simply means there's no authentication barrier blocking access. But whether cookies are included in requests depends on an entirely different set of rules around:

Cookie attributes
Cross-origin request policies
CORS configuration

The browser doesn't care if the endpoint is "public" or "private"—it cares about security, and it enforces strict rules to protect users from attacks like CSRF (Cross-Site Request Forgery).

The Three Factors That Control Cookie Transmission

After hours of debugging and reading documentation, I identified three critical factors that determine whether cookies are sent with cross-origin requests:

1. SameSite Attribute: The Gatekeeper

The SameSiteattribute is the first line of defense. It tells the browser when a cookie should be included:

SameSite=Strict

Cookie is ONLY sent on same-site requests
Cross-site requests? Forget about it—no cookies for you
Most secure, but breaks legitimate cross-site use cases

SameSite=Lax (default in modern browsers)

Cookie sent on same-site requests
Also sent on top-level navigations (like clicking a link)
NOT sent on cross-site API calls (like fetch or axios requests)

SameSite=None; Secure

Allows cookies on cross-site requests
MUST be paired with the Secure flag
Required for cookies to work in cross-origin API scenarios

Key takeaway: If your backend sets cookies without SameSite=None; Secure, they won't be sent in cross-origin API calls, period.

2. Client-Side Configuration: Ask for Credentials

Even with the right cookie attributes, you need to explicitly tell the browser to include cookies in cross-origin requests.

With Fetch API:

javascript

fetch({your_endpoint}, { credentials: 'include' // This is the magic line })

With Axios:

javascript

axios.get({your_endpoint}, { withCredentials: true // Enable cookie transmission })

Without these flags, the browser assumes you don't want cookies sent cross-origin, and it won't include them—even if everything else is configured correctly.

3. Server-Side CORS Headers: The Final Permission

Here's where my 2-hour bug was hiding: the server must explicitly allow credentialed requests with proper CORS headers.

Required headers:

`Access-Control-Allow-Credentials: true

Critical rules:

You CANNOT use Access-Control-Allow-Origin: * with credentials
The origin must be specific
Both headers must be present for cookies to be sent

In my case, the frontend had withCredentials: true, but the backend team hadn't configured these CORS headers. The browser saw the mismatch and silently blocked the cookies.

Other Cookie Flags Worth Understanding

While debugging, I also learned about two other important cookie attributes:

HttpOnly

Prevents JavaScript from accessing the cookie via document.cookie
Does NOT prevent the browser from sending it in HTTP requests
Great for security (prevents XSS attacks from stealing session cookies)

Secure

Cookie will ONLY be sent over HTTPS connections
Essential for production environments
Required when using SameSite=None

My Debugging Story: What Went Wrong

Here's exactly what happened in my case:

Frontend setup: I was using axios with withCredentials: true ✅
Cookie attributes: Backend was setting cookies, but without proper SameSite attributes ❌
CORS headers: The public API team hadn't configured Access-Control-Allow-Credentials or a specific Access-Control-Allow-Origin ❌

The result? The browser looked at this mismatched configuration and said, "Nope, not sending those cookies."

Once the backend team added:

SameSite=None; Secure to the cookies
Access-Control-Allow-Credentials: true

Everything worked perfectly.

The Complete Checklist for Cross-Origin Cookies

Before you waste hours debugging like I did, check these three things:

✅ Backend Cookie Configuration

Cookies set with SameSite=None; Secure
Secure flag present (requires HTTPS)
HttpOnly flag if you don't need JS access

✅ Frontend Request Configuration

withCredentials: true (Axios) or credentials: 'include' (Fetch)
Requests are going to the correct domain

✅ Server CORS Headers

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin set to a specific origin (NOT *)
Headers present on both preflight and actual responses

All three must align perfectly, or cookies won't be sent.

Pro Debugging Tips

Chrome DevTools is your friend:

Open DevTools → Network tab
Click on the failed request
Go to the "Cookies" tab
Look for blocked cookies and the reason why

The browser will tell you exactly why cookies were blocked—you just need to know where to look!

The Bigger Picture: Why Browsers Are So Strict

You might wonder: "Why make this so complicated? Why not just send cookies everywhere?"

The answer is security. These restrictions exist to protect users from:

CSRF attacks: Malicious sites make requests on your behalf to legitimate sites where you're logged in
Data leakage: Third-party sites accessing your cookies and session data
Privacy violations: Tracking users across different websites

The browser assumes cookies contain sensitive data (like session tokens), so it requires explicit permission from both the client AND server before allowing cross-origin transmission.

Yes, it makes development harder. But it also keeps users safe.

Key Takeaways

After spending 2 hours on this bug, here's what I want you to remember:

"Public endpoint" doesn't mean "free cookie access"—browsers enforce strict security rules regardless of API accessibility

Three things must align:

Cookie attributes (SameSite=None; Secure)
Client configuration (withCredentials: true)
Server CORS headers (Allow-Credentials + specific Allow-Origin)

Silent failures are the worst—browsers often block cookies without obvious error messages, so know how to use DevTools to debug

This is a backend AND frontend problem—you can't fix it from just one side

Security over convenience—these restrictions exist for good reasons, even if they complicate development

Final Thoughts

Cross-origin cookie handling is one of those topics that seems simple until you actually need to implement it. The combination of cookie attributes, CORS policies, and browser security rules creates a complex system that's easy to misconfigure.

But once you understand the rules, debugging becomes much easier. Instead of randomly trying different configurations, you can systematically check each requirement and identify exactly what's missing.

I hope this post saves you from the 2 hours of frustration I went through. If you're working with public APIs and need to send cookies cross-origin, bookmark this checklist—you'll thank yourself later!

From V8 to Event Loop: The Inner Anatomy of Node.js

Parmesh B — Fri, 27 Jun 2025 06:29:14 +0000

What is Node.js?

Many people think that Node.js is a framework, while other new students, who are beginners, understand it as a library. But wait, my friends, Node is neither a framework nor a library.

Node.js is a cross-platform, open-source server environment that can run on Windows, Linux, macOS, and other operating systems. Node.js is a back-end JavaScript runtime environment that utilizes the V8 JavaScript engine to execute JavaScript code outside of a web browser. Node is built using programming languages like C, C++, and JavaScript.

You can explore more about Node.js from their official documentation or Wikipedia.

The V8 Engine — the backbone of Node applications

V8 is a free and open-source JavaScript and WebAssembly engine developed by the Chromium Project for Chromium and Google Chrome web browsers. The project’s creator is Lars Bak. V8 Engine is built using JavaScript, C++, ECMAScript, and Assembly languages.

V8 is the name of the JavaScript engine that powers Google Chrome. It’s the thing that takes our JavaScript and executes it while browsing with Chrome. V8 provides the runtime environment in which JavaScript executes. V8 is written in C++, and it’s continuously improved. It is portable and runs on Mac, Windows, Linux, and several other systems.

You can explore more about the V8 Engine from official documentation or Wikipedia.

Performance Myth — Internal Working of Node.js

Many people are still not able to understand the internal workings of Node.js because its non-blocking and asynchronous execution of programs makes it very complex to understand. Especially the internal working of Node.js, which is the Event Loop.

Now, many people have questioned what asynchronous programming is. So, let’s understand what Synchronous and Asynchronous Programming are.

What is Synchronous and Asynchronous Programming?

Synchronous programming means that the code runs in the sequence it is defined. When a function is called and has returned some value in a synchronous program, only then will the next line be executed.

In simple words, synchronous programming means the execution of a program happens line by line. If one line is taking so much time to execute, then the execution of the program will not go to the next line. It waits for that line to execute, and then it will go to the next line. And if one line takes so much time to execute, then the UI will be frozen.

Asynchronous programming, on the other hand, refers to code that doesn’t execute in sequence. These functions are performed not according to the sequence they are defined inside a program, but only when certain conditions are met.

In simple words, Asynchronous means the environment doesn’t wait for a specific line to execute. It will start executing that line and put it into the background, and when the output of that line comes, it will print it to the console. This way the UI will not be frozen, only that part will be frozen whose going to fetch the data from the actual application server.

- JavaScript code

console.log("Hello world!")

setTimeout(()=>{
    console.log('set timeout function')
}, 2000)

console.log('I am Parmesh Bhatt.')

- Output

Hello world!
I am Parmesh Bhatt.
set timeout function

Now, let’s understand about Event Loop in Node.js.

Event Loop

An event loop is an endless loop that waits for tasks, executes them, and then sleeps until it receives more tasks. Node handles requests using an Event loop inside the NodeJS environment.

Node.js has mainly three parts in the backend: Call Stack, Call Back Queue, and Node APIs. The combination of all three is called an Event Loop.

Let’s have an example and understand it simply:

Suppose we have a code like below,

let a = 2;
let b = 3;
const sum = a + b;
console.log(sum);

- For this, the output will be,

When we write a simple code like the above, the first execution will start, and the main function goes into the Call stack.

**Now you all have a question in JavaScript, we are not writing any main function as we write in C++ and Java. So, where does this main function come in the Call stack?

My friends, JavaScript is internally built. When it starts executing, it will automatically put all of the code in the main function and then start its actual execution.**

After the main function goes into the Call stack, the console.log function goes into the Call stack, and the Call stack executes it, and the output is printed on the screen.

Call Stack has an internal building that follows the LIFO property. LIFO means Last In, First Out. This means whichever function comes last will execute first, and that’s why the main function comes first and gets out of the stack last.

Another example:

console.log('one');

setTimeout(()=>{
    console.log("Settimeout 1")
}, 2000)

setTimeout(()=>{
    console.log("Settimeout 2")
}, 0)

console.log('Two');

- The output of the above code is:

one
Two
Settimeout 2
Settimeout 1

It’s really interesting. Let’s understand it…

We all know now that in NodeJS, there are three things: the Call stack, the second is Node APIs, and the third is the call-back queue.

When we start executing the above code, as usual, the main function goes into the Call stack, and the console.log function will also go into the Call stack.

But from the setTimeout function, the setTimeout function will not go into the Call stack directly, but it goes into the Node API.

Now you all have a question: Why does it go into the node API directly? Why does it not go into the Call stack?

Let’s understand it,

The setTimeout function goes into the Node API directly because the set timeout function is inherited from C++, and every function that inherits from C++ will always go into the Node API directly, and it will not be executed until it goes into the call stack.

There are many more functions like setTimeout in C++. You may explore it on the Internet.

So the setTimeout 1st function goes into the Node API first, and the thesetTimeoutt 2 function goes into the Node API 2nd.

Then the last console.log will go into the call stack, and the call stack will execute it and print the output. Now the output is one and two. After the execution of the last console, every function present in the Call stack will come out of the Call stack, including the main, and the Call stack is now empty.

When the call stack is empty, the functions that are present in the Node API will go into the Callback Queue one by one.

The functions that have a lower priority will go first into the callback queue. When multiple functions are present in the node API, every function will go one by one into the Callback Queue, and then into the Call Stack.

Every function that is present in the Callback Queue will only go into the Call stack when the Call stack is empty. If the Call stack is not empty, the functions will not go into the call stack from the Callback Queue.

After going into the Call stack, the Call stack executes the functions one by one and prints the output on the console. And that’s why the output is like,

one
Two
Settimeout 2
Settimeout 1

This is how the node works internally, and the combination of the call stack, Node API, and the Callback Queue is known as an Event Loop.

Features of Event Loop

An event loop is an endless loop that waits for tasks, executes them, and then sleeps until it receives more tasks.
The event loop executes tasks from the event queue only when the call stack is empty, i.e., there is no ongoing task.
The event loop allows us to use callbacks and promises.
The event loop executes the tasks starting from the oldest first.

Conclusion

The event loop allows Node.js to perform non-blocking I/O operations even though JavaScript is single-threaded.

Since most modern kernels are multi-threaded, they can handle multiple operations executing in the background. When one of these operations completes, the kernel tells Node.js so that the appropriate callback may be added to the poll queue to eventually be executed.

Now you should understand why the two-second time delay function does not block the rest of the program from executing…

So, I end my conversation here, but if anybody wants to connect with me, then the links are below…