Breaking the CORS Puzzle: What Every Developer Must Know for Interviews

Let’s talk about something that every web developer encounters — CORS Policy. I recently faced some interview, in which medium-level questions were asked on CORS (Cross-Origin Resource Sharing),and they’re exactly what you’ll want to know if you’re preparing for an interview. Here’s what I was asked and the answers I gave, plus a few tips to deepen your understanding.

1. What is CORS? And What Does It Stand For?
CORS stands for Cross-Origin Resource Sharing. It’s a security feature in browsers that controls how resources can be shared between different origins. In simpler terms, it allows web servers to grant permission for external sources (like websites or applications) to access their resources.

How CORS Works:
CORS revolves around three elements in an array: [protocol, URL, port]. Imagine you have a server running at https://localhost:3000—this server uses HTTPS, the localhost URL, and port 3000. If a client tries to access this server from a different URL, protocol, or port, the browser’s Same-Origin Policy (SOP) will block it. This is where CORS steps in, giving servers a way to share with specific external origins while maintaining security.

2. How Did You Implement CORS in Your Project?
In the project I was interviewed for, I used Node.js. CORS comes up a lot when building APIs for client-server communication, and here’s the Node.js code I used:

const cors = require("cors"); // Import CORS middleware

app.use(
  cors({
    origin: "http://localhost:3000", // Only allow requests from this origin
    methods: ["GET", "POST"], // Restrict allowed HTTP methods
    credentials: true, // Enable cookies and authentication headers across origins
  })
);

This configuration lets the server accept requests only from http://localhost:3000 and only for GET and POST methods. Enabling credentials: true is key here—it allows cookies and auth headers to be shared, which is essential for sessions that require login or token-based authentication.

3. Why Use Middleware? Isn’t It Just Adding Complexity?
One question that came up was Why even use middleware for CORS? If you can connect the server and client directly, isn’t middleware just causing a delay?

Here’s the scoop: Middleware is actually a way to handle common tasks (like CORS) in a streamlined, reusable way, making it possible to set rules at a global level instead of repeatedly applying them throughout the code. This saves time and minimizes errors, especially in complex applications where different endpoints may have different access rules. While there’s a slight delay, the trade-off for security, scalability, and simplicity is worth it.

4. What’s the Difference Between a Simple Request and a Preflight Request?
This one’s a little trickier but essential to understand.

A simple request is when a browser can directly send a request to a server without checking permissions in advance. This usually applies to GET and POST requests without custom headers, making it faster and easier for clients.

A preflight request comes in when a request goes beyond the scope of a “simple request.” If a client wants to use an HTTP method that isn’t GET or POST (like PUT or DELETE) or add custom headers (such as Authorization or Content-Type: application/json), the browser needs to double-check that this is allowed. To do this, it sends an _OPTIONS _(very important) request to the server before making the actual request.

Think of this OPTIONS request as a “permission letter.” The browser is essentially asking the server, “Hey, can I send this request with these specific methods or headers?” The server then responds with which methods, headers, and origins it’s willing to accept. If the server gives the green light, the browser proceeds with the real request. If not, the browser blocks it, keeping everything secure.

Preflight requests add a layer of security by ensuring that non-standard requests aren’t just blindly sent to the server, giving servers control over exactly what gets through and how.

END…..

After covering CORS basics, the interview dove into **system design **questions. These tend to dig deeper into how you’d structure an application or design a scalable backend with multiple clients in mind.

Curious for more on this? Let me know in the comments if you’d like insights on the system design questions — they can really add value to your preparation!