What is CORS?

In the past, when internet technologies were still new, cross-site request forgery (CSRF) issues happened. These issues sent fake client requests from the victim's browser to another application.

For example, the victim logged into their bank's application. Then they were tricked into loading an external website on a new browser tab. The external website then used the victim's cookie credentials and relayed data to the bank application while pretending to be the victim. Unauthorized users then had unintended access to the bank application.

To prevent such CSRF issues, all browsers now implement the same-origin policy.

Same-origin policy

Today, browsers enforce that clients can only send requests to a resource with the same origin as the client's URL. The protocol, port, and hostname of the client's URL should all match the server it requests.

For example, consider the origin comparison for the below URLs with the client URL http://store.aws.com/dir/page.html.

URL	Outcome	Reason
http://store.aws.com/dir2/new.html	Same origin	Only the path differs
http://store.aws.com/dir/inner/other.html	Same origin	Only the path differs
https://store.aws.com/page.html	Different origin	Different protocol
http://store.aws.com:81/dir/page.html	Different origin	Different port (http:// is port 80 by default)
http://news.aws.com/dir/page.html	Different origin	Different host

So, the same-origin policy is highly secure but inflexible for genuine use cases.

Cross-origin resource sharing (CORS) is an extension of the same-origin policy. You need it for authorized resource sharing with external third parties. For example, you need CORS when you want to pull data from external APIs that are public or authorized. You also need CORS if you want to allow authorized third-party access to your own server resources.

In HTTP, request methods are the data operations the client wants the server to perform. Common HTTP methods include GET, POST, PUT, and DELETE.

In a regular cross-origin resource sharing (CORS) interaction, the browser sends the request and access control headers at the same time. These are usually GET data requests and are considered low-risk.

However, some HTTP requests are considered complex and require server confirmation before the actual request is sent. The preapproval process is called preflight request.

Complex cross-origin requests

Cross-origin requests are complex if they use any of the following:

• Methods other than GET, POST, or HEAD
• Headers other than Accept-Language, Accept, or Content-Language
• Content-Type headers other than multipart/form-data, application/x-www-form-urlencoded, or text/plain

So, for example, requests to delete or modify existing data are considered complex.

How preflight requests work

Browsers create preflight requests if they are needed. It's an OPTIONS request like the following one.

OPTIONS /data HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: DELETE

The browser sends the preflight request before the actual request message. The server must respond to the preflight request with information about the cross-origin requests the server’s willing to accept from the client URL. The server response headers must include the following:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

An example server response is given below.

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

The preflight response sometimes includes an additional Access-Control-Max-Age header. This metric specifies the duration (in seconds) for the browser to cache preflight results in the browser. Caching allows the browser to send several complex requests between preflight requests. It doesn’t have to send another preflight request until the time specified by max-age elapses.

 

You should note the following when you configure cross-origin resource sharing (CORS) on your server.

Define appropriate access lists

It is always best to grant access to individual domains using comma-separated lists. Avoid using wildcards unless you want to make the API public. Otherwise, using wildcards and regular expressions may create vulnerabilities.

For example, let's say you write a regular expression that grants access to all sites with the suffix permitted-website.com. With one expression, you grant access to api.permitted-website.com and news.permitted-website.com. But you also inadvertently grant access to unauthorized sites that may use domains like maliciouspermitted-website.com.

Avoid using null origin in your list

Some browsers send the value null in the request header for certain scenarios like file requests or requests from the local host.

However, you shouldn’t include the null value in your access list. It also introduces security risks as unauthorized requests containing null headers may get access.