I need to be able to store protected, DOM element, attributes at the UI. (For example, I want to store the DBKEY of the target database row along side the matching table row.)
As I can see no way of locking the DATA- attributes down to prevent user manipulation, I am in need of a viable alternative.
The freeze() method is only available at the Object/Element level, so the next thing that comes to mind is a minimal virtual DOM (or two-way binding) but virtualDOM are anathema to me, and surely there must be another way to do this.
So, I can keep and maintain a nodeList of DOM Elements and mutations on my current pagelet/DIV and add/modify as many protected attributes as I like. Resulting in sequential searches of the nodeList +/- making the index available to Javascript.
Or B, create a mirror, unattached DOM tree create/node, appendChild etc. But closest() is good but I know of no built-in down-tree search.
Anyway, I've got to be over thinking this? Is there a simple way to supply a read-only attribute to a DOM element?
This is essentially impossible to secure. The major issue is that modification to the DOM is not even the most dangerous attack you can have against your application. It is the laziest one, so preventing that will only deter people with barely any motivation to try and attack your application. They would likely not even try to modify the DOM.
Here are a couple of important scenarios where the protection will not work:
Instead of modifying the DOM and then triggering a request to the backend, the user can simply make the request themselves. It could be through Postman or even directly using the browser tools.
Modern browsers even allow modifying and re-playing an HTTP request, so anybody can do that with a few clicks and change whatever parameter you want to keep static.
A user can clone the site, modify the HTML statically before opening it, then run it in a browser.
It is a bit more effort than just doing the HTTP request but it is not really that complex of an attack and users without much of any programming knowledge can do that.
There are a myriad of other ways to go around client-side protection but these two are probably very important as they fundamentally bypass a "frozen DOM". Anybody using the dev tools can also go around most types of protection or alter the code that runs. It is more involved but it is mostly annoying, rather than some hard stop.
The solution is not to try and jump through hoops on the client-side but make sure the server-side is well-protected from users tampering with the input.