I think we all look at that Disable XML-RPC function in Defender with the same sort of empty feeling. What will this block? What functionality will I lose? How is this actually protecting this site? It’s a very unprofessional “try it and see what happens”, response-based approach to management.
I would prefer a more pro-active approach: THIS is what that change should do. HERE is a report that shows what it has done. I think it would be easy to do this and I’m looking to my trusted vendor WPMU DEV to step up to help with this.
The codex tells us what XML-RPC is for, but I think most of us are blind as to which plugins are using it. I’ve always been concerned that checking that will disable some function used by The Hub or some other DEV product.
As Defender scans plugins for insecure code (I hope it does that, rite?) it would be helpful if it also checked for method invocation and filters related to XML-RPC. Then we can get a report that tells us in concrete terms what we now just hope to find out later by chance and circumstance.
We can scan our own access logs for the text “xml-rpc”, and see what we’re sending back in response. But we need to discern for ourselves what that means. I’m hoping Defender will include a report to tell us the specific API calls that come in over a period of time, and what our site returns in response. I’m sure the implementation would be much less rigorous than my suggestion here, but I’m picturing a grid that has one column per API method or hook, and one row per week (selectable) that shows info about that function: how many hits, HTTP response, and if we’re returning a status 200, a link to the request and response blocks. If we get to a point where there are all zeros across a row in that grid, we Know we’re handling that problem. We should be able to turn on XML-RPC, see a flood of requests from bad guys, and ten turn if off again to verify that Defender is, um, defending us in this area.