Understanding 𝗖𝗢𝗥𝗦-𝗖𝗿𝗼𝘀𝘀-𝗢𝗿𝗶𝗴𝗶𝗻 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗦𝗵𝗮𝗿𝗶𝗻𝗴

Understanding 𝗖𝗢𝗥𝗦-𝗖𝗿𝗼𝘀𝘀-𝗢𝗿𝗶𝗴𝗶𝗻 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗦𝗵𝗮𝗿𝗶𝗻𝗴

Overview: 𝗖𝗢𝗥𝗦-𝗖𝗿𝗼𝘀𝘀-𝗢𝗿𝗶𝗴𝗶𝗻 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗦𝗵𝗮𝗿𝗶𝗻𝗴 is an HTTP-header-based method that allows a server to specify any origins (domain, scheme, or port) other than its own from which a browser should allow resources to be loaded. CORS additionally makes use of a technique that allows browsers to send a “preflight” request to the server hosting the cross-origin resource to ensure that the server will allow the real request. The browser transmits headers indicating the HTTP method and headers that will be used in the real request during that preflight.

As an Application developer, We need know What is CORS and how it works 🔥

Here’s a high level flow on how browsers initiate that extra “preflight” request to determine whether they have permission to perform cross origin requests.

What is CORS ? CORS stands for Cross Origin Resource Sharing, and it’s a protocol that allows servers to receive requests from different domains.

Developers often make external API requests to fetch data form external servers. Sometimes these servers could be from different domains too.

Example:
👉 User app in domain[.]com making a GET request to domain[.]com is a same origin request
👉 User app in domain[.]com making a GET request to google[.]com is a cross origin request

But these cross domain requests are restricted by the browser ❌.

We get CORS errors like below:

Once developers have configured CORS on the server to accepts requests from other domains the browser will kick in a preflight check ✅

It is to verify whether resource sharing is allowed on the destination server. The preflight request uses the HTTP method OPTIONS.

So lets take a look in more details here . Browsers use CORS, a method, to prevent websites from requesting data from different URLs.
A request from a browser includes an origin header in the request message. The browser allows it if it gets to the server of the exact origin; if not, the browser blocks it.

We can deal with CORS issues on the backend.
Cross-origin requests require that the values for origin and 𝗔𝗰𝗰𝗲𝘀𝘀-𝗖𝗼𝗻𝘁𝗿𝗼𝗹-𝗔𝗹𝗹𝗼𝘄-𝗢𝗿𝗶𝗴𝗶𝗻 in the response headers match and it is set by the server.
When you add an origin to the backend code, the CORS middleware only permits this URL to communicate
with other origins and utilize it for cross-origin resource requests.

There are two ways to fix CORS issues:

𝟭. 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗲 𝘁𝗵𝗲 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝘁𝗼 𝗔𝗹𝗹𝗼𝘄 𝗖𝗢𝗥𝗦

Server can let all domains with 𝗔𝗰𝗰𝗲𝘀𝘀-𝗖𝗼𝗻𝘁𝗿𝗼𝗹-𝗔𝗹𝗹𝗼𝘄-𝗢𝗿𝗶𝗴𝗶𝗻: *.
This actually turns off same-origin policy, which is not recommended.
Another option would be only to allow particular domain, which is better option, e.g., 𝗔𝗰𝗰𝗲𝘀𝘀-𝗖𝗼𝗻𝘁𝗿𝗼𝗹-𝗔𝗹𝗹𝗼𝘄-𝗢𝗿𝗶𝗴𝗶𝗻: 𝗵𝘁𝘁𝗽𝘀://𝗱𝗼𝗺𝗮𝗶𝗻2.𝗰𝗼𝗺.

𝟮. 𝗨𝘀𝗲 𝗮 𝗣𝗿𝗼𝘅𝘆 𝗦𝗲𝗿𝘃𝗲𝗿

We can use a proxy server to call external API.
It acts as a middleware between client and the server. If server doesn’t return proper headers defined by CORS, we can add then in the proxy.

