“Cross-origin resource sharing is known by the acronym CORS. When someone is operating on a different domain, the server will use this method to control access to its services. It happens in the middle of a server and a browser. With the help of HTTP Access-Control-Request-* headers, the browser transmits some data. Based on the received headers, the server decides what to send back as Access-Control-Allow-* headers. The browser is now aware of its ability or inability to access server resources. The browser may occasionally perform a pre-flight, which is a validation, before making the actual request. The headers cannot be changed by front-end code in the browser. The headers can be modified by the server-side code. However, it must be performed by a downstream service that the application cannot see, such as an API gateway or the HTTP server.

Cross-origin HTTP queries made by scripts are restricted by browsers for security concerns. The same-origin principle, for instance, is adhered to both the Fetch API and XMLHttpRequest. This implies that a web application utilizing those APIs can only make requests for resources from the origin from which it was loaded unless the response from other sources has the appropriate CORS headers.”

Triggers and Types of Tigger a CORS Request

Since the resources are frequently hosted in the same source as the web application, not all requests result in a CORS request. CORS is activated if it is different. Simple requests and CORS pre-flighted requests are two different forms of CORS requests.

Simple Request Cors

When a user initiates a Simple Request, their web browser transmits the request to the server. The server then examines the source of the request, analyzes it to its rules, and provides the requested resource if it matches. This request type employs the ORIGIN and ACCESS-CONTROL-ALLOW-ORIGIN headers to decide whether the resource should be provided. The only request types that will result in a simple request are GET, HEAD, and POST, as well as the headers like Accept-Language, DPR, Downlink, Save-Data, Content-Type, Content-Language, Viewport-Width, and Width. Even yet, not all content types result in a straightforward request. Here, only certain forms of form encoding cause a straightforward request.

Pre-Flighted Cors

Pre-flighted requests are somewhat different because there isn’t an instant connection to the services in the initial round. A pre-flighted request is initiated when the conditions are changed in some way, for example, by utilizing a modified request header or an alternative content type. In pre-flighted requests, the search engine first confirms that it can access the resource by corresponding with the web browser, and when the web browser responds with an okay (HTTP 200) answer, it then sends another request to acquire the resource. First, it makes a request using the HTTP OPTIONS method, and then it downloads resources using request types similar to methods GET and POST.

Prerequisite of CORS in Nginx

In the first place, 4xx replies are incompatible with Nginx’s standard add header directive. The more set headers directive, which also functions with 4xx replies, may be used to add custom headers to them, but to do so, we must first install the Nginx headers module.

The Nginx-extras package can be readily installed if you use a Debian distribution, notwithstanding the documentation’s recommendation that you build Nginx from source using the module:

Importance of Enabling CORS on Nginx

JavaScript executing on the client’s browser typically doesn’t need to access services outside of its domain. As a result, turning off CORS may be a wise security precaution.

However, for such functionality to function on the backend, CORS must be enabled. This is because legitimate JavaScript code may occasionally need to pass a request to a server beyond its domain. A separate protocol, domain name, or port might all be referred to as the same domain.

How to Enable CORS on Nginx in Ubuntu 20.04

Let’s go on to the main portion. Open the preferred editor, vim, then navigate to the Nginx configuration:

Enter the next entry in your Nginx configuration’s server block.

Restart Nginx after that, and then save the configuration file.

CORS can be enabled by using the CURL command to verify. The following output should result from this:

How to Deal With the CORS Errors in a Severs

The server side is where CORS is implemented; the client side cannot change how it works. Users can be prevented from using shared resources by using the CORS behavior, often known as the CORS error. This is not an error but rather a security mechanism to protect you or the website you are visiting from a potential breach of security. The client-side implementation of HTTP headers that are inadequate or incorrect may result in this issue (e.g., missing API keys and other authorization information). We have some unique solutions to these errors.

• Cross-origin requests can be made with the aid of a CORS proxy. Your request is forwarded through the proxy layer, which is blind to its origin. Consequently, even though the request originates from an unidentified origin, the CORS proxy renders it as though it is coming from a permitted location.
• The usage of a serverless function is a more popular remedy. It’s a different approach to proxying your requests, but despite the approach described above, you can create your micro-infrastructure to access a web service and transmit data to an API endpoint.

Conclusion

CORS’ main objective is to make online applications more secure to hinder man-in-the-middle attacks. CORS can yet be advantageous as well. Since it is not enabled by default, CORS must be enabled in that situation. With the use of the ORIGIN and ACCESS-CONTROL-ALLOW-ORIGIN directives, which are the sole request types used by the basic CORS request type, Nginx can provide the web browser permission to access the requested resource based on the origin. CORS is a great tool that should be utilized carefully in either case.