FastRender + page caching = security hole?

[shilman]

Suppose I am running FastRender on a page that does not require the user to be logged in. Furthermore, suppose I am using a CDN or some other intermediate page cache to improve my page load performance.

Now, suppose a logged-in user Alice accesses that page. FastRender will insert Alice's loginToken into the page head, and the page will be cached.

Next, suppose another user Bob accesses the cached page. Bob will then have access to Alice's loginToken, and can therefore access the site as Alice.

If this is correct, FastRender should never be used in conjunction with page caching. Or am I misunderstanding something about FastRender and/or Meteor security?

Thanks for your help.

[avalanche1]

as far as I know, FR doesn't inject loginToken alongside with user data..
You can check this by Meteor.user() in the console.

[arunoda]

It's depends. We send the loginToken, if it comes with the cookie. (We can do it better). So, if you cached a loggedIn users page(even if it's a public page), it will have issues.

If you cached a non-logged user's page that won't have any issues.

[shilman]

Thanks for the response @arunoda -- I think this is a pretty serious issue and I'm surprised that more people haven't made a fuss about it. I guess this is a great reason to transition to SSR as quickly as possible. Thanks for being a trailblazer on both fronts! 😄

If I come up with any good workarounds/practices as I work through this, I will post them here.

[avalanche1]

@arunoda, could you elaborate on if it comes with the cookie and how to circumvent this?

[arunoda]

FR set the loginToken into the cookie once loggedIn. Then every request to server carries the login token. That's how it identify the user.

[theodorDiaconu]

I'm almost sure there is nothing in this world that offers page caching for logged in users. As different people may see different results based on their role/data access restrictions on the same route.