Under the guidance of the security checklist (Security Checklist: "Incorporate controls at the application level; Control the selectors in your application"), how would I determine all possible extensions and selectors that are running in my instance?
This approach does not work, because you can come up even with non-existing selectors which you need to block as well. Therefor you should switch from a blacklist approach (deny things which you know you don't use) to a whitelist approach (deny everything but allow the things you need).
In that case it would mean, that you should come up with a ruleset, which starts with a "deny all" and then allow all selectors you use. That should be doable if you have an application which rarely uses selectors at all. It becomes hard if you use many selectors and nearly impossible when you don't know the selectors, because they are kind of dynamic (and unknown to development time).
Still, this is a flawed approach too. Because if someone really wants to take you out of business, that person will just run a DOS against your site, not exploiting your application at all, but rather saturating the network pipes (that's a service you can probably get on some darknet marketplaces). In that case a careful locked application does not help you, because enduser requests hardly ever reach your application, but get stuck somewhere between the enduser and your servers.
And if that someone tries hard enough, you have to throw many many resources (that means: $$$$) at it to mitigate such attacks.
Therefor I see the security checklist not as a way to protect your AEM from begin DOSed, but rather to avoid the leakage of sensitive data, which shouldn't get exposed. The only DOS you should be aware of is the regular traffic coming in from the users of your site.
kind regards,
Jörg
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.