Once Fix is done. Below, you’ll see an example of the headers sent back by the server (yes, by server — therefore CORS is not something you can fix in the UI code) with a reply to OPTIONS. Look at those Access-Control-* headers and focus on Access-Control-Allow-Origin:

Here’s what’s happening: before sending your requested API call, your browser does a ‘security check’ by asking the API, (via an OPTIONS call, who is allowed to do what. Simple as that.

An ‘issue with CORS’ occurs when the API does not reply to such request with, ‘Yes, dear browser, you are allowed to do that call’. So, as you can see on the screenshot above, my API responded that my UI, localhost, is allowed to handle OPTIONS, HEAD, DELETE, POST and GET calls.

Now that’s the core of all the ‘problems’ with CORS. In order to fix CORS, you need to make sure that the API is sending proper headers (Access-Control-Allow-*). That’s why it’s not something you can fix in the UI, and that’s why it only causes an issue in the browser and not via curl: because it’s the browser that checks and eventually blocks the calls.

How do I fix a CORS error in Java Spring boot?
Enable CORS in Controller Method We need to set the origins for RESTful web service by using @CrossOrigin annotation for the controller method. This @CrossOrigin annotation supports specific REST API, and not for the entire application.

In the simplest scenario, cross-origin communications starts with a client making a GET, POST, or HEAD request against a resource on the server.
In this scenario, the content type of a POST request is limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain.
The request includes an Origin header that indicates the origin of the client code.

The server will consider the request’s Origin and either allow or disallow the request.
If the server allows the request, then it will respond with the requested resource and an Access-Control-Allow-Origin header in the response.
This header will indicate to the client which client origins will be allowed to access the resource. Assuming that the Access-Control-Allow-Origin header matches the request’s Origin, the browser will allow the request.

On the other hand, if Access-Control-Allow-Origin is missing in the response or if it doesn’t match the request’s Origin, the browser will disallow the request.

Two simple ways discussed below to handle this Access-Control-Allow-Origin (CORS) issue -

1. Put @CrossOrigin annotation on top of Controller to allow CORS as shown below-

   @CrossOrigin(origins= {"*"}, maxAge = 4800, allowCredentials = "false" )
   @RestController
   @RequestMapping("/")
   public class CorsOk {
   /* put your code here */
     
     }

1. A simple ways is to create a simple CORS filter to allow every type pf CORS, this can be done as shown below.

//Samplecode - for full code download the file AppCORSFilter
   @Override
       public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
        response.setHeader("Access-Control-Allow-Credentials", "true");
        response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Max-Age", "3600");
        response.setHeader("Access-Control-Allow-Headers", "Content-Type, Accept, X-Requested-With, remember-me");

        chain.doFilter(req, res);
    }

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

@Component
public class AppCORSFilter implements Filter {

private final Logger log = LoggerFactory.getLogger(SimpleCORSFilter.class);

public AppCORSFilter() {
    log.info("SimpleCORSFilter init");
}

@Override
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;

    response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
    response.setHeader("Access-Control-Allow-Credentials", "true");
    response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
    response.setHeader("Access-Control-Max-Age", "3600");
    response.setHeader("Access-Control-Allow-Headers", "Content-Type, Accept, X-Requested-With, remember-me");

    chain.doFilter(req, res);
}

@Override
public void init(FilterConfig filterConfig) {
}

@Override
public void destroy() {
}

}

AWS S3 also allows configuring CORS for content hosted on S3.

Regarding preflight request, if you open your browser in developer mode you will see two requests for the same resource,
the first is preflight request and if the server allow this origin, then second request will be send to consume the resource .

Using cross-origin resource sharing (CORS)

Cross-origin resource sharing (CORS) defines a way for client web applications that are loaded in one domain to interact with resources in a different domain. With CORS support, you can build rich client-side web applications with Amazon S3 and selectively allow cross-origin access to your Amazon S3 resources.

This section provides an overview of CORS. The subtopics describe how you can enable CORS using the Amazon S3 console, or programmatically by using the Amazon S3 REST API and the AWS SDKs.

Cross-origin resource sharing: Use-case scenarios
The following are example scenarios for using CORS.

Scenario 1

Suppose that you are hosting a website in an Amazon S3 bucket named website as described in Hosting a static website using Amazon S3. Your users load the website endpoint:

http://website.s3-website.us-east-1.amazonaws.com
Now you want to use JavaScript on the webpages that are stored in this bucket to be able to make authenticated GET and PUT requests against the same bucket by using the Amazon S3 API endpoint for the bucket, website.s3.us-east-1.amazonaws.com. A browser would normally block JavaScript from allowing those requests, but with CORS you can configure your bucket to explicitly enable cross-origin requests from website.s3-website.us-east-1.amazonaws.com.

Scenario 2

Suppose that you want to host a web font from your S3 bucket. Again, browsers require a CORS check (also called a preflight check) for loading web fonts. You would configure the bucket that is hosting the web font to allow any origin to make these requests.

How does Amazon S3 evaluate the CORS configuration on a bucket?
When Amazon S3 receives a preflight request from a browser, it evaluates the CORS configuration for the bucket and uses the first CORSRule rule that matches the incoming browser request to enable a cross-origin request. For a rule to match, the following conditions must be met:

The request’s Origin header must match an AllowedOrigin element.

The request method (for example, GET or PUT) or the Access-Control-Request-Method header in case of a preflight OPTIONS request must be one of the AllowedMethod elements.

Every header listed in the request’s Access-Control-Request-Headers header on the preflight request must match an AllowedHeader element.

Browser support
CORS is supported by all browsers based on the following layout engines:

1. Blink- and Chromium-based browsers (Chrome 28+,Opera 15+, Amazon Silk, Android’s 4.4+ WebView and Qt’s WebEngine)
2. Gecko 1.9.1 (Firefox 3.5 SeaMonkey 2.0) and above.
3. MSHTML/Trident 6.0 (Internet Explorer 10) has native support.
4. MSHTML/Trident 4.0 & 5.0 (Internet Explorer 8 & 9) provide partial support via the XDomainRequest object.
5. Presto-based browsers (Opera) implement CORS as of Opera 12.00[14] and Opera Mobile 12, but not Opera Mini.
6. WebKit (Initial revision uncertain, Safari 4 and above, Google Chrome 3 and above, possibly earlier).
7. Microsoft Edge All versions.

History
Cross-origin support was originally proposed by Matt Oshry, Brad Porter, and Michael Bodell of Tellme Networks in March 2004 for inclusion in VoiceXML 2 to allow safe cross-origin data requests by VoiceXML browsers. The mechanism was deemed general in nature and not specific to VoiceXML and was subsequently separated into an implementation .
The WebApps Working Group of the W3C with participation from the major browser vendors began to formalize the NOTE into a W3C Working Draft on track toward formal W3C Recommendation status.

In May 2006 the first W3C Working Draft was submitted.[20] In March 2009 the draft was renamed to “Cross-Origin Resource Sharing”[21] and in January 2014 it was accepted as a W3C Recommendation.

CORS vs JSONP
CORS can be used as a modern alternative to the JSONP pattern. The benefits of CORS are:

While JSONP supports only the GET request method, CORS also supports other types of HTTP requests.
CORS enables a web programmer to use regular XMLHttpRequest, which supports better error handling than JSONP.
While JSONP can cause cross-site scripting (XSS) issues when the external site is compromised, CORS allows websites to manually parse responses to increase security.
The main advantage of JSONP was its ability to work on legacy browsers which predate CORS support (Opera Mini and Internet Explorer 9 and earlier).
CORS is now supported by most modern web browsers.

Hope this post on CORS was helpful.

Happy Coding …….

Other Interesting Articles :

Many ways to learn GCP for Free with Google Cloud over the holidays

Linux Commands for Cloud Learning