Are you attempting to block POST's on AEM Author or AEM Publish?
If you are trying to block POST's on AEM Author, don't 🙂 .. AEM uses POSTS and especially those handled by the Sling Default POST servlet liberally. Blocking anything that isn't a POST to a very specific URL is asking to break AEM's OOTB functionalities. You should instead, use ACLs to control what content/content trees an AEM Author can write to via the POSTs (which will result in a 403, not a 200 if the user does not have permissions to write to the target path)
If you are trying to block POST's on AEM Publish. The pattern to do this at AEM Dispatcher is:
1. Deny everything
2. Allow only POSTs for the specific paths/path-patterns you know are required for your application
3. Ensure that your content on AEM Publish is properly protected by ACLs, so any POSTs you DO allow ensure the right ppl are modifying the content.
If you are properly filtering out (DENY'ing) these POST requests at Dispatcher, you will not get a 200, but rather a 404.
The best practice to secure AEM Publish endpoints via Dispatcher is to:
1. First Deny EVERYTHING
2. Then Allow only what you need to
This is why the first rule in the OOTB AEM Publish Dispatcher is "DENY *" 
In terms of identifying what URL end-points need to be ALLOWED in Dispatcher for POST'ing depends on your application's design. Hopefully custom POST end-points are bound to servlets registered to Servlets by Resource Type and Selector/Extension, and the resource that has the respective sling:resourceType's are permissioned accordingly.
If you actually use SlingPostServlet in your application on AEM Publish, then you would want to ensure that POST requests without any selectors, etc. are ONLY available on the content trees that should be written to using the SlingPostServlet, and those resources are permissions properly so only expected users can write to them.
Generally speaking, I would be concerned if any user that isn't admin has write access to /content (not sure if your original example was just an example).
If you are referring to a Sling Servlet from AEM, You would probably need to review the business logic. Amend the doPost() method to check for necessary acceptable values. If acceptable values are not matched, you can return your own custom status, for example, 406 NOT ACCEPTABLE.
I am actually assuming that your doPost method returns a "XXX" (whatever your servlet is setting as the response status) status as the response, on every request.