Contents (5)
Custom REST endpoints are quick to build, and that speed is why security details get skipped. These five come up most often in technical reviews.
A permission_callback that is always true
register_rest_route( 'hamidarab/v1', '/orders/(?P<id>\d+)', [
'methods' => WP_REST_Server::READABLE,
'callback' => 'hamidarab_get_order',
'permission_callback' => static fn ( $request ) => current_user_can( 'edit_shop_orders' ),
'args' => [
'id' => [ 'validate_callback' => static fn ( $v ) => is_numeric( $v ) ],
],
] );__return_true is only right for data that is genuinely public.
Input without sanitising and validation
Define validate_callback and sanitize_callback for every argument, so data is clean before it reaches your logic.
Returning whole objects
Build the response explicitly and return only the fields you need; returning a whole order or user object is how data leaks.
No nonce on browser requests
Cookie-authenticated requests must send an X-WP-Nonce header, or WordPress treats them as a guest.
No rate limiting
Public endpoints that do heavy work, with no rate limit or cache, are an easy way to take a site down.
$ ./request_review
Facing the same problem in your own store?
Senior WordPress and WooCommerce backend engineering for complex production problems.
Request a Technical Assessment
## Comments