“Disable the REST API for security” is advice I hear constantly from clients, usually after reading it on a security checklist somewhere online. Almost every time, I have to walk them back from doing it the way half the internet suggests — because that approach breaks the block editor completely. Here’s what’s actually going on, and what to do instead.

Why you can’t just kill it

The REST API is a way for different pieces of software — your site’s own dashboard included — to ask WordPress for data, like a post’s title or content, and get back a structured answer without loading a full webpage. Gutenberg, the block editor you write posts and pages in, isn’t a separate system bolted onto WordPress. It’s a JavaScript application that talks to your site entirely over this REST API.

Every time you open a post to edit it, the editor is making requests behind the scenes to addresses like /wp-json/wp/v2/posts/123. That happens when you load more blocks, when autosave kicks in, when you insert media, and when you hit publish. The Site Health screen, application passwords, and a good chunk of modern plugin admin screens built as React apps all depend on the same system.

The snippet that gets copy-pasted around the web to “disable the REST API” looks like this:

add_filter( 'rest_authentication_errors', function( $result ) {
    return new WP_Error(
        'rest_disabled',
        'REST API is disabled.',
        array( 'status' => 403 )
    );
});

This rejects every single REST request, no exceptions. The moment you add it, opening the editor gets you a blank screen, an endless “Updating failed” notice, or the classic “The response is not a valid JSON response” error. That’s not a bug in your site — it’s this snippet doing exactly what it says. If you’ve already hit that exact error message, I cover it in more depth in fixing “Updating failed” when the block editor won’t save, since the same error shows up from a few other causes too.

What you actually want

Almost nobody genuinely wants to disable the REST API entirely. What they actually want is to stop anonymous, external access to it — someone scraping your site’s user list or content through /wp-json/ without ever logging in. That’s a completely different, much safer thing to build, and it takes two lines of thinking instead of one blunt filter. It’s the same instinct behind most of the small security-minded lines I add to wp-config.php on every install, covered in the wp-config.php settings I change every time — restrict the specific thing you’re worried about, not the whole system around it.

Option 1: restrict REST access to logged-in users only

This keeps the API fully working for you and anyone logged into wp-admin — exactly who the block editor needs it to work for — while blocking anonymous requests from outside:

add_filter( 'rest_authentication_errors', function( $result ) {
    // If a previous check already returned an error or true, respect it.
    if ( ! empty( $result ) ) {
        return $result;
    }

    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_not_logged_in',
            __( 'The REST API is restricted to logged-in users on this site.', 'my-textdomain' ),
            array( 'status' => 401 )
        );
    }

    return $result;
});

The key difference from the broken version is the is_user_logged_in() check. Anyone using the block editor is, by definition, logged in, so this doesn’t touch their experience at all. It only blocks requests from someone who isn’t authenticated, which covers most of the “REST API scraping” concern people actually have.

One caveat worth testing for: this will also block any legitimate logged-out use of the REST API you might actually want. A headless frontend, a mobile app hitting public endpoints, or a Jetpack integration that relies on public routes could all be affected. Test thoroughly before relying on this in production.

Option 2: block specific routes instead of the whole API

If your actual concern is narrower — say, you don’t want /wp-json/wp/v2/users exposing usernames to anyone who asks — you can remove just that one endpoint and leave everything else untouched, including the routes the editor depends on:

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;
});

This is the more surgical approach, and it’s the one I reach for most often. It removes exactly the exposure you’re worried about without touching anything the editor, plugins, or Site Health rely on.

What to test after making either change

• Open the block editor on an existing post and confirm it loads, autosaves, and lets you publish or update.
• Upload a new media file through the editor.
• Check any plugin with its own admin screen built in React or Vue — WooCommerce reports, page builders, form plugins commonly rely on the REST API too, in much the same way plugins lean on WordPress’s other internal request system, admin-ajax.php, which gets blocked by mistake for similar reasons.
• If you run a headless setup, a mobile app, or a service like Jetpack that depends on public REST endpoints, confirm those still function after scoping your restriction.

Frequently Asked Questions About Disabling the REST API

Why does blocking the REST API break the block editor specifically?

Because the block editor isn’t a traditional page that reloads when you click something — it’s a JavaScript app that fetches and saves your content through the REST API in the background. Block that API entirely, and the editor has no way to load your post’s content or save your changes.

Do I need a developer to make this change safely?

Adding either of the two safer snippets requires editing your theme’s functions.php file or a small custom plugin, which is a code change best handled by a developer if you’re not comfortable doing it yourself. The good news is both snippets are short and well-scoped, so it’s typically a quick job rather than a big one.

Will this break plugins I don’t even know are using the REST API?

It’s possible, which is why the testing checklist above matters. Modern plugin admin screens increasingly use the REST API behind the scenes, so it’s worth clicking through your key plugins’ settings screens after making either change, not just the block editor.

What’s the actual security risk I’m trying to fix here?

Usually it’s anonymous access — bots or scrapers hitting public REST endpoints to pull your list of usernames or content without logging in. That’s a real, narrow concern, and it’s solvable without touching the parts of the API your own site depends on.

How is this different from a security plugin’s “REST API” toggle?

Many security plugins offer a similar option, and under the hood most of them are doing something close to Option 1 or Option 2 above — restricting to logged-in users or hiding specific routes. Check which one before assuming it’s safe; some older plugin versions still ship the blunt, block-everything version.

Should I just leave the REST API alone entirely?

For a lot of sites, yes — the actual exposure is smaller than it sounds, and the block editor needs it working properly. Only make a change here if you have a specific, identified concern, like usernames showing up in an SEO scan or a bot pattern in your logs.

The short version: the REST API isn’t an optional bolt-on you can switch off. It’s load-bearing infrastructure for the editor itself. Scope your restriction to unauthenticated access or to specific routes, not to the whole API surface, and you get the security benefit without losing the tool you write in every day.