I am allowing all of the URLs starting with /bin in my dispatcher setup. I am also using various servlets with different extensions (.txt, .xml). I found out that my dispatcher is exposing querybuilder's .json URL. I have followed the dispatcher security checklist but it doesn't have the /bin/* URLs in the checklist. I am looking for a recommended approach for blocking /bin/* URLs.
Blocking the url pattern "/bin/*" on author will break authoring functionality. But that's only true for authoring.
On publish requests should only happen to resourcetypes, thus only requests hitting "/content" plus maybe "/etc" should be necessary. That's also a reason why you should never bind servlets to paths directly: It will make your live much easier if you need to secure your instances.
If you are using dispatcher in front of the author, then you still need to allow "/bin" but for production publish instance the approach you mentioned looks good, block "/bin" and then allow project specific servlets.
That being said, still, I would recommend you perform testing to make sure there is no operation on publish instance that requires users to make a POST call to OOTB servlets under "/bin"
I believe requests like http://localhost:4502/bin/wcmcommand are used internally by AEM and thus I want to block those request on dispatcher as I don't the user to access these internal requests via public URL. I do have the rule that you have mentioned but. I want to block all URLs other than my own servlets via dispatcher as I want to expose my servlet only on public URL. I am looking for a standard approach/best practice. I had thought of serving all of my servlets via /bin/project_name/* then blocking /bin/* and later allowing /bin/project_name/* This will block all the servlets via bin except the /bin/project_name/ servlets. But I am not sure if this is a standard approach for servlets.
The /bin folder is an empty one, and it does not contain any node default from AEM. It is given for the custom development just in case some developer wants to use it for there servlet. hence no security issue from default AEM perspective. But if you are planning to use it and add some stuff in it for internal use, you can block it on the dispatcher. else you can leave it as it does not contain anything.