Disable REST API blocks public access to /wp-json/… endpoints. Optionally allow REST API access for logged-in users only, and on Pro, allow it for specific IP addresses.

What this feature does

The WordPress REST API exposes posts, users, comments, settings, and more over HTTP at /wp-json/wp/v2/…. It powers the block editor, mobile apps, headless front-ends, and many third-party integrations. It also leaks information by default: anyone can list your authors at /wp-json/wp/v2/users, which gives attackers a list of valid login names to target.

This setting filters rest_authentication_errors to return a 403 Forbidden for every REST request that doesn’t pass an explicit allow rule. By default that means every request is blocked. Two child settings let you carve out exceptions:

Enable for logged-in usersAllow the REST API for any logged-in user. Most plugins and the block editor work fine with this on.
Allow specific IP addresses ProAllow REST API access only from explicit IPs, regardless of login state.
The block editor needs the REST API

If your team uses the Gutenberg block editor (the default WordPress editor since 5.0), enable Enable for logged-in users. Without it, the editor will fail to load posts or save changes. Logged-in editors are not your security threat; the goal is to block anonymous public access.

How to enable it

  1. Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
  2. Toggle Disable REST API on. The child fields appear: Enable for logged-in users (almost always wanted) and on Pro, Allow specific IP addresses.
  3. Pick your exceptions. Turn on Enable for logged-in users if you use the block editor or any logged-in REST integration. Add IPs to the Pro allowlist for any external service that needs read or write access.
  4. Save and verify. Test with curl -I https://yoursite.com/wp-json/wp/v2/users from an unauthenticated request. The response should be HTTP/1.1 403 Forbidden.

Settings reference

Setting What it does Default
Disable REST API Master switch. Filters rest_authentication_errors to block every REST request unless an exception applies. Off
Enable for logged-in users Allow the REST API for users who are signed in. Required for the block editor and most logged-in plugin features. Off
Allow specific IP addresses Pro One IP per line. Requests from these addresses are always allowed, regardless of login state. Empty

What happens behind the scenes

Filters and discovery cleanup

AdminEase hooks rest_authentication_errors and returns a WP_Error with status 403 for any blocked request. When Enable for logged-in users is on, AdminEase first checks is_user_logged_in() and lets logged-in requests through.

It also removes the discovery hints WordPress normally adds to the front-end: rest_output_rsd, rest_output_link_wp_head, and rest_output_link_header. Anonymous visitors no longer see <link rel="https://api.w.org/" /> in the page head or the matching Link response header.

Developers can bypass the block per-request via the adminease_disable_rest_api_bypass filter, useful for whitelisting a specific endpoint or namespace from a small mu-plugin.

Common workflows

Standard hardening

Master switch on, Enable for logged-in users on. Block editor and admin work normally; anonymous public access returns 403.

Headless WordPress front-end

Don’t use this feature, or use Pro’s IP allowlist to permit only your front-end’s server IP. Headless setups need anonymous public REST access by definition.

External webhook receiver

Pro: add the webhook source’s IP to the allowlist. The integration works while everyone else is blocked.

Troubleshooting

The block editor won’t load posts

Turn on Enable for logged-in users. The block editor fetches posts and saves changes through the REST API and needs that access.

WooCommerce, Yoast, or my page builder shows errors

Most modern plugins use the REST API for various features. Enable for logged-in users covers the common cases. If a specific plugin fetches REST data anonymously (e.g. some review or comment loaders), either Pro-allowlist its known IPs or use the adminease_disable_rest_api_bypass filter to whitelist its specific endpoints.

I can still see /wp-json/ output in a browser

If you’re logged in and have Enable for logged-in users on, that’s expected. Test from a private/incognito window to confirm the block applies to anonymous users.

The hint <link> tag in HTML is gone but my SEO tool says the REST API is exposed

The discovery cleanup is a hint, not a security boundary. SEO tools can still hit /wp-json/ directly to test it. As long as that returns 403 anonymously, your site is correctly hardened. The discovery hint is simply removed for cleanliness.