Token Up

Keeping Hands out of the Cookie Jar

Erin Browning

Slides are available at:


Erin Browning

Senior Security Engineer

a.k.a., I'm a hacker

You can contact me at:


latacora logo
slack logo

Slack is hiring!

Slack is used by millions of people every day – we need engineers who want to make that experience as secure and enjoyable as possible.

All of the code-blocked URLs are fake.
Please don't attack my website.

The Problem

I'm an attacker.

I want to take over accounts on your website.

Your site probably looks like this:


Frontend client:

Mobile clients

Your sessions probably look like one or more of these:

  • JWTs
  • Randomized session token
  • API tokens
As you break your website out from a monolith to microservices, how do you store sessions/tokens between an API and your browser-based frontend client?
Auth0's answer:

Is storing your auth in local storage that bad?

Let's find out.

In this talk:

  • Common vulnerabilities that execute in a browser
  • Modern application structures
  • How to take advantage of browser-based protections


Two common attacks
What is XSS?

Cross site scripting

Attacker created javascript is executed in the user's browser in the context of site the user visited

More at:



Cannonical testing example:
<script>alert(1);</script> using alert in js plus an xss vulnerability
What can you do with XSS?

  • Steal cookies
  • Take actions as the user
  • Like changing passwords
  • Change page content
What is CSRF?

Cross-Site Request Forgery More at:

Forces a user to perform actions they didn't intend on a website to which they're authenticated

By default, cookies are included in requests sent cross domain.

What do these attacks have in common?
All of these attacks execute in the user's browser
How are these attacks different?
cow + dolphin jumping up in an ocean with the caption 'anything you can do i can do better'
How can we reduce the impact of these attacks?
First, let's talk about a typical application structure:
  • - contains your frontend + any monolith code
  • - api
  • - administrator site

Where is your authentication stored in the browser?
Probably in a cookie

That cookie is probably scoped to *

If not, it'll be in local storage, placed there by your javascript

Interactions are going through XHR to /api

For those of you who don't do frontend work:
XHR is an API called XMLHttpRequest.
It lets you transfer data between a web browser running JS
and a server without reloading the page.

Traditional CSRF protection stores a random token in a form in an HTML page.

That token gets stored on the server as well.

When the form is submitted, the token is sent with the form data and validated on the server.

Your API may be using a CSRF token, or it may just be relying on monolith form CSRF protection--aka, your api may be vulnerable.
Improvement: use subdomains
Now you have:

You can scope cookies to www, admin and api instead of using *.

The API cookie can have the secure and HTTPonly flags set.
Secure means that cookie will only be sent over HTTPS
HTTPonly means js can't touch it
Yes, the names are confusing, so remember: for HTTPonly, only HTTP requests can access the cookie.

You XHR your requests to api from www.
How do you even do CSRF protection to your API?
Depends on ~content types~

  • multipart/form-data
  • text/plain
  • application/x-www-url-form-encoded
  • application/json
  • application/xml
  • multipart/form-data, can go cross origin
  • text/plain, can go cross origin
  • application/x-www-url-form-encoded, can go cross origin
  • application/json, can't go cross origin without CORS
  • application/xml, can't go cross origin without CORS
What is CORS?

We care about CORS because of the protection offered by the Same Origin Policy (SOP).

What is the Same Origin Policy?

Lots of requests can't be made from URL1 to URL2 if they differ on the following things:

  • Protocol (e.g., HTTP vs HTTPS)
  • Port
  • Host

CORS must be set on the assets you are accessing.
How do you reduce the impact of XSS?

API isn't running js.

www could still be vulnerable, and the site could send requests through XHR.

Improvement: use iFrames
Instead of using CORS, create an iFrame on www to api.

Use the window.postMessage API

docs at

window.postMessage() enables cross-origin communication through DOM-based events.

Windows can send and receive messages from each other through events.

ALWAYS ALWAYS ALWAYS validate your origin

if (event.origin !==
// .. otherwise do some stuff

Improvement: use websockets
Verify your Origin header.
The attacker would need to fake the origin header in the victim's browser.

Modern browsers don't let you set your own origin header.

Common problems:

  • Sites don't check auth before upgrading the connection. The protocol upgrade request will have access to the browser's cookies. Therefore, check auth when upgrading.

iFrames and websockets both have trustworthy origins in the browser.

Ultimately, how can you avoid CSRF hitting your API?

By dropping all requests to API that aren't application/json

How can you avoid XSS?

You can't completely.

Should you store auth in local storage?

Not unless you're sure you can prevent XSS.

How do you know you have a good understanding of all this?

Tell me why XSS is worse in all these cases.

Special Thanks

lvh @latacora

Leigh Honeywell @tallpoppy

The latacora team

The Product Security teams @Slack

see you on the internet bb