Understanding CORS: How Websites and APIs Safely Connect

Photo by Ferenc Almasi on Unsplash

Introduction:
In the world of the internet, websites often need to talk to each other to share information or access data from APIs. However, for security reasons, there are rules in place called CORS (Cross-Origin Resource Sharing) that regulate this communication. In this article, we’ll explore what CORS is, why it matters, how developers can ensure smooth communication between websites and APIs, and how CORS configuration is done on the server side.

Understanding CORS:
Imagine you’re in a big city with different neighborhoods. Each neighborhood represents a Website or Domain or Server, and there are “gatekeepers” between them. These gatekeepers are like CORS. They check if it’s okay for one website to access resources from another.

The CORS Story:
Let’s say you’re Ram, and you live in the Web District. You want to get some cool stuff from the API District, which is across the river called CORS River. But before you can cross the river, you have to ask permission. This is like sending a message (Preflight API call) to the API District’s guards (server) to see if they’ll let you in.

Preflight API Calls:
Before any API call to the server, the browser firstly send a preflight request to the server, and the server check your request (Preflight API call) to see if you’re allowed to enter. They send back a response with CORS headers, which are like permission slips. If they say it’s okay, you can access the server or API and get what you need from the API.

CORS Configuration on the Server Side:
When configuring CORS on the server side, developers need to specify which origins, methods, headers, and credentials are allowed. Here’s an example of CORS configuration for the API District’s server:

// Server Response Headers at https://api.exampleapi.com

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true

In this configuration:
Access-Control-Allow-Origin: Specifies that requests from https://example.com are allowed to access resources on the API server.

• Access-Control-Allow-Methods: Indicates that the server allows HTTP methods such as POST, GET, and OPTIONS.
• Access-Control-Allow-Headers: Lists the HTTP headers that are allowed in requests, in this case, only Content-Type.
• Access-Control-Allow-Credentials: Specifies whether the browser should include credentials (like cookies) in the request. Setting this to true indicates that credentials are allowed.

Postman Testing:
Postman is a standalone API client that operates outside the restrictions imposed by web browsers. It does not enforce CORS policies, allowing you to make requests to any server without considering the cors-origin policy.

Browser Enforcement:
Web browsers enforce CORS policies strictly to prevent unauthorized access to sensitive resources. If a website doesn’t have permission (CORS headers), the browser won’t let it access resources from another site.

Overview:
CORS error mostly happen in browser when one domain try to access resources of another domain .Browser sends a preflight API call to the server or another domain if server sends back response with permission to access its resources then browser will allow to send API request to that server otherwise browser will block the request.

Thanks for reading ❤️