cookies and milk

Why Cookie Sharing?

Saaslet manages user signups and logins, account actions like password or address changes and payments - all activities that are closely linked to an authenticated user.

To authenticate that user between page loads, we use cookies: small bits of data stored in the user's browser. So far, so common - pretty much every web app works this way.

But there's a catch: Whenever a user of your SaaS makes a request to your server, you need to receive that cookie to know who you're dealing with. But that user's cookie was set by - and browsers only sent cookies back to the domain that set them.

To get around this limitation, we ask you to allow us to set cookies for your domain. This can either be done by adding a CNAME entry into your zone file or DNS configuration or by creating a proxy-forward rule for your HTTP server. We realize that this is a bit of extra work - and we're really sorry about that. There would have been simpler solutions, but all of them come with some major security caveats.

Here's what we could have done instead:

cookies small

Third-Party Cookies

Many sites set cookies from multiple sources: Google Analytics, Ad Providers, Tracking Cookies, etc. These are called third party cookies and provide a simple way for multiple providers to keep state. But there are problems: Many people use AdBlockers - and most AdBlockers also block third party cookies. Furthermore, the legal situation for third party cookies in the European Union has made exact compliance a rather convoluted affair


You're probably familiar with the "Sign up with Google/Twitter/Facebook etc." buttons on the web. They work based on an authorization workflow called oAuth 2, which is specifically designed to make authentication via third party providers safe and reliable. But authentication is as far as oAuth 2 goes. It has no concept of sessions, mutable user-data, or payment flows. There are other layers that handle this, built on top of oAuth 2 such as OpenID Connect - but they again rely on your ability to set cookies from your URL.

When you're using a Saaslet widget on your page, you create it via saaslet.js. That would have made it easy for the widget to authenticate via our API, receive a cookie and set it via JavaScript for your domain.

But here's the catch: cookies set via JavaScript can also be read and changed via JavaScript - and not just your JS - any JS running on the page. That means that any malicious code in a third-party library you're using, any embedded advertisement or analytics snippet, etc. could hijack the user's session or change its cookie. This is called cross-site scripting (or XSS) and is a fairly common attack vector on the web. The best way to get around it is to set an http-only flag for cookies that make them completely inaccessible to any script running on the site - which is what we did.

on this page: