"Simple JS can't have unexpected security/performance pitfalls".
Hah.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
I know this isn't directly related, however one of the vulnerabilities is prototype pollution [0], a deceptively simple technique that I think so many apps are vulnerable to. It goes like the following:
- Get an application to serialize or take `__proto__`, `constructor` or `prototype` as an input so it's a key on a JS Object
- Serialize its value to something nasty, like `'{"auth": {"name": "user", "password": "pwd"}, "message": { "text": "", "__proto__": {"canDelete": true}}}'` [1]
This high jacks the prototype of the object and adding those specified properties. If you do things like deep merging of objects on data, you are susceptible to this without the proper guards in hydration / rehydration. The mitigation is simple: don't allow objects to have `constructor`, `prototype`, or `__proto__`. You can delete them by customizing JSON.parse (by passing a reviver [2]) or using something like `mergeWith` to skip these keys
A similar vulnerability exists with `constructor` and `prototype` as well [3]
[0]: https://portswigger.net/daily-swig/prototype-pollution-the-d...
[1]: https://github.com/Kirill89/prototype-pollution-explained
[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[3]: https://shieldfy.io/security-wiki/prototype-pollution/introd...
A prototype can only be modified by code that is actually being run. If you can get someone else's application to run code under your control, you've already won.
It requires some knowledge of the inner workings of the system (in the above, you'd have to know that the auth provider checks for a cached `isAdmin` prop on some object before executing the authentication routine to generate it). But if your system is designed to only be secure if no-one knows the inner workings, you're probably owned anyways.