Always assume that the adversary has full control over the browser.
Typically if you want your app to be secure against malicious entities, the security of it has to come from the server. Make authorization/bearer tokens or a cookie scheme that can be verified by your server (i.e. https://jwt.io/). Then only allow data to be sent from to the users you want to based on that information. Security/validation in the front-end is more about making sure users don't unintentionally mess things up.
The user has full ability to modify any HTML/CSS/JS you have in the browser via various dev-tools.
The user has full access to any information being sent via the JavaScript (even if it's minified, there are tools to unminify it to some extent).
All React state can be modified pretty easily using React's dev tools, If you are using redux, you might have the redux dev tools set up.
In firebase, there's a whole section on security in the docs. Set up the data that would be behind your RestrictedView
s to require the levels of authentication you need them to. Make sure that firebase does it's share of your application security. The section on insecure rules is also a good place to start reading up on what firebase can do for you and how to configure their security rules.
Some further reading:
OWASP Top Ten (2017) Broken Access Control (bold is added for emphasis)
Access control is only effective if enforced in trusted server-side
code or server-less API, where the attacker cannot modify the access
control check or metadata.
With the exception of public resources, deny by default.
Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any
record.
Unique application business limit requirements should be enforced by domain models.
Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
Log access control failures, alert admins when appropriate (e.g. repeated failures).
Rate limit API and controller access to minimize the harm from automated attack tooling.
JWT tokens should be invalidated on the server after logout. Developers and QA staff should include functional access control unit and integration tests.
Understanding React Frontend security
We need to make one thing clear — everything you put in the client
browser can be easily changed by the client.
Later in that article:
How do I prevent the user from accessing non-public parts of my site?
You do it exactly as you though to do it — you create a variable, set
it to true for admins only and once the check passes, show the admin
only content.
“Ok, that’s not secure at all — everyone can then go to the admin page
and delete everything!” you scream.
Fair — but only if you implement your application in a bad way. The
frontend part should not be concerned with the validity or not of
credentials provided. It should always accept the data as “true” and
just render all the data it is passed.
It it’s the backend job to perform this validation!