Security issues with React.Provider
Closed this issue · 5 comments
Hello @bvaughn ,
Maybe it's a problem of understanding but I see a lot of React applications that protect the whole App with the Provider. For instance, here we have a tutorial:
- Blog: https://www.freecodecamp.org/news/how-to-protect-your-routes-with-react-context-717670c4713a/
- CodePen example: https://codesandbox.io/s/p71pr7jn50
- Demo example: https://p71pr7jn50.codesandbox.io/
Here, in the demo example, we have a AuthProvider component that have in its state the property isAuth that it's a boolean. The application seems to work fine and you can login/logout without problem and isAuth will be true/false depending on the action.
On the other hand, I can open de React DevTools, go to the component AuthProvider and check the state of isAuth... Then, I will be logged.
Maybe it's a problem of misconception, but I think that this class of auth architecture have a problem of security. Can we define a state in the Provider that it's not editable with the React Dev Tools?
Thanks :)
Restricting developer tools is not the solution, the app would have bigger security concerns if no server-side validation is actually performed and trusts everything the client sends.
It is similar to only relying on client-side JavaScript to perform input validation and hoping it solves SQL injection, an attacker can send the HTTP request by themselves, or make the validation function always return true.
Hello @ngyikp ,
First of all, thanks for your quick answer :) .
We have server-side validation and it won't be a problem for us that somebody try to make an action that is not allowed. For instance, the same page must be shown in a read-only mode depending on the kind of role. If someone change the role and go from a read-only role to a full-access role this person will be allowed to change, locally, the data and try to send it to the server with the Save button. The server will response: "You are not allowed to do this action" or whatever. That it's controlled.
What I see a little bit weird is that the user can change the role defined in the Context because, in fact, is a component with its own state and this state can be changed using the React Developer Tools. I do not know if saving this kind of data in the Context is the best option.
What do you think @ngyikp ?
Thanks for your answers!
@aaronplanell this has nothing to do with devtools.
Everything you do in front is done in the browser, so with any debugger or console, you can show and edit any variable in your code base.
However indeed, we could expect that the devtools would be deactivated in production environment, as Vuejs ones do.
Hello @mathieutu ,
I understand that but, at least, to try not to put things so easier, hehehe.
I solved this issue because I used hooks with React 16.8 and the state is not updatable from the DevTools (AFAIK, it will be in React 16.9). Using the state of a component, it's editable and the user can change isAuth value to true, then the user will see the inputs and the save button. If the user try to save the API will answer "You don't have permissions" and it's OK.
It would be nice to have a property to say: "OK. This state is not editable from DevTools" or, depending on the build (develop or production), make this decision.
What do you think?
Thanks for your answer :)
We don't offer that because it's a false guarantee. You can always pause the debugger in the right place and change any variable. We intentionally don't provide an option like this because it would give a false impression of a security guarantee where there is none. If you don't want some code to run, don't send that code to the client.