Publicado el por Félix Molinuevo

How to Secure the WordPress REST API Without Breaking WordPress

The WordPress REST API is not something you should automatically disable.

Modern WordPress depends on it. Gutenberg, plugins, WooCommerce, and external integrations can use the REST API to communicate with your site.

But leaving every endpoint open without reviewing what it exposes can create unnecessary security risks.

So the real question isn’t:

How do I disable the WordPress REST API?

It’s:

How do I secure the WordPress REST API without breaking WordPress?

The answer is not to block /wp-json/ entirely. Instead, you should keep the REST API available while controlling what it exposes, who can access it, and how requests are handled.

This became particularly relevant in 2026. WordPress 7.0.2 fixed a critical REST API batch-route confusion and SQL injection issue that could lead to Remote Code Execution. WordPress subsequently released additional security updates, including WordPress 7.0.4 in August 2026.

This guide shows how to harden the WordPress REST API without breaking the features your site depends on.

If you only have a few minutes, start with Step 1: make sure WordPress itself is patched. Then audit what /wp-json/ exposes and tighten individual routes instead of trying to shut down the entire API.

Why WordPress REST API Security Matters in 2026

The REST API isn’t inherently dangerous. It’s a core part of modern WordPress.

The security problem appears when a vulnerable component processes REST API requests incorrectly, when an endpoint exposes more information than it should, or when a custom route doesn’t properly enforce authorization.

A good example came in July 2026.

WordPress 7.0.2 addressed a critical REST API batch-route confusion and SQL injection issue that could lead to Remote Code Execution. The fix was also backported to affected WordPress 6.9 and 6.8 branches. See the official 7.0.2 security release notes.

And security work didn’t stop there. WordPress 7.0.4, released on August 12, 2026, included another security fix involving authenticated Author+ remote code execution through malicious file uploads on sites using Imagick and Ghostscript. See the official 7.0.4 release notes.

The lesson isn’t that /wp-json/ should be blocked.

It’s that WordPress security is a layered problem.

Keeping Core updated, controlling REST API permissions, limiting unnecessary exposure, securing plugins, and protecting the underlying server all matter.

Step 1: Make Sure WordPress Is Fully Updated

Before changing REST API behavior, check your WordPress version.

This is the most important REST API security step because hardening an endpoint does not protect you from a vulnerability that has already been fixed in WordPress Core.

Go to:

Dashboard → Updates

and make sure you’re running a current, supported version.

As of August 2026, WordPress 7.0.4 is the latest security release in the 7.0 branch.

You can also check your version from the command line:

wp core version

Then update if necessary:

wp core update

Don’t treat REST API hardening as a substitute for patching.

An outdated WordPress installation is a much bigger problem than an exposed /wp-json/ route by itself.

Step 2: See What Your /wp-json Actually Exposes

Once WordPress is patched, inspect the REST API.

From a terminal:

curl https://yoursite.com/wp-json/

The response contains information about the registered REST API routes available on the site.

The WordPress REST API also provides a discovery mechanism through its API root, making it possible for clients to discover available routes.

You can check a specific endpoint directly:

curl https://yoursite.com/wp-json/wp/v2/users

The /wp/v2/users endpoint is a standard WordPress REST API endpoint for retrieving users. Whether anonymous users can retrieve useful information depends on the endpoint’s permissions and the data exposed by the installation.

The important distinction is this:

Don’t ask whether /wp-json/ is public. Ask which routes are public and whether they are supposed to be public.

That’s a much better security question.

Step 3: Should You Disable the WordPress REST API?

Usually, no.

The REST API is part of how modern WordPress works. Gutenberg, WooCommerce, plugins, and integrations may depend on it.

Blocking /wp-json/ globally can therefore create problems that are harder to diagnose than the security issue you’re trying to solve.

Instead of:

How do I disable the WordPress REST API?

ask:

Which REST API endpoints should be public on my site?

That’s the safer approach.

For example, a public website may legitimately expose content through:

/wp-json/wp/v2/posts

