What is CORS
CORS, also known as cross origin resource sharing is a technique used in modern web browsers that controls access to resources hosted in a web server. CORS uses additional headers such as origin, access-control-origin, and many more to determine whether the requested resource has permission to be sent to the browser. The primary purpose of CORS is to prevent a web application running in a web browser from accessing resources hosted in a different origin when there is no permission, what it means the web application can’t download resources, such as images, scripts, css like any content etc. when they are not hosted in the same origin (usually all should be in the same domain) as the web application unless the server is configured to allow this behaviour. By having this implementation in a web browser, users can protect their data from unauthorized parties. A hacker can secretly modify a web page while being middle of the connection to disrupt business of the user or gain access to valuable data. However, there are advantages of CORS too, such as it allows developers to load resources from a different origin due to cost effectiveness, or simply convenience. In that case they have to modify their web server to allow such requests. This article demonstrates how to get it done on a Nginx web server with ease.
What Triggers a CORS Request
Not all the requests trigger a CORS request as usually the resources are hosted in the same origin as the web application. If it’s different, then CORS is triggered. CORS has two types of requests, simple request and CORS pre-flighted request.
Simple Request works as a regular request, the web browser sends a request to the server to download a particular resource when the user initiated it, then web server checks the origin of the request, compares it against the rules in the web server, if it’s matched, the resource is supplied. This request type uses OIRIGN, and ACCESS-CONTROL-ALLOW-ORIGIN headers to determine whether the resource should be supplied or not. Simple request is only triggered if request methods like GET, HEAD, POST are used, and headers like Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width are used. Even then, not all the content types trigger a simple request. Here only form encoding types trigger a simple request.
Pre-flighted request type is rather different as there is no direct access to the resources in the first round. When the aforesaid conditions are altered somehow, either by using a different request header or a different content type, a Pre-flighted request is triggered. In Pre-flighted requests, the web browser first make sure it can access to the resource by communicating with the web browser, then when the web browser replied with okay (HTTP 200) response, then it sends another request to download the resource. It utilizes HTTP OPTION request method to initiate the first request, then it uses GET, POST like request types to download the resources.
How to Configure Nginx to Support CORS Requests
This section demonstrates how to configure a nginx web server to allow cross origin resource sharing. This can only be done if the developer has access to the web server, as it involves modifying the configuration file of Nginx.
Use the following simple code snippet to allow CORS requests. This has to be copied to the default file of nginx service in Ubuntu or any other platform.
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://localhost;
add_header 'Access-Control-Allow-Methods' 'POST, OPTIONS';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
return 204;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' 'https://localhost;
add_header 'Access-Control-Allow-Methods' 'POST';
}
}
The basic code snippet goes as above. It contains directives like request_method, add_header to identify the request type, and set the header of the response for browser to read respectively. The Access-control-allow-origin header defines what origin the resource has access to, for instance if a web application hosted in github wants to access an image hosted in myOwnServer.com, then the URL of github should be used as the value of Access-control-allow-origin directive in myOwnServer.com, then whenever the web application hosted in github sends requests to myOwnServer.com to download the image file, all these requested are granted permission. Access-control-allow-method header defines what request types the web application that sends the requests supports, then rest of the headers are for its max age to cache the requests, and the supported content type.
As described above, once the OPTION request was completed, the browser sends another request to download the resources if the first request was successful, its headers are set in the first request_method if brackets.
Other than the aforesaid directives, there are some other important directives in Nginx that can be used in CORS requests. One of the most important directives is access-control-allow-headers, what it does is to set the response header with allowed header names for browser to verify. A web application can have its own headers for various purposes, and if such headers present in the subsequent requests after the initial OPTIONS request, then all these headers should be allowed by the web server before the requested resource to be shared.
It’s important that this code snippet to be in the right place in Nginx default file, because Nginx executes different location blocks depending on the matched URL, if such location block doesn’t contain this code snippet, then it isn’t executed at all, and therefore it’s important to use this in all the location blocks for the safe side. Some of the important location blocks are Images, PHP (~ \.php$), CSS, etc.. blocks.
Once the aforesaid code snippet is saved, save the Nginx file, and reload the Nginx service to changes to take effect.
Conclusion
CORS, is known as cross origin resource sharing, and is a technique to control the access of resources. These resources can be any file from image to a javascript file. The primary purpose of CORS is to tighten the security of web applications to prevent man in the middle attacks. However, CORS can have benefits too. In that case, the CORS has to be turned on as it’s not allowed by default. The basic CORS request type is simple request type, it uses only ORIGIN, and ACCESS-CONTROL-ALLOW-ORIGIN directives, and with that help the Nginx can grant permission for the web browser to access the requested resource depending on the origin. Either way CORS is quite useful and should be used carefully.
from Linux Hint https://ift.tt/3fGLrgI
0 Comments