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?
Right. I know from that perspective. Our deployment has one package that I wrote, so I know our selectors. But I can imagine an application, perhaps poorly architected, that has many code packages where a developer might introduce a selector that could cause problems. It would be nice to query them from an administrative perspective to ensure compliance.
And what about the out-of-the-box ones? I am assuming only the .html (Apache Sling Servlet/Script Resolver and Error Handler) and .json (Apache Sling GET Servlet) extensions are available. What about default selectors?
This is all really a theoretical exercise for what can be done on the publish instance. In practice, we completely lock down our application through the dispatcher. Only .html files on our content paths are supported. No selectors on .html. No .json either. We even lock down assets (js, css) to specific paths and disable all selectors except for minify.