I found out a custom REST endpoint I’d built for a client’s mobile app was wide open to the public internet when a routine log review turned up a request from an IP I didn’t recognize, pulling customer order data through an endpoint that had no business answering an unauthenticated request. The cause was almost funny in hindsight: during local development I’d set permission_callback to __return_true so I could test the endpoint quickly in Postman without fighting auth, meant to swap it out before launch, and never did. WordPress’s REST API will happily register a route with no authentication at all if you tell it to, and it won’t warn you.
The fix that finally stuck wasn’t a smarter one-off permission check — it was refusing to let a route reach register_rest_route without one. Every custom endpoint in that codebase now goes through a small wrapper function that requires an explicit permission_callback argument with no default, so leaving it out is a PHP error at registration time instead of a silent security hole in production. For endpoints that need real authentication rather than a capability check, I use WordPress’s application passwords rather than rolling custom token logic — wp_authenticate_application_password handles the credential verification, and I just gate the route behind current_user_can for the specific capability the mobile app actually needs, nothing broader.
Scoping that capability precisely turned out to matter as much as requiring a callback at all. My first fix gated the orders endpoint behind edit_posts, which technically worked but meant any contributor-level account on the site could hit an endpoint meant only for the mobile app’s service account. I ended up registering a dedicated capability, read_customer_orders, assigned to exactly one application-password user, so the blast radius of a leaked credential is one integration instead of every editor on the team.
I test this now the same way I’d test any other security-sensitive code path: a Pest test that asserts an unauthenticated request to the endpoint returns a 401, and a second test asserting a request with the wrong capability returns a 403. Those two assertions would have caught the original bug in CI, before it ever reached a server with real customer data on it.
The uncomfortable lesson wasn’t about REST API mechanics — it was that “I’ll fix it before launch” is not a security control. The fix that actually works is the one the framework enforces whether I remember to or not.
