REST API WordPress: доступ, ключи и права

REST API WordPress отдает содержимое сайта в формате JSON по адресам вида /wp-json/wp/v2/posts. Его использует сам редактор Gutenberg, мобильные приложения и внешние фронтенды. Разберем, как выдать доступ сторонним программам, ограничить права и закрыть лишние данные от посторонних запросов.

Где находится REST API и как его проверить

Базовый адрес API — https://site.example/wp-json/. Список записей отдает /wp-json/wp/v2/posts, страниц — /wp-json/wp/v2/pages, пользователей — /wp-json/wp/v2/users. Проверить, что API включен, можно одной командой.

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

Если вместо JSON приходит страница 404, значит не работают ЧПУ-правила — зайдите в «Настройки → Постоянные ссылки» и сохраните форму заново, ничего не меняя.

Как выдать доступ через пароль приложения

С версии 5.6 в WordPress встроены Application Passwords — отдельные пароли для программ, не совпадающие с паролем от админки. Создать пароль можно в профиле пользователя, в разделе «Пароли приложений»: введите название программы и нажмите кнопку создания. Ключ показывается один раз, сразу сохраните его в менеджере паролей.

curl -u "editor:xxxx xxxx xxxx xxxx xxxx xxxx" -X POST https://site.example/wp-json/wp/v2/posts -d "title=Черновик статьи" -d "status=draft"

Пробелы внутри пароля приложения — часть формата, их не нужно убирать. Если пароли приложений скрыты в профиле, значит на сайте нет HTTPS: WordPress отключает эту функцию для сайтов без TLS-сертификата.

Как ограничить права ролей и эндпоинтов

По умолчанию REST API следует тем же правам, что и остальной WordPress: автор видит только свои черновики, подписчик не может публиковать записи. Для более тонкой настройки используйте фильтр rest_prepare_post и проверку возможностей через 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);

Такой код убирает полный текст записи из ответа API для всех, кто не имеет права на редактирование, оставляя только заголовок и описание.

Как закрыть API от анонимных запросов

Часть сайтов не должна показывать данные без авторизации вовсе. Для этого подойдет фильтр rest_authentication_errors, который блокирует запрос до того, как он дойдет до конкретного эндпоинта.

<?php
add_filter('rest_authentication_errors', function ($result) {
    if (!empty($result)) {
        return $result;
    }
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_forbidden',
            'Доступ только для авторизованных запросов',
            array('status' => 401)
        );
    }
    return $result;
});

После такого фильтра список пользователей через /wp-json/wp/v2/users — частая цель сканеров для подбора логинов — перестанет отдаваться анонимно. Подробный разбор общих мер защиты собран в статье про безопасность WordPress.

Типичные эндпоинты и уровень доступа

Где применяется REST API на практике

Помимо самого Gutenberg, через REST API работает связка WordPress с внешним фронтендом: React или Vue-приложение забирает контент по ключу приложения и рендерит его отдельно от админки. Подробная схема такой связки описана в статье про headless WordPress. Управлять паролями приложений и правами удобно и из консоли — команды перечислены в материале про WP-CLI.

Чек-лист перед открытием API наружу

• Пароли приложений выданы только тем программам, которым они действительно нужны, и хранятся в менеджере паролей.
• Список пользователей через /wp-json/wp/v2/users закрыт от анонимных запросов или отдает только псевдонимы.
• Поля с чувствительными данными убраны из ответа фильтром rest_prepare_post для ролей без прав на редактирование.
• Черновики и служебные записи недоступны без авторизации.
• HTTPS включен, иначе пароли приложений не появятся в профиле.