WordPress REST API: Access, Keys and Rights

The WordPress REST API returns site content as JSON at addresses like /wp-json/wp/v2/posts. It is used by the Gutenberg editor itself, by mobile apps and by external front ends. Here is how to grant access to third-party programs, limit rights and close off unneeded data from outside requests.

Where the REST API lives and how to check it

The base API address is https://site.example/wp-json/. The list of posts comes from /wp-json/wp/v2/posts, pages from /wp-json/wp/v2/pages, users from /wp-json/wp/v2/users. Check that the API is on with one command.

curl -s https://site.example/wp-json/wp/v2/posts | head -c 300

If a 404 page comes back instead of JSON, the pretty permalink rules are broken — open "Settings → Permalinks" and save the form again without changing anything.

How to grant access with an application password

Since version 5.6, WordPress ships with Application Passwords — separate passwords for programs that do not match the admin login password. Create one in the user profile, under "Application Passwords": enter the program name and press the create button. The key is shown once, so save it in a password manager right away.

curl -u "editor:xxxx xxxx xxxx xxxx xxxx xxxx" -X POST https://site.example/wp-json/wp/v2/posts -d "title=Draft post" -d "status=draft"

The spaces inside an application password are part of the format, so do not remove them. If application passwords are hidden in the profile, the site has no HTTPS: WordPress turns this feature off for sites without a TLS certificate.

How to limit role and endpoint rights

By default the REST API follows the same rights as the rest of WordPress: an author sees only their own drafts, a subscriber cannot publish posts. For finer control, use the rest_prepare_post filter together with a capability check through current_user_can.

<?php
add_filter('rest_prepare_post', function ($response, $post, $request) {
    if (!current_user_can('edit_posts')) {
        unset($response->data['content']);
    }
    return $response;
}, 10, 3);

This code removes the full post text from the API response for anyone without edit rights, leaving only the title and excerpt.

How to close the API to anonymous requests

Some sites should not show any data without authentication at all. The rest_authentication_errors filter fits here, blocking a request before it reaches a specific endpoint.

<?php
add_filter('rest_authentication_errors', function ($result) {
    if (!empty($result)) {
        return $result;
    }
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_forbidden',
            'Access is allowed only for authenticated requests',
            array('status' => 401)
        );
    }
    return $result;
});

After this filter, the user list at /wp-json/wp/v2/users — a common target for login-guessing scanners — will no longer be served anonymously. A full set of general protection steps is collected in the article about WordPress security.

Common endpoints and access level

Where the REST API is used in practice

Besides Gutenberg itself, the REST API powers pairing WordPress with an external front end: a React or Vue app fetches content with an application key and renders it separately from the admin panel. A detailed diagram of such a setup is in the article about headless WordPress. Managing application passwords and rights is also convenient from the console — the commands are listed in the material about WP-CLI.

Checklist before opening the API outward

• Application passwords are issued only to the programs that truly need them and are stored in a password manager.
• The user list at /wp-json/wp/v2/users is closed to anonymous requests or returns only display names.
• Fields with sensitive data are stripped from the response by a rest_prepare_post filter for roles without edit rights.
• Drafts and internal posts are unreachable without authentication.
• HTTPS is enabled, otherwise application passwords will not appear in the profile.