while a custom endpoint containing private business information should require authentication and authorization.

The goal is least privilege, not zero exposure.

Step 4: Stop WordPress User Enumeration

The /wp/v2/users endpoint is part of the standard WordPress REST API and can return a collection of users when the request is permitted.

If your site doesn’t need anonymous access to that endpoint, you can remove it from the available REST routes.

A site-specific must-use plugin is one option:

<?php

add_filter('rest_endpoints', function ($endpoints) {

    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }

    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }

    return $endpoints;
});

Save it as:

wp-content/mu-plugins/disable-user-enumeration.php

Make sure the mu-plugins directory exists before creating the file.

The rest_endpoints filter is specifically designed to filter the available REST API endpoints.

Then test again:

curl https://yoursite.com/wp-json/wp/v2/users

The important result is that an anonymous request should no longer return the user collection if you’ve removed the route.

Don’t assume the response must be exactly 401 Unauthorized. The result depends on how the endpoint is removed or restricted and how the request is handled.

A simpler alternative

If you’re not comfortable modifying WordPress files, a security or WordPress management plugin can handle some forms of user-enumeration protection.

Just remember that plugins are another component you have to maintain — see our guide on WordPress plugin security before adding one to a production site.

For a production site, the important part isn’t which method you choose.

It’s verifying that:

  1. The endpoint is no longer unnecessarily exposed.
  2. Login still works.
  3. Gutenberg still works.
  4. Plugins that need REST continue working.
  5. You haven’t introduced new errors.

Step 5: Secure Custom REST API Routes With Proper Permissions

This is one of the most important checks for developers.

If your site or one of its plugins registers custom REST API routes, each route should have an appropriate permission_callback. See the official documentation on adding custom endpoints.

For example:

register_rest_route('myplugin/v1', '/data', [
    'methods'  => 'GET',
    'callback' => 'my_data_callback',
    'permission_callback' => function () {
        return current_user_can('edit_posts');
    },
]);

The permission_callback determines whether the current user is allowed to access the endpoint.

For private or privileged operations, WordPress recommends checking capabilities with current_user_can() rather than simply checking whether someone is logged in.

Authentication and authorization are not the same thing.

A user can be authenticated without having permission to perform a particular action.

What about __return_true?

You may see code like:

'permission_callback' => '__return_true'

That isn’t automatically a security vulnerability.

It is appropriate when the endpoint is intentionally public.

The problem is using a public permission callback for an endpoint that exposes private information or performs privileged operations.

So the question isn’t:

Is this endpoint using __return_true?

It’s:

Should this endpoint actually be public?

If the answer is yes, __return_true can be appropriate.

If the answer is no, the endpoint needs a real authorization check.

Step 6: Audit Your REST API Routes

Visit:

https://yoursite.com/wp-json/

and review the routes registered by your site.

Look for custom namespaces and endpoints created by:

  • Plugins
  • Custom themes
  • WooCommerce extensions
  • Internal applications
  • Third-party integrations
  • Custom WordPress development

For every custom endpoint, ask:

Is it supposed to be public?

If yes, document why.

Does it expose private data?

If yes, require appropriate authorization.

Does it perform an action?

If yes, verify that the permission check is appropriate for that action.

Does it accept user-controlled input?

If yes, validate and sanitize it appropriately.

Does it depend on a plugin?

Check that the plugin is actively maintained and fully updated.

A useful rule is:

Public by design is different from public by accident.

That’s the distinction you want to establish for every route.

Step 7: Rate-Limit /wp-json When Appropriate

Authentication and authorization aren’t the only controls you can use.

Rate limiting can help prevent excessive requests against REST endpoints.

If your server uses Nginx, a basic configuration could look like this:

limit_req_zone $binary_remote_addr zone=restapi:10m rate=10r/s;

location /wp-json/ {
    limit_req zone=restapi burst=20 nodelay;
}

Treat those values as an example baseline, not a universal configuration.

The correct limits depend on how your website uses the REST API.

