4

I have just started learning authorization and authentication in react, and I'm writing this after finishing my first simple login system using JWT, as most of you know you store a token in the browser and then you compare it with the saved tokens in your backend now when that validation is done truly I set Authenticated Boolean to true and gain access to the website, after finishing that simple system I checked react dev tools and I found out that I can just change the boolean to true and bypass all of the authentication work!

And I have searched online for resources and tutorials to fix that massive problem but didn't find what was I looking for all I found is how to setup Authentication or protect a router similar to the way I did, but not deeply secured.

So can anyone recommend a course or tutorial paid or free to learn more about security and authentication?

Henry Woody
  • 14,024
  • 7
  • 39
  • 56
Kadiem Alqazzaz
  • 554
  • 1
  • 7
  • 22
  • 3
    That's why you need to check everything on the server. – SLaks Feb 25 '19 at 17:44
  • @SLaks you mean every time a user enters a page I must send check request to the server? wouldn't that make extra load on the server? also if there a lot of pages it would be time consuming to add check method to all of those pages – Kadiem Alqazzaz Feb 25 '19 at 17:54
  • Generally I think of web pages as two parts: Data and Presentation. The presentation (which is usually your react/html/css code) can't easily be secured (and generally doesn't need to be), but the data can and should be secured. Securing data is as straightforward as only sending data you want a user to have access to, and nothing else. This is done on the server side. *You should assume anything you send over the internet can be read by the user, even if you don't display it on a webpage*. – Garrett Motzner Feb 25 '19 at 18:05
  • @SimpleWebDesigner You have to send the JWT tokens within each requests to your backend (i.e. when accessing/creating/updating/deleting data). Then if the user is not authenticated, he will see the app but he won't see any data and won't be able to perform any action on your database. – GG. Feb 25 '19 at 18:08

1 Answers1

6

Since React apps are single page apps (if you are doing client-side rendering), the entire application (all html/css/js files) is sent to the client in the initial request. Generally authentication works in the way you have stated where the authentication status of the user is stored in the application state. This, of course, means that someone familiar with web applications would be able to set the variable isAuthenticated to true. If you have sensitive information kept statically (written literally in html/css/js) then this would be an issue.

The reason this scenario is not generally seen as an issue is because React apps usually do not hold any data. And data is usually the sensitive stuff in an app. Data can be tied to the user and should not be exposed to those who are not properly authenticated or do not have the required permissions. Data is held by the server, which can control what it sends out (checking for verified JWTs) via the API to the app. So your server should check for a valid JWT on any request that returns sensitive information—generally all requests except those for the app itself and authentication requests.

In short: Yes, someone can get access to the "authenticated" side of your app, but any requests to the API for data by the app at this point would (or should) be blocked as unauthorized (i.e. status 401). So they can see what the app looks like to an authenticated user, but would not be able to see any sensitive information.

(Note: if you do store sensitive information statically (as mentioned above), consider storing it on the server and having the app request that info via the API and requiring a valid authentication token).

If you would like to block the possibility of an unauthenticated user gaining access to the authenticated side of your app, you could make the login page its own app or HTML doc and only send the full/authenticated version of the app to authenticated users.

Henry Woody
  • 14,024
  • 7
  • 39
  • 56
  • New to this too but wouldn't implementing `Express` with middleware solve this issue? I've been researching this topic and also ran across that storing the token as a cookie is vulnerable to attacks, [reference](https://stackoverflow.com/questions/27067251/where-to-store-jwt-in-browser-how-to-protect-against-csrf). Any suggestions on a tutorial or post that outlines a resolution for testing? – DᴀʀᴛʜVᴀᴅᴇʀ Feb 25 '19 at 18:16
  • 1
    @Gʀɪᴍ Yeah the server should have some middleware that validates (or rejects) a request based on the JWT attached to it. I generally store the JWT in localStorage, which is safer when it comes to [CSRF](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)) attacks but a bit more vulnerable to [XSS](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)), which means you'll need to take extra care to prevent XSS attacks. Then when the app makes an API request it can place the JWT in the 'Authorization' header ( while cookies are attached to requests automatically). – Henry Woody Feb 25 '19 at 18:26