In the past few months, I have been working on migrating microservices hosted in Azure’s CSP to the EA platform. Some of the changes my team has been making to the microservice manifests include standardizing naming, adding resiliency, improving observability, and hardening security by widely using sealed secrets. We use the Istio Service Mesh to provide a network overlay for managing traffic, security, observability, and more for our services. We use Istio to control outbound access to services from our cluster, add detailed tracing and metrics data to our observability stack, and provide routing and TLS customization for a variety of workloads.

One of the changes involved modifying the CORS configuration defined for the Istio virtual service to be deployed to the EA platform. I had not worked on CORS previously and had no clue about what it did. This blogpost is my attempt to share my understanding of CORS or Cross Origin Resource Sharing.

Cross-origin resource sharing (CORS) is a mechanism for integrating applications. CORS defines a way for client web applications that are loaded in one domain to interact with resources in a different domain. In Istio’s virtual service configuration, CORS is configured as follows,

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings-route
spec:
  hosts:
  - ratings.prod.svc.cluster.local
  http:
  - route:
    - destination:
        host: ratings.prod.svc.cluster.local
        subset: v1
    corsPolicy:
      allowOrigins:
      - exact: https://example.com
      allowMethods:
      - POST
      - GET
      allowCredentials: false
      allowHeaders:
      - X-Foo-Bar
      maxAge: "24h"

This configuration restricts cross origin requests to those originating from example.com domain using HTTP POST/GET, and sets the Access-Control-Allow-Credentials header to false. In addition, it only exposes X-Foo-bar header and sets an expiry period of 1 day.

Why do you need CORS? Link to heading

Imagine you’re hosting a party, and you’ve hired a bouncer to guard the door. This bouncer’s job is to ensure only invited guests are allowed in. Now, each guest has a name tag (their origin) that tells the bouncer where they’re coming from—like “Alice from alice.com” or “Bob from bob.com.”

Your party is your web server, and your guests are web browsers trying to access resources (like your website’s data). The bouncer? That’s CORS—Cross-Origin Resource Sharing.

The Problem Without CORS Link to heading

Let’s say your website is hosted at mywebsite.com. Normally, only your own guests (browsers accessing mywebsite.com) should be able to interact with your website.

But what if maliciouswebsite.com sends an uninvited guest to your party? Without the bouncer (CORS), anyone from anywhere could show up and grab all your party snacks (your website’s sensitive data). This is dangerous because:

  1. Sensitive Information Could Leak: Untrusted origins could access private data, like a logged-in user’s details.
  2. Security Risks: Malicious origins might misuse your data or harm your users.

How CORS Fixes This Link to heading

Here’s how the bouncer (CORS) works:

  1. Guest Arrives (Request Made): A browser (like Alice from alice.com) shows up at your party and asks to come in.

  2. The Bouncer Checks the Guest’s Tag: The bouncer looks at the guest’s name tag (the origin) to see if they’re on the guest list (allowed origins).

  3. Decision Time:

    • If Alice from alice.com is on the list, the bouncer says, “Come on in!” and Alice gets access.
    • If Bob from bob.com is on the list, the bouncer says, “Come on in!” and Bob gets access.
    • If Syd from syd.com isn’t on the list, the bouncer blocks him, saying, “Sorry, you’re not allowed.”

CORS Explanation

Why the Bouncer is Necessary? Link to heading

Without this check, anyone could:

  1. Pretend to be from a trusted origin.
  2. Steal your party snacks (data).
  3. Ruin the party for everyone else.

A Real-World Example Link to heading

Let’s say you run an online store (mycoolstore.com) that provides user-specific account details via an API. Without CORS, a malicious site like badactor.com could trick a logged-in user into making a request to your API. Since the user is logged in, your server might unintentionally return their account details to badactor.com!

CORS stops this by checking if the request is actually coming from mycoolstore.com (a trusted origin) before allowing it.

CORS is like a vigilant bouncer that makes sure only invited guests can access your website’s resources. It’s essential for keeping your data safe and ensuring your users have a secure experience. So, the next time you hear about CORS, just remember: It’s your party, and the bouncer (CORS) ensures only the right people get in.