In my app’s “on page load” workflow, I display a popup that cannot be closed using the ESC key (it’s meant as a kind of “Accept the terms to continue” agreement). However, I recently discovered something shocking that feels like a security loophole.
When the popup appears and I open the browser’s dev tools (F12), I noticed that if I delete the popup element from the DOM, I can interact with the page as if the popup never appeared. This effectively bypasses the intended restriction.
Is there a way to prevent this? I tried adding some custom JavaScript to the “on page load” workflow, something like “if dev tools is open, do X,” but I couldn’t get it to work properly.
Perhaps there’s an easier way to handle this or maybe a plugin that can help? Any advice would be greatly appreciated…
It’s not a security loophole… it’s just the way the World Wide Web works…
Anything loaded into the users browser can be manipulated by the user.
Anyone can remove, add, or change anything on the web page.
So you should never user client-side logic for security (it’s NOT secure, and never can be).
If you need your users to agree to the terms before continuing, make sure you add some server-side checks that they have agreed to them before they can continue. (i.e. something stored in the database).
You’re absolutely right; I understand that client-side logic isn’t secure and can easily be manipulated. I’ll definitely incorporate server-side checks to ensure users have agreed to the terms before they can proceed.
That being said, is there any way to detect when the dev tools are opened and trigger an action like a redirect or a warning message? I know this wouldn’t make things completely secure, but it could at least act as an additional deterrent for casual tampering…
I am not sure you need to do this, as @adamhholmes said, you need to make server-side checks and always make sure in your next pages that depend on that the terms & conditions have been accepted, that they have been really accepted by checking your database value for this specific user.
If there is something in the same page that you don’t want the user to interact with before accepting the terms & conditions, then you might consider changing your UI to have your terms & conditions acceptance in a separate page before doing anything else.
Hope this helps !
right, and I completely understand the importance of handling this with server-side checks as you’ve mentioned. I can see how restructuring the flow to include a dedicated terms & conditions page would simplify things in some scenarios.
That said, while exploring this further, I noticed another challenge. For instance, on a form submission page, users can manipulate the disabled property of fixed-value inputs or even change their values via dev tools. Similarly, elements that are hidden based on user permissions can be made visible again through DOM manipulation.
In essence, it feels like anyone who knows how to tinker with the DOM can potentially break the system if there aren’t enough server-side checks in place. It’s becoming clear that I’ll need to add quite a lot of server-side validations to cover all these cases… haha.
Would you call this a “Welcome to programming” moment? :))
use privacy rules to limit the data sent to the client based on access rights
use redirects and floating groups to “hide” the page and elements to unapproved users
ensure backend api workflows require authentication
if unapproved users change the dom then they will only see what you’ve allowed them to see with privacy rules
99% of users will not know how to change the dom and those that do won’t bother with it, and for those that do privacy rules will ensure they still can’t access anything they shouldn’t
