CORS is not your nightmare! But …

The problem ( not really a problem, but this is the scenario)

If you are using Angular or jQuery or maybe an XHR request, so you are saying to a specific server “Hey server, this is a POST/GET request and these are my PARAMS would you answer me ?” But unfortunately your web browser returns something like this in the console “Hey, you can’t do that because” :

No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access.

In that moment you will say ! “Oh no! But why ?? WHY !!” you did everything right all your params and headers are set but you still have the same problem. You google it and you find some solutions or some workarounds to deal with it. But what is CORS ?

First of all you need to know…

What is a security policy ?

In business, a security policy is a document that states in writing how a company plans to protect the company’s physical and information technology (IT) assets. A security policy is often considered to be a “living document”, meaning that the document is never finished, but is continuously updated as technology and employee requirements change.

Servers use security policy to know how to deal with accessing ressources in the same server or between servers. Security policies on servers mitigate the risks associated with requesting assets hosted on different server.

What is CORS ?

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.

An example of a cross-origin request: A HTML page served from http://domain-a.com makes an <img> src request for http://domain-b.com/image.jpg. Many pages on the web today load resources like CSS stylesheets, images, and scripts from separate domains, such as content delivery networks (CDNs).

Why your requests works on some apps like POSTMAN and not on your browser?

POSTMAN is a dev tool, its not a browser.

What’s the benefits of using CORS ?

The CORS standard is needed because it allows servers to specify not just who can access its assets, but also how the assets can be accessed.

Cross-origin requests are made using the standard HTTP request methods. Most servers will allow GET requests, meaning they will allow resources from external origins (say, a web page) to read their assets. HTTP requests methods like PATCH, PUT, or DELETE, however, may be denied to prevent malicious behavior. For many servers, this is intentional. For example, it is likely that server A does not want servers B, C, or D to edit or delete its assets.

With CORS, a server can specify who can access its assets and which HTTP request methods are allowed from external resources.

What is the solution ?

The simplest solution is to tell the server “Obey and serve the requests from these origins!” 😆

On APACHE :

Access-Control-Allow-Origin: http://www.example.com

Access Control Allow Origin with a wildcard that allows all domains:

Access-Control-Allow-Origin: *

BUT BEWARE

A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site. For example, a freely-available web font on a public hosting service like Google Fonts.

Is there some workaround or some quick solution for development mode ?

Yes BUT not recommended, use on your own risk.

• We could spoof (fake) the “Origin” header when making our request — something like this:

xhr.setRequestHeader("Origin", 'www.exemple.com');

• Use a browser extension on chrome or firefox.
• Disable security on the browser :

On chrome or chromium

Note : Kill all chrome instances before running command

chromium-browser --disable-web-security --user-data-dir

The browser will warn you that "you are using an unsupported command line" when it first opens, which you can ignore.

• You can set a proxy!

On angular2+ you can change the requests to “/api” for exemple and create a proxy that redirect “/api/*” to the specific URL.

To set it up, we need to create a file proxy.conf.json at the root of our Angular CLI project. The content should look as follows

{
"/api/*": {
"target": "http://localhost:3000",
"secure": false,
"logLevel": "debug",
"changeOrigin": true
}
}

or you can use a plugin, like this one:

Rob--W/cors-anywhere

Conclusion

I hope you have learned something on the CORS, it’s a great thing to read about for further informations, these are many other restrictions that you can use to create your own security policy depending on your needs.

Front-end developers, can use some workarounds for development purposes.