Obscured Plausible proxy endpoint is discoverable via /wp-json/

[crweiner]

Hello Plausible team, one of the sites my team manages is getting an automated flood of POST and GET requests to the obscured Plausible endpoint that is created by turning on "Bypass ad blockers". If we use Cloudflare's WAF to block traffic to this endpoint, then clearly that blocks legit traffic tracking as well.

We noticed that /wp-json/ (and /wp-json/<namespace>/v1/) list the Plausible endpoint publicly with the GET and POST methods that they support. While we are not certain about this, exposing the Plausible endpoint in /wp-json/ might be the reason why the site we manage is getting flooded with traffic to the endpoint. If the Plausible endpoint is publicly listed in /wp-json/, it would make it easier for bots to find and try to keep writing to that endpoint.

We do know that plausible.init is visible in the page source, so removing the API endpoint from appearing in /wp-json/ is not a perfect solution, but it might make it a bit harder to automatically find. "Security through obscurity" isn't perfect, by any means.

My team has been testing out some changes to try and obscure and harden the endpoint a bit more, such as:

1. Hide Plausible proxy routes from REST discovery

• File: src/Proxy.php
• Added a rest_route_data filter
• Removed both:
  • /<namespace>/v1
  • /<namespace>/v1/<base>/<endpoint>
    from the /wp-json/ route list

2. Block namespace index probing

• File: src/Proxy.php
• Added a rest_pre_dispatch filter
• Return 404 for GET /wp-json/<namespace>/v1/

3. Replace permissive route access with validation

• File: src/Proxy.php
• Replaced permission_callback => __return_true
• Added validation for:
  • POST body size
  • Content-Type JSON
  • valid JSON
  • same-site Origin/Referer
  • expected payload keys
  • expected Plausible domain
  • local-site event URL

4. Fix error status handling

• File: src/Proxy.php
• Updated the response-code shim so validation failures remain 400/404/413 instead of being normalized incorrectly

5. Harden MU speed module

• File: mu-plugin/plausible-proxy-speed-module.php
• Added early short-circuit rejection for:
  • namespace probing
  • wrong path under namespace
  • non-POST
  • non-JSON
  • missing same-site provenance
  • oversized bodies
  • invalid payloads

If there is a need to keep the Plausible endpoint accessible via /wp-json/, then do let me know, and sorry for the unneeded GH issue! If that is the case, are there any other recommendations you have to avoid bots hammering away at the REST endpoint?

Happy to open a PR with our team's changes as well, if that is helpful.

Thank you for taking a look at this and do let me know if you have any questions!

[Dan0sz]

Ah, you're correct. There's no reason for the endpont to be publically available, but they are by default.

I'm curious to the changes you made, please create a PR and (after checks) I'll include it in the next release!

[crweiner]

Thank you for responding so quickly, @Dan0sz! Good to know that there isn't a reason for those to show up in /wp-json. 👍 My team is still testing out some of our tweaks, and we're not quite ready yet to share our suggestions, so I'll ping you here when we have a PR ready for you to review if that's ok!

[Dan0sz]

Sure, @crweiner. That's fine! Looking forward to it!