chore: Configure Mozilla's Eslint Plugin eslint-plugin-no-unsanitized

[andreituicu]

No description provided.

[davidnuescheler]

we try to keep the linter to the bare ootb well understood standard minimum... see: https://www.aem.live/docs/dev-collab-and-good-practices#linting

this doesn't mean that no changes ever can be made to the linter config, but they have to be really extremely common and well understood, and not opinionated, especially if we push them on a boilerplate basis.

[andreituicu]

@davidnuescheler: I'm sorry for the delay in response, I missed your comment.

I was proposing this linter plugin, because I noticed that it is not uncommon for developers to not be aware that some DOM APIs are dangerous and can lead to DOM Based XSS (or other attacks) when mixed with user provided input.

The reason I was thinking the boilerplate is a good place for such an addition is that it creates a "secure by default" starting point for projects (at least from this point of view), same as we have a "performant by default" starting point with 100 Lighthouse score. Just like with performance/Lighthouse, in my mind, it is a lot easier to iteratively built a secure website if there is something to remind developers at every change to avoid unsafe DOM sinks, rather than figure out later which are the usages that are exploitable or not. https://www.aem.live/developer/keeping-it-100#testing-your-pull-requests

I agree that it is opinionated, but in my mind there are a number of opinionated practices in the boilerplate which make for building a good and performant website (e.g. LCP prioritisation, section hiding and unhiding for avoiding CLS, etc.), so I was thinking best-practices for building a secure website would be inline with that.

Now, I'm not yet 100% sure how effective would be on its own, especially since some usages (like the fragment.js example) are unavoidable and that's why I opened it as a draft to start a discussion in this sense. What I personally like about it is: It helps reduce the attack surfaces and raises awareness at the very root, in the moment the code is being written. No unsafe usages potentially means nothing to exploit.