How to Disable the WordPress REST API

The WordPress REST API is a powerful interface that allows external applications, themes, and plugins to interact with your site's data. Out of the box, WordPress exposes a number of public endpoints that anyone can query without authentication. While this is useful for headless setups and third-party integrations, it also opens the door to information leaks, especially around user data.

What the WordPress REST API Exposes by Default

When the REST API is fully accessible, several endpoints return data that most site owners would rather keep private. The most commonly abused ones include:

• /wp-json/wp/v2/users: returns a list of all users who have published at least one post, including their username, display name, user ID, avatar URL, and author archive link.
• /wp-json/wp/v2/users/1: returns detailed information about a specific user by ID. Attackers often start with ID 1 because that is typically the administrator account.
• /wp-json/wp/v2/posts: lists published posts along with author information.
• /wp-json/wp/v2/pages: lists all published pages, which can reveal internal site structure.
• /wp-json/: the root endpoint itself reveals all registered routes, giving attackers a roadmap of your site's capabilities and installed plugins.

The /wp/v2/users endpoint is the biggest concern for most sites. Attackers use it for user enumeration, collecting valid usernames that they then feed into brute-force login attacks. Even if you use strong passwords, exposing usernames removes one layer of defense.

Why You Should Not Completely Disable the REST API

It might be tempting to block the REST API entirely, but doing so will break several core WordPress features. The Gutenberg block editor depends heavily on REST API calls to load block data, save content, and manage media. If you disable the API completely, Gutenberg will fail to load and you will not be able to edit posts or pages.

Beyond Gutenberg, many popular plugins rely on the REST API for their functionality:

• Contact Form 7: uses REST API endpoints for form submission handling in newer versions.
• WooCommerce: relies on REST API routes for cart operations, checkout processing, and the admin interface.
• Yoast SEO: uses REST API calls for its metabox and content analysis features in the editor.
• Jetpack: requires REST API access for its connection to WordPress.com services.

The correct approach is selective restriction: block public access to sensitive endpoints while keeping the API available for authenticated users and the WordPress admin area.

Restrict the REST API to Logged-In Users Only

The most effective method is to require authentication for all REST API requests. Add this code to your theme's functions.php file or, better yet, to a custom site-specific plugin:

add_filter('rest_authentication_errors', function($result) {
    // If a previous authentication check already passed or failed, respect it
    if (true === $result || is_wp_error($result)) {
        return $result;
    }

    // Block unauthenticated requests
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'You are not currently logged in.',
            array('status' => 401)
        );
    }

    return $result;
});

This approach blocks all REST API access for visitors who are not logged in. Gutenberg, WooCommerce, and other plugins continue to work normally because their requests come from authenticated admin sessions. Visitors trying to access /wp-json/wp/v2/users will receive a 401 error instead of user data.

One thing to keep in mind: if your site uses a headless frontend or you have a public-facing feature that fetches data via the REST API (for example, a live search powered by the REST API), this method will break that feature. In those cases, the selective approach below is a better fit.

Selectively Disable Only the Users Endpoint

If you want to keep the REST API accessible for public use but specifically prevent user enumeration, you can remove just the users endpoints:

add_filter('rest_endpoints', function($endpoints) {
    // Remove the users list endpoint
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    // Remove the single user endpoint
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P[\d]+)']);
    }
    return $endpoints;
});

This leaves all other REST API routes functional while specifically blocking the user enumeration vector. It is a good compromise for sites that need public REST API access for search, content queries, or other features but want to protect user data.

Remove the REST API Discovery Link from HTML

WordPress outputs a <link rel="https://api.w.org/"> tag in the HTML head and a Link header in HTTP responses. These tell automated tools where to find the REST API. While removing these tags does not actually disable the API (the endpoints still respond at their usual URLs), it does reduce discoverability:

// Remove the REST API link from the HTML head
remove_action('wp_head', 'rest_output_link_wp_head');

// Remove the REST API link from XML-RPC responses
remove_action('xmlrpc_rpc_methods', 'rest_output_link_wp_head');

// Remove the Link header from HTTP responses
remove_action('template_redirect', 'rest_output_link_header', 11);

This step is best used alongside one of the restriction methods above, not on its own. Removing the link tag without restricting the actual endpoints is security through obscurity, which provides minimal real protection.

Using a Plugin to Manage REST API Access

If you prefer not to add custom code, several plugins provide a user interface for managing REST API access:

• Disable WP REST API: blocks all REST API access for unauthenticated requests with a simple toggle. No configuration needed beyond activating the plugin.
• WP REST API Controller: gives you granular control over which endpoints are public and which require authentication, letting you allow some routes while blocking others.

The plugin approach is simpler to manage but adds a dependency. If the plugin is deactivated or removed during an update, your REST API will be fully public again. The code-based approach is more reliable for long-term protection.

Testing Your REST API Restrictions

After applying your changes, verify they work correctly. Open an incognito browser window (so you are not logged in) and try accessing these URLs on your site:

• https://yoursite.com/wp-json/wp/v2/users
• https://yoursite.com/wp-json/wp/v2/users/1
• https://yoursite.com/wp-json/

If your restriction is working, these should return a 401 error or an empty response instead of user data. Then log in to your WordPress admin and confirm that the Gutenberg editor, your forms, and any WooCommerce functionality still work as expected.

Verify with InspectWP

After implementing your changes, run a new InspectWP scan on your site. The Security section of your report will show whether the REST API is publicly accessible and whether the users endpoint returns data. If the restriction is working correctly, InspectWP will report the API as not accessible or the user endpoint as restricted.