CORS - ashishranjandev/developer-wiki GitHub Wiki

Developer is trying to access the API from his front‑end application, but is getting an error. When he makes a request to the API, he gets an error that access has been blocked by CORS policy. No Access‑Control‑Allow‑Origin headers are present. This issue is happening because the server is not configured to allow requests from origins other than the one that is hosted. When our browser makes the request to the server, it sees that the server hasn't been configured to allow the requests, so it prevents us from accessing the response. If we looked into the Network tab, the request comes through without any errors, but if we try to look into the response, we can't view it.

This is a browser preventing us from accessing that information. This limitation is called same origin policy. It's a rule enforced by browsers which controls access to data between web applications. If a web application isn't configured to allow access to request from origins that we're making there, the browser will not allow us to access the result, or, in some cases, it will not allow us to make the request.

Without same origin policy, any web page would have access to the DOM of other pages. This would let it access potentially sensitive data from other web pages, as well as perform actions on them without user consent.

Let's say you browse a malicious website while at the same time you are logged in on your bank account. Without same origin policy, the malicious website could make authenticated calls using your cookies that were created for your bank site, even though it does not have access to them. This happens because browsers automatically attach any cookies bound to your bank's domain when a call is made to it. If the HTTP calls were restricted to the same origin, then this will not allow calls from other websites and prevent hackers from doing cross‑site request forgeries.

An origin is defined as a combination of a protocol, domain, and port.

HTTP mechanism that utilizes HTTP headers to define origin permissions. Via these CORS headers, the server can inform the browser that it's okay to allow access to some or all origins based on your configuration. The browser will read the CORS headers, and if our origin is part of these allowed origins, it will give us access to the response.

when we have web clients that need to access APIs that are not on the same origin, in these cases we need to loosen the tight grip of same origin policy to allow our web clients access. That's where cross‑origin resource sharing comes into play, or CORS.

• Allow for every one - Add header - Access-Control-Allow-Origin: *
• Allow for our UI - Add header - Access-Control-Allow-Origin: http://localhost:80

Standard cross‑region requests do not send or set any cookies by default. In order for us to include cookies and authentication information as part of the request, we have to specifically specify when we make the request.

To be able to include credentials in a cross site request, three conditions need to be met.

1. First, we have to specify that we want to include the credentials when we make the request
2. the server has to respond with an allow credentials header to let the browser know that it's okay to make a cross site request that includes credentials
3. we cannot use a wildcard for allowed origins. The list of allowed origins has to be specific.

When we are trying to access a resource that is not on the same origin, the browser will determine if we are allowed to access the resource or not. It does so by using headers that are returned from the server that it's trying to call.

The browser classifies each request into one of the following categories:

1. simple
2. preflighted requests.

What is simple request

• It uses the methods Get, Head or Post,
• it has a Content‑Type of urlencoded data, form‑data or plain text
• it's very important that it does not set any custom headers

When the browser deems the request not simple, it does not execute it right away.

1. it makes another request to check the API before making the original request, which is called a preflight request. This preflight request is a request with the method options, which includes as headers the requested method, requested headers of the original method.
2. The server then responds back, specifying the allowed methods, headers, and origins.
3. If our origin method and headers are allowed, the browser makes the original request.
4. Otherwise, it skips it and throws a CORS error indicating which condition was not met.

sequenceDiagram
    participant Client
    participant Browser
    participant Server

    Client->>Browser: Send request with method, headers, etc.
    Browser->>Server: OPTIONS /resource (Preflight Request)<br/> Host: api.home.org,<br/> Origin: www.home.org,<br/> Access-Control-Request-Method:POST,<br/> Access-Control-Request-Headers: Authorization, Content-Type
    Server-->>Browser: Response with allowed methods, headers, etc.<br/> Access-Control-Allow-Origin: www.home.org,<br/> Access-Control-Allow-Methods: POST,GET,OPTIONS<br/> Access-Control-Allow-Headers: Authorisation, Content-Type<br/> Content-Type: application/json
    alt If preflight request is successful
        Browser->>Server: Actual Request (GET/POST, etc.)
        Server-->>Browser: Actual Response
        Browser-->>Client: Response to Client
    else If preflight request fails
        Browser-->>Client: Error Response (CORS error)
    end

Given that most CORS requests first make a preflight request to make things faster, they can be cached. To control the lifetime of the preflight request, we can use the Access‑Control‑Max‑Age header. (Max for Firefox - 24h, Chrome - 10m)