Quoting from a long-dead Auth0 forum post: https://community.auth0.com/t/why-is-storing-tokens-in-memory-recommended/17742

"Any values stored in memory are still vulnerable to XSS attacks since they’re accessible by JavaScript. Agreed?

Agreed. The main difference is that localStorage makes it even easier to enumerate the contents. The point of this is just to avoid a brute force XSS attack from being able to dump your localStorage somewhere else that could allow it to be used for nefarious purposes. Storing in memory just makes it so someone has to go through the extra effort of targeting your app specifically. But yes, memory is still susceptible to XSS attacks."

I don't get it.

My Javascript is rusty, but taking a stab at knocking out a quick redirect_uri implementation:

// https:// localhost/redirect.html#access_token=123

(function () {
    const match = RegExp('[#&]access_token=([^&]*)').exec(window.location.hash);
    const token = match && decodeURIComponent(match[1].replace(/\+/g, ' '));


// my library.js

function APICaller(token) {

   var private_static_token = token; // HOW CAN XSS GET HOLD OF THIS?

   APICaller.overlySimpleGet = async function(url) {
     return fetch(encodeURI(url), {
       method: 'GET',
         headers: { 'Authorization': 'Bearer ' + private_static_token },
       .then(response => response.json());

// app code (imports library.js)

   .then((json) => console.log(json));

Given the initial statement in the forum post:

"Storing in memory just makes it so someone has to go through the extra effort of targeting your app specifically. But yes, memory is still susceptible to XSS attacks"

How is the value of private_static_token vulnerable to XSS?

Equally, if you have an XSS vulnerability in your redirect_uri page, then it would seem that a much simpler option for the attacker would be just to read the token when the page loads before it even got to your local variable. And that could be an untargeted attack.

Side note:

It seems to me that there is really only one good method for token storage - a httponly/secure/samesite=strict cookie with CSRF protection, which only works if you have a backend.

The other browser storage options can all, with varying degrees of effort, be compromised by XSS, so you better have a strict Content Security Policy in place for those. (This makes me wonder why OAuth implicit flows don't support cookies as well as headers, but no doubt there is a good/practical reason I can't think of atm.)

  • in this case, i could clobber fetch(), decodeURIComponent(), or APICaller / its methods to get your secret. you could Object.freeze your instance, which helps, but you still need to guarantee the on and off ramps to your secure highway are built by the highway dept. It also unclear why the attacker can't see location.hash, but i point out the less obvious vectors. – dandavis Feb 17 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.