For example, a WooCommerce store or an application with frequent API requests may need very different limits from a small brochure website.

Before deploying rate limiting, test:

  • Gutenberg
  • WooCommerce
  • Search
  • Contact forms
  • Membership functionality
  • External integrations
  • Any custom JavaScript using the REST API

If you don’t have server-level access, your hosting provider or a security layer may be able to implement rate limiting for you.

Step 8: Verify You Didn’t Break WordPress

Security changes are only useful if the site still works.

Ideally, test changes on a staging environment first.

At minimum, verify:

  • curl https://yoursite.com/wp-json/wp/v2/users no longer exposes an unnecessary user collection.
  • Gutenberg can still save and update posts.
  • WooCommerce admin functionality works if installed.
  • Contact forms continue working.
  • Search functionality works.
  • Any REST-based integrations continue working.
  • Browser developer tools don’t show unexpected REST errors.
  • Server logs don’t show a large increase in legitimate failed requests.

If something breaks after blocking or restricting a REST route, don’t assume the security rule is correct.

Find out which component needs that endpoint before deciding whether the endpoint should remain available.

Step 9: Secure the Server Behind WordPress

REST API hardening is only one layer of WordPress security.

A properly configured WordPress installation should also have:

  • Current WordPress Core
  • Updated plugins and themes
  • Strong administrator authentication
  • Two-factor authentication where appropriate
  • Least-privilege user accounts
  • Secure file permissions
  • Server-side firewall or WAF protection
  • Rate limiting where appropriate
  • Reliable backups
  • Monitoring and logging
  • A supported PHP version
  • Secure hosting configuration

This matters because an attacker doesn’t care whether the vulnerability is in /wp-json/, a plugin, PHP, or the underlying server.

They only need one workable path.

REST API hardening cannot compensate for an outdated WordPress installation or an insecure server.

What About XML-RPC?

REST API security and XML-RPC security are related, but they aren’t the same problem.

You may see recommendations to disable:

/xmlrpc.php

This can make sense for sites that don’t need XML-RPC functionality.

But don’t automatically disable it just because it exists.

First determine whether your site or integrations still depend on it.

The same principle applies here as with /wp-json/:

Remove functionality you don’t need. Don’t remove functionality simply because it’s accessible.

What the 2026 REST API Vulnerabilities Teach Us

The WordPress 7.0.2 security release is a useful example of why WordPress security shouldn’t be reduced to «hide this endpoint.»

WordPress 7.0.2 fixed a REST API batch-route confusion and SQL injection issue that could lead to Remote Code Execution. The issue was addressed in the security release and fixes were backported to affected WordPress branches.

The appropriate response to that kind of vulnerability is:

  1. Identify whether your WordPress version is affected.
  2. Apply the security update.
  3. Check whether plugins or custom code are involved.
  4. Review logs if you suspect exploitation.
  5. Investigate signs of compromise rather than simply changing endpoint visibility.

That’s an important distinction.

Hardening reduces attack surface. Patching removes known vulnerabilities. They are complementary, not interchangeable.

What This Doesn’t Cover

Securing the REST API doesn’t make a WordPress site secure by itself.

It doesn’t replace:

  • WordPress Core updates
  • Plugin and theme updates
  • Strong authentication
  • Two-factor authentication
  • Secure hosting
  • Backups
  • Server monitoring
  • WAF or firewall controls
  • Malware detection
  • Incident response

It also doesn’t guarantee that a site hasn’t already been compromised.

If you suspect an intrusion, don’t just hide the endpoint and move on.

Check the site’s logs, installed plugins, administrator accounts, modified files, scheduled tasks, and recent changes.

WordPress REST API Security Checklist

  • [ ] WordPress Core is fully updated.
  • [ ] Plugins and themes are fully updated.
  • [ ] /wp-json/ has been reviewed.
  • [ ] /wp-json/wp/v2/users has been tested anonymously.
  • [ ] Unnecessary public endpoints have been removed or restricted.
  • [ ] Custom REST routes have appropriate permission_callback functions.
  • [ ] Private endpoints require appropriate authorization.
  • [ ] Public endpoints are intentionally public.
  • [ ] User-controlled REST API input is validated and sanitized.
  • [ ] REST API rate limiting has been considered.
  • [ ] Gutenberg and other REST-dependent functionality have been tested after changes.
  • [ ] Server logs are being monitored.
  • [ ] Backups are available and tested.
  • [ ] The underlying hosting environment is properly secured.

FAQ: WordPress REST API Security

What is the WordPress REST API?

The WordPress REST API is a JSON-based interface that allows WordPress and external applications to communicate with a WordPress installation.

The block editor, plugins, mobile applications, and external integrations can use it to read or modify WordPress data.

That makes it an important part of modern WordPress — and an important part of its security surface.

Is the WordPress REST API a security risk?

Not by itself.

The REST API is a normal WordPress feature. The security risk comes from vulnerable code, unnecessarily exposed information, poorly protected custom endpoints, or inadequate authorization.

Should I disable the WordPress REST API?

Usually, no.

Gutenberg, WooCommerce, plugins, and integrations may depend on it.

Instead of blocking /wp-json/, audit individual endpoints and restrict the ones that don’t need to be publicly accessible.

How do I secure the WordPress REST API?

Start by keeping WordPress Core, plugins, and themes updated.

Then review the routes exposed by /wp-json/, remove or restrict unnecessary endpoints, make sure custom routes use appropriate permission_callback functions, and consider rate limiting.

Finally, test the site to make sure legitimate REST API functionality still works.

How do I check what my WordPress REST API exposes?

Open:

https://yoursite.com/wp-json/

You can also test individual endpoints from a terminal:

curl https://yoursite.com/wp-json/wp/v2/users

Then determine whether the information returned is actually intended to be public.

How do I stop WordPress REST API user enumeration?

If your site doesn’t need anonymous access to the users endpoint, you can remove or restrict the relevant REST routes.

One approach is using the rest_endpoints filter to remove /wp/v2/users.

After making the change, test the endpoint again and confirm that an anonymous request no longer returns the user collection.

How do I secure custom WordPress REST API endpoints?

Make sure every custom route has an appropriate permission_callback.

For private or privileged operations, check the authenticated user’s capabilities with functions such as current_user_can().

Also validate user-controlled input and avoid exposing sensitive information unnecessarily.

Does blocking /wp-json/ break WordPress?

It can.

Gutenberg, WooCommerce, plugins, themes, and external integrations may depend on the REST API.

A better approach is to identify and restrict unnecessary endpoints while leaving required functionality available.

Is __return_true insecure in a WordPress REST API route?

Not necessarily.

__return_true is appropriate for endpoints that are intentionally public.

It becomes a problem when it’s used for an endpoint that exposes private information or performs an action that should require authorization.

What was the 2026 WordPress REST API vulnerability?

WordPress 7.0.2 fixed a critical REST API batch-route confusion and SQL injection vulnerability that could lead to Remote Code Execution.

The vulnerability was addressed through a security release, with fixes also backported to affected WordPress branches.

The correct response was to update affected installations, not simply block the REST API.

The Bottom Line

Don’t disable the WordPress REST API just because it’s public. Secure it instead.

Start with the basics:

  1. Keep WordPress Core patched.
  2. Audit /wp-json/.
  3. Remove unnecessary public endpoints.
  4. Protect custom routes with proper authorization.
  5. Validate and sanitize user-controlled input.
  6. Rate-limit API traffic when appropriate.
  7. Test everything after making changes.
  8. Secure the hosting environment underneath WordPress.

The goal isn’t to make the REST API invisible.

The goal is to make sure every endpoint that is exposed is exposed for a reason.

If you’re not sure what your WordPress installation is exposing, AXR Global can review your WordPress configuration, hosting environment, REST API routes, and security controls and help you harden the site without breaking the functionality your business depends on.

→ Schedule a security audit