No ‘Access-Control-Allow-Origin’ header is present on the requested resource Error, while Postman does not?

When a client from one domain tries to send a request for a resource hosted in another domain, the “Access-Control-Allow-Origin header is not present on the requested resource” error is frequently seen. This happens due to the “Same-Origin Policy” which is a web browser security feature that stops malicious scripts from unauthorized accessing resources on other domains.

Postman, on the other hand, is an API testing tool that functions differently from a web browser and does not adhere to the Same Origin Policy as the browsers. Therefore, you won’t encounter this error when sending requests to resources located in different domains.

Approaches: The problem addressed above could be solved using two approaches as mentioned,

• Either we can configure the webserver to allow requests from the origins we want. This is a simple solution that is commonly used to deal with the issue.
• We can also use a proxy server that will make requests from the same origin as the browser. This solution is complex as compared to the above one but it is an ideal approach if you do not want to configure the webserver to allow requests from other origins.

Approach 1: To demonstrate approach 1 which involves setting each origin, we want to allow access to the resources, Here is an example NodeJS App using Cors middleware to enable selective cross-origin requests:

Javascript

// Node app to demonstrate the use of cors module

// Importing modules
const express = require("express");
const cors = require("cors");

// Creating express object
const app = express();

// Using cors middleware to allow all origins
app.use(cors());

// Creating get route
app.get("/", (req, res) => {
    res.send("Hello World");
});

// Listening to port
app.listen(3000, () => {
    console.log("Server started at port 3000");
});

Now that server is created let us make a request to it,

As you can see I am able to access the route as I have used the wildcard or `*` approach for cors but in real-world we avoid such practices instead in specify each origin to the web server as follow,

// Modified the same code above
// Using cors middleware to allow example.com 
// and example.net to access the resources
app.use(
      cors({
        origin: ["http://example.com", "http://example.net"],
      })
);

The cors definition above will allow resource access to the request form `example.com` and `example.net`

Approach 2: In approach 2 we will be using a proxy as a middle between the client and resource server, once any client makes a request for a resource, for example, an image from xyz.com the proxy running on the same server will forward the request to the running service using the origin of the server itself, not the client and this way it will overcome the CORS issue. 

Example: Following is the demonstration of this approach,

Javascript

// Node app to demonstrate the proxy
// server approach to CORS issues

// Load the express package and create our app
let express = require("express");

// Importing createProxyMiddleware from
// http-proxy-middleware
const { createProxyMiddleware }
    = require("http-proxy-middleware");

let app = express();

// creating a proxy middleware
// function for the path /api
const apiProxy = createProxyMiddleware("/api", {
    target: "http://example.com",
    changeOrigin: true,
});

// Telling the app to use the proxy
// middleware for the path /api
app.use("/api", apiProxy);

// Start the server
app.listen(3000, () => {
    console.log("Server running on port 3000");
});

Output:

Once you make the request to /api route it will redirect you to the specified URL `example.com` in this case.

By routing requests to the proxy middleware, the browser makes the request from the same origin as the server, avoiding the cross-origin issue.

Note: Note that adding the Access-Control-Allow-Origin header to a resource’s HTTP response should be done carefully with security implications in mind. Allowing access from any domain (using the ‘*’ wildcard) can make your resource vulnerable to cross-site scripting (XSS) attacks which could make an entire system vulnerable to malicious attacks and can lead to catastrophic effects.