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

By: John Detlefs
Posted: April 01, 2020

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.

Of CORS My Request Failed

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:

Before you get really started

Creating the certs and templates

Add your Dockerfile in your root directory

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

Adding some build scripts

Adding your nginx config

Add your docker-compose file


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!

Getting it all started

  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

Meshify's scheme for interacting with a third party service

An image from Notion

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!