Decide exactly who can query your REST API
Disable REST API restricts the WordPress REST API to logged-in users, administrators only, or nobody at all, closing off a common source of anonymous user and content enumeration.
- Three modes: block guests, block everyone but admins, or block everyone.
- Blocked requests get a proper HTTP 401, not a silent failure.
- Respects any error another plugin already produced.
- The login endpoints WordPress itself needs stay reachable.
Block access for
What does Disable REST API do?
When the disable_rest_api module is active, TOWP_Disable_Rest_Api filters rest_authentication_errors at priority 99 to return a WP_Error with HTTP 401 for requests that don't match the chosen mode. In "Non-logged-in users" mode, the default, only anonymous requests are blocked and any logged-in user keeps full access; in "Non-administrators" mode, only users with the manage_options capability can reach the API; in "Everyone" mode, every request is blocked regardless of login state, including administrators. If another plugin has already returned an authentication error, the module leaves it untouched rather than overriding it.
The REST API tells anyone who's asking, what's there
A fully open API can answer questions about a site that its owner never actually decided to publish.
It's open to the public by default
WordPress's REST API is reachable by anyone out of the box, and by default it can answer questions about registered users, published content and site structure that a site owner never explicitly decided to make public.
It's also required for parts of WordPress to function
The block editor, official mobile apps and many plugins all talk to the REST API, so closing it entirely isn't free; it needs a mode that fits what the site actually depends on.
Three modes, one clear boundary
The module lets the REST API stay open exactly as far as the site actually needs it to.
Block anonymous requests, keep logged-in access
The default mode closes the API to visitors who aren't logged in, while every authenticated user keeps working exactly as before.
Restrict it to administrators only
A stricter mode limits API access to users who can manage the site, closing it to every other role.
Or close it completely
The strictest mode blocks every request, including from administrators, for sites that have no use for the API at all.
A boundary that fits how the API is actually used
Every capability below is present in the supplied PHP class and its settings registration.
The default, balanced mode
Blocks anonymous REST requests while every logged-in user, regardless of role, keeps full access.
Restricted to administrators
Only users with the manage_options capability can reach the API; every other logged-in role gets blocked alongside guests.
Fully closed, including admins
Blocks every request regardless of login state, with an explicit warning that this can break the block editor's own API calls.
A real 401, not a silent failure
Every blocked request receives a WP_Error with HTTP status 401 and a specific, readable message rather than an unexplained failure.
Respects existing authentication errors
If another plugin has already produced an authentication error, the module leaves that response untouched instead of overriding it.
The endpoints WordPress needs keep working
The endpoints WordPress itself relies on to log a user in stay reachable, regardless of which mode is chosen.
Where restricting the API helps most
The module supports any site rethinking how openly its REST API should answer requests.
Preventing user enumeration
Stop the REST API's default user listing from handing out usernames to anyone who asks, a common first step in a credential-stuffing attempt.
Sites with no public API use
Close the API entirely on a site where nothing external, and no block editor use by non-admins, depends on it being open.
Membership and internal sites
Keep the API available to logged-in members or staff while closing it off to the general public.
Less to enumerate, nothing legitimate broken
The module combines a genuine security improvement with a clear, predictable error response.
One filter, scoped to REST requests only
The verified implementation adds a single, lightweight check with no effect outside the REST API.
One filter, one check
The entire restriction is a single filter callback with a straightforward switch statement, adding negligible overhead per REST request.
No effect outside REST requests
The filter only runs during REST API authentication checks, with zero impact on regular page loads.
No database lookups beyond WordPress's own
Capability and login state checks use WordPress's own already-loaded user data, without any additional queries.
A real HTTP 401, nothing overridden
The code returns a proper, standard error and respects any protection already in place.
A real HTTP 401 on every block
Every blocked request returns a proper WP_Error with status 401, rather than an ambiguous or silent failure.
User enumeration closed off by default
The default mode alone prevents anonymous discovery of registered users through the REST API's own endpoints.
Administrator-only configuration
Only an administrator with access to TheOneWP settings can choose which mode applies.
Doesn't override another plugin's own restriction
An existing WP_Error from another authentication mechanism is respected rather than replaced.
Built around native WordPress REST API authentication
The supplied code integrates through APIs present in WordPress core. No compatibility claim beyond the verified implementation is assumed.
rest_authentication_errors
The standard WordPress filter for REST API authentication, the same one core and other security plugins use for this purpose.
current_user_can('manage_options')
The same capability WordPress itself uses to identify administrators, applied here for the "Non-administrators" mode.
is_user_logged_in()
WordPress's own function for checking authentication state, used for the default "Non-logged-in users" mode.
TheOneWP versus common alternatives
Compare the verified Disable REST API implementation with a typical hand-written authentication snippet.
| Capability | TheOneWP Disable REST API | Other common solutions |
|---|---|---|
| Restricting REST API access | Three clear modes, chosen deliberately | Often all-or-nothing if available at all |
| Error handling | A proper HTTP 401 with a specific message | Some snippets return an unclear or malformed response |
| Compatibility with other plugins | Respects an existing authentication error | A poorly-written snippet can conflict with other security plugins |
| Keeping login functional | WordPress's own login endpoints stay reachable | A blanket block can accidentally break login itself |
| Administration | One toggle with a mode selector | Requires a code snippet or a dedicated plugin |
Choose the right mode in four steps
Start conservative, then tighten further only once nothing legitimate breaks.
Enable Disable REST API
Activate the module from the TheOneWP settings.
Choose the right mode
Start with "Non-logged-in users" unless the site has a specific reason to restrict further.
Test anything that depends on the API
Confirm the block editor, any connected app, and relevant plugins still work as expected under the chosen mode.
Tighten further if nothing breaks
Move to "Non-administrators" or "Everyone" only after confirming nothing legitimate still needs broader access.
Tighten deliberately, not all at once
Each mode trades off differently, so it's worth confirming what actually depends on the API before restricting it further.
Start with the default mode
"Non-logged-in users" closes off the most common risk, anonymous enumeration, while leaving every legitimate authenticated use working.
Test the block editor before choosing "Everyone"
The strictest mode can interfere with the block editor's own REST calls, even for administrators, so confirm that's acceptable first.
Check any external integration
A mobile app, headless front end, or third-party service that calls the API needs to be accounted for before restricting access further.
Revisit the mode if the site's use of the API changes
A newly added integration or feature might need the API open more broadly than the current setting allows.
Avoid assumptions that break something legitimate
Each mode has a real trade-off worth understanding before choosing the strictest one by default.
Choosing "Everyone" without testing the block editor
The strictest mode can break the block editor's own API calls, even for administrators, since it blocks every request without exception.
Forgetting about external integrations
A mobile app or a headless front end that relies on the REST API needs to be accounted for before restricting access further.
Assuming there's more to configure
Beyond selecting a mode, there's nothing further to configure; the module is a single field with three options.
Disable REST API FAQ
These answers come directly from the verified class and its settings registration.
What does Disable REST API do?
It restricts who can access the WordPress REST API, with three modes: block anonymous requests, block everyone except administrators, or block everyone.
What happens to a blocked REST API request?
It receives a WP_Error with HTTP status 401 and a message specific to the active mode, rather than a silent or ambiguous failure.
Will this break the block editor?
The default and "Non-administrators" modes shouldn't, since editors and administrators keep access. The "Everyone" mode can affect it, since it blocks every request without exception.
Does this affect WordPress login?
No. The endpoints WordPress itself relies on to log a user in stay reachable regardless of which mode is chosen.
What's the difference between "Non-logged-in users" and "Non-administrators"?
"Non-logged-in users" only blocks anonymous requests, while "Non-administrators" also blocks logged-in users who aren't administrators.
Does this work alongside other security plugins?
Yes. If another plugin has already produced an authentication error, this module leaves that response untouched instead of overriding it.
Does restricting the REST API stop user enumeration?
Restricting anonymous access specifically closes off the most common way the API's user endpoint can be queried without authentication.
Can I change the mode later?
Yes. The mode can be changed at any time from the same settings field, with no need to disable and re-enable the module.
Does this affect mobile apps or headless front ends that use the API?
It can, depending on the mode chosen; any integration that calls the API needs to authenticate according to whichever mode is active.
Who can change the REST API restriction mode?
Only an administrator with access to the TheOneWP settings screen.
Stop letting anyone query your REST API for free.Choose exactly who gets access.
Use Disable REST API to restrict access to logged-in users, administrators only, or nobody at all, with a proper error response either way.