Enabling cross-origin resource sharing in OCI Load Balancer service

We’ve worked with many customers to help migrate their on-premises applications to Oracle Cloud Infrastructure (OCI). These applications often consist of third-party, custom, or internet service provider (ISV) solutions. Sometimes, we’re faced with migrating web applications and web servers to OCI. In almost all these cases, we need to deal with cross-origin resource sharing (CORS).

CORS is a way for web servers to serve resources from a different source in a controlled manner. You can implement it using various solutions, which we cover. This post talks about implementing CORS on OCI load balancers because most of our customers choose this kind of implementation.

What is CORS?

To prevent a web page code from making requests to a different origin than the one it was served from, web browsers typically enforce a same-origin policy. The policy protects against malicious websites, but it can also prevent legitimate interactions between a server and clients of a known and trusted origin.

The CORS standard was introduced to address those issues: CORS allows web pages to consume REST APIs served from a different origin by using other HTTP request and response headers to specify which origins can access the resources.

When a web browser makes a request to a server hosting a cross-origin resource, it first sends a “preflight” request to determine if the requested methods are supported. If the server allows the methods, the browser proceeds with the actual request. The CORS standard also enables servers to indicate whether requests can include credentials, such as cookies, authorization headers, or TLS client certificates.

Available CORS request headers

A CORS simple request is an HTTP request that includes an origin header, which identifies the origin server name. A CORS preflight request checks to see if the CORS protocol is understood. It uses “options” as the method and includes the following headers:

• Access-Control-Request-Method: Indicates which method a future CORS request to the same resource might use

• Access-Control-Request-Headers: Indicates which headers a future CORS request to the same resource might use

Available CORS response headers

An HTTP response to a CORS request can include the following headers:

• Access-Control-Allow-Origin: Indicates whether the response can be shared by returning the literal value of the origin request header

• Access-Control-Allow-Credential: Indicates whether the response can be shared when request’s credentials mode is “include”

Security Considerations

• While "Access-Control-Allow-Origin: *" is an allowed value, it is not recommended since it is a potential vulnerability whenever the response can contain private data, for example.
• The header should not return the full list of allowed sources, but rather the server should check the Origin header in the request and if it is an allowed one, the header should return only the Origin, with the additional header "Vary: Origin" to indicate to browsers that server responses can differ based on the value of the Origin request header.

Use case

You have an application server, s1.domain-a.com, serving the web page, http://s1.domain-a.com/. The first request defines the origin server as s1.domain-a.com. The browser runs a JavaScript, relying on “XMLHttpRequest,” which loads http://s1.domain-a.com/image1.gif. This process is a same origin request and doesn’t require any CORS header.

The JavaScript loads http://s2.domain-b.com/image2.gif, which is a cross-origin request. The browser doesn’t allow this request because of the same-origin policy.

The s2.domain-b.com sends CORS headers in the response, such as “Access-Control-Allow-Origin: s1.domain-a.com”.  The browser permits the request, and the image is shown in the page.

The following diagram depicts the different requests:

If you want to migrate your API server to OCI, you need to configure CORS headers to allow Cross-Origin requests.

You can add CORS headers in the following ways:

• In your application server code

• Configure an Apache server in front of your application server by “Header set Access-Control-Allow-Origin” tags

• Configure an OCI API Gateway

• Configuring headers in OCI Load Balancing

The document demonstrates how to implement the fourth solution by creating an OCI Compute instance with an Apache server as the origin, followed by setting up a load balancer to frontend the Apache service. Both the Compute instance and the load balancer are publicly accessible for testing the response with and without the extra headers.

Origin server setup

The origin server has been prepared in OCI as a simple Apache server. You can find a sample configuration in Create a web server on a Compute instance.

Our example uses the following conditions:

• We have a httpd server listening on port 80.

• The Linux firewall doesn’t block the requests against port 80.

• You have configured the proper security lists and routing tables to allow your client to access the Apache server on port 80.

• Create a sample html page in /var/www/html/index.html, such as the following example:

Configure the load balancer

You can configure a public load balancer by following this tutorial.

When you reach the Add Backends (Servers) to Your Backend Set step, be sure to select the Compute Instance you just created as the origin server and confirm port 80. When creating the Listener for your load balancer, choose port 80 there as well.

Configure CORS headers

After the load balancer has been created, add a new rule set called “CORS,” as described in the documentation. Check the box “Specify Response Header Rules” and add the following header and values:

Create the rule set, edit the listener, and add the rule set to it:

Testing CORS

Resolving on your client hosts file the OCI Compute public IP with Apache as myoriginserver and the load balancer listener public IP as mylbservice, we can verify headers with the curl command. For more details on hosts file editing, see How to edit the hosts file on Windows, Mac, or Linux.

Make a CORS request to the Apache server using the Origin header:

No headers are present in the response. Run the same request against the load balancer:

The load balancer has added the headers. The following code block shows a sample preflight request with the options method:

Conclusion

The presented solution can be useful when exposing your API or web services to different sources using the OCI public or private Load Balancer. CORS is supported on most modern browsers so managing CORS headers is required when web application code needs to access a service in a different domain.

More scenarios are possible, so if you have questions, you can reach out to the authors, Cristiano or Arno. If you want to go hands-on and replay the above scenario yourself, you can get a free trial of Oracle Cloud Infrastructure.