Securing a single page application built on react/react-router

Question

I've been putting together a single-page application using React and React-Router and I can't seem to understand how these applications can be secured.

I found a nice clear blog post which shows one approach, but it doesn't look very secure to me. Basically, the approach presented in that post is to restrict rendering of components which the user is not authorized to access. The author wrote a couple more posts which are variations on the idea, extending it to React-Router routes and other components, but at their hearts all these approaches seem to rely on the same flawed idea: the client-side code decides what to do based on data in the store at the time the components are composed. And that seems like a problem to me - what's to stop an enterprising hacker from messing around with the code to get access to stuff?

I've thought of three different approaches, none of which I'm very happy with:

1. I could certainly write my authorization code in such a way that the client-side code is constantly checking with the server for authorization, but that seems wasteful.

2. I could set the application up so that modules are pushed to the client from the server only after the server has verified that the client has authority to access that code. But that seems to involve breaking my code up into a million little modules instead of a nice, monolithic bundle (I'm using browserify).

3. Some system of server-side rendering might work, which would ensure that the user could only see pages for which the server has decided they have authority to see. But that seems complicated and also seems like a step backward (I could just write a traditional web app if I wanted the server to do everything).

So, what is the best approach? How have other people solved this problem?

Answer 1

Great question. I'm not aware of any absolute best practices floating around out there that seem to outstrip others, so I'll just provide a few tips/thoughts here:

• a remote API should handle the actual auth, of course.
• sessions need to be shared, so a store like redis is usually a good idea, esp. for fast reads.
• if you're doing server-side rendering that involves hydration, you'll need a way to share the session state between server and client. See the link below for one way to do universal react
• on the client, you could send down a session cookie or JWT token, read it into memory (maybe using redux and keep it in your state tree?) and maybe use middleware (a la redux?) to set it as a header on requests.
• on the client, you could also rely on localStorage to save the cookie/JWT
• maybe split the code into two bundles, one for auth, one for the actual app logic?

See also:

• https://github.com/erikras/react-redux-universal-hot-example for hydration example
• https://github.com/erikras/react-redux-universal-hot-example/issues/608

Answer 2

As long as the store does not contain data that the user is not authorized to have, there shouldn't be too much of a problem even if a hacker checks the source and sees modules/links that he shouldn't have access to.

The state inside the store as well as critical logic would come from services and those need to be secured, whether it's an SPA or not; but especially on an SPA.

Also: server-side rendering with Redux isn't too complex. You can read about it here:

http://redux.js.org/docs/recipes/ServerRendering.html

It's basically only used to serve a root html with a predefined state. This further increases security and loading speeds but does not defy the idea behind SPAs.

Answer 3

If you’re trying to protect the code itself, it seems that any approach that either sends that code to the client, or sends the code able to load that code, would be a problem. Therefore even traditional simple approaches with code splitting might be problematic here, as they reveal the filename for the bundle. You could protect it by requiring a cookie on the server, but this seems like a lot of fuss.

If hiding the internal code from unauthorized users is a requirement for your application, I would recommend splitting it into two separate apps with separate bundles. Going from one to another would require a separate request but this seems to be consistent with what you want to accomplish.