CORS and SameSite Cookies Got You Down? An Effective Workaround for Browser Security Policies

Like many of my colleagues I haven't ever felt like I really understood what Cross Origin Resource Sharing (CORS) policies accomplish. I feel like when I try to learn more about it, I understand it even less.

CORS security policies are like the worlds worst child safety lock. Whenever I have looked at information behind it, the explanations are usually very good at explaining what the moving parts are, but rarely give a good explanation for why CORS policies exist. For more background look at these CORS explanations: MDN, Codecademy, Port Swigger, Auth0

There is so much content to look at, but really for most developers this stuff should be abstracted so you don't have to think about it. I doubt very many of us could give a comprehensive breakdown of what a browser request lifecycle looks like. Really though, you can get a long way without deeply understanding this.

As far as I understand it, CORS security defaults on the browser default to the most restrictive rules, any outbound request from content on a domain that isn't making a request to that same domain will be blocked. This is a good thing. Content in the DOM is inherently mutable, so its possible that bad things could happen after your browser renders your HTML/CSS/Javascript.

Your browser is essentially telling you "Hey, if you want to make this request you better put in the work of lying about where its coming from on your server. Get out of here with your funny business!" Servers responding to requests could do work to maintain whitelists for multiple domains, but whitelists are hard to secure and backend developers are justifiably hesitant to make changes to stuff like that.

At Meshify, we've put a fair amount of resources into using Dockerized NGINX servers in tandem with Create-React-App for most of our applications. As a result of this work we've done we are able to:

• Share Cookies from authenticated requests between pods in our Kubernetes infrastructure
• Develop against a local service that will work with our API with parity against production behavior
• Develop against secure WebSockets locally
• Develop against Service Workers locally
• Maintain legacy apps to keep them working with stricter security standards

• You'll need a config that builds to a directory, in our case its called "build", and our build script is "yarn build"
• Install Docker
• Install Homebrew
• After installing homebrew, brew install mkcert

• mkdir templates in your project's root directory
• mkdir templates/localcerts
• mkdir templates/nginx

IMPORTANT: That last line build is whatever the name of your build directory is, copy paste errors can trip you up!

Throughout these examples youll see text like <YOUR_BACKEND_SERVER_URL_WITH_API>. I'm expecting you to substitute these with your own endpoints and text. Trailing slashes can be important. If you're running your app and getting 404's, its possible your API slashes are mismatched with your NGINX config. Be careful!

1. Run yarn mkcert in your root directory
2. Run yarn build:docker
3. Run yarn start:docker
4. In a separate window, run docker-compose up
5. Go to https://localhost:3006 click through the security warnings about self signed certs

In our case, we forward requests matching the string 'periscope' to a standalone service that we made to handle some business logic. The standalone service could also be lambdas or some other endpoint that we own. In this instance we get to use the cookie from an authenticated user in that standalone service to make another request to the API to ensure that user has permissions to read what they are accessing.

My brilliant coworker Danil did most of the heavy lifting getting this setup working smoothly with NGINX. Kubernetes works especially well with this setup, COMMAND and ENVIRONMENT exists in Kubernetes configuration the same way it does here, so there are few changes necessary.

I encourage you to comment here if you have any trouble getting this running and wish you luck in breaking out of the cage that your browser puts you in!