Как установить ограничения на сохранение данных через REST API в WordPress

WordPress REST API открывает широкие возможности для взаимодействия с сайтом извне, однако иногда требуется ограничить возможность сохранения или изменения данных через API для определённых пользователей или условий. В этой статье мы подробно рассмотрим, как реализовать такие ограничения, используя собственные фильтры, хуки и плагины.

Почему важно ограничивать сохранение данных через REST API

REST API даёт возможность создавать, обновлять и удалять записи, страницы, пользовательские данные и многое другое. Без контроля доступа злоумышленники или некорректные запросы могут повредить содержимое сайта, привести к потере данных или взлому. Поэтому важно:

• Ограничить доступ к сохранению данных только авторизованным пользователям с нужными правами.
• Проверять данные перед сохранением, чтобы избежать ошибок и уязвимостей.
• При необходимости блокировать изменения через API для некоторых типов записей или условий.

Рассмотрим несколько способов реализации.

Ограничение доступа через фильтр rest_pre_insert_ (допустим, для постов)

WordPress предоставляет фильтр rest_pre_insert_<post_type>, который вызывается перед сохранением записи через REST API. С его помощью можно проверить текущего пользователя и данные, и в случае нарушения условий вернуть ошибку.

Пример функции для ограничения сохранения записей типа post только для авторизованных пользователей с ролью редактора и выше:

function wpblog_rest_pre_insert_post(\$prepared_post, \$request, \$creating) {
    if (!current_user_can('edit_others_posts')) {
        return new WP_Error(
            'rest_cannot_edit',
            __('У вас нет прав для сохранения этой записи через API.'),
            array('status' => 403)
        );
    }
    return \$prepared_post;
}
add_filter('rest_pre_insert_post', 'wpblog_rest_pre_insert_post', 10, 3);

В этой функции проверяется, что у пользователя есть возможность редактировать чужие записи, что характерно для роли редактора и выше. Если условие не выполняется, возвращается ошибка с кодом 403 Forbidden — REST API не сохранит запись.

Дополнительные проверки данных

Можно дополнительно проверить содержимое полей, например, длину заголовка или запрещённые слова:

function wpblog_validate_post_content(\$prepared_post, \$request, \$creating) {
    if (strlen(\$prepared_post->post_title) < 5) {
        return new WP_Error(
            'rest_invalid_title',
            __('Заголовок должен быть не короче 5 символов.'),
            array('status' => 422)
        );
    }
    if (stripos(\$prepared_post->post_content, 'запрещённое') !== false) {
        return new WP_Error(
            'rest_invalid_content',
            __('Содержимое содержит запрещённые слова.'),
            array('status' => 422)
        );
    }
    return \$prepared_post;
}
add_filter('rest_pre_insert_post', 'wpblog_validate_post_content', 20, 3);

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

Блокировка обновления определённых типов записей или полей

Если нужно запретить редактирование через REST API какого-то конкретного типа записей (например, page), можно сделать так:

function wpblog_disable_rest_update_pages(\$allowed, \$request, \$post) {
    if ($post->post_type === 'page') {
        return new WP_Error(
            'rest_cannot_edit',
            __('Редактирование страниц через REST API запрещено.'),
            array('status' => 403)
        );
    }
    return \$allowed;
}
add_filter('rest_allow_update', 'wpblog_disable_rest_update_pages', 10, 3);

Этот фильтр rest_allow_update срабатывает при попытке обновить объект через REST API. Если тип записи — страница, функция возвращает ошибку, блокируя обновление.

Ограничение обновления определённых пользовательских полей

Если используется ACF или собственные метаполя, можно проверять и блокировать изменения конкретных полей. Например:

function wpblog_block_custom_field_update(\$prepared_post, \$request, \$creating) {
    $meta = $request->get_param('meta');
    if (isset($meta['secret_key'])) {
        return new WP_Error(
            'rest_cannot_edit_meta',
            __('Изменение поля secret_key через API запрещено.'),
            array('status' => 403)
        );
    }
    return $prepared_post;
}
add_filter('rest_pre_insert_post', 'wpblog_block_custom_field_update', 15, 3);

Так можно защитить важные поля от изменения извне.

Использование плагинов для расширенного контроля доступа к REST API

Если хочется готовое решение с удобным интерфейсом, можно обратить внимание на плагины:

• Clearfy Pro — плагин оптимизации и безопасности, который умеет ограничивать доступ к REST API и настраивать права.
• WPCommunity — плагин для управления сообществом с расширенными настройками прав пользователей, включая REST API.

Эти инструменты облегчат управление правами без необходимости писать код.

Тестирование и отладка ограничений REST API

После добавления кода или настройки плагина важно проверить, что ограничения работают корректно. Для этого можно использовать:

• Инструменты API-запросов, например Postman или curl.
• Плагины типа REST API Console для удобного тестирования прямо из админки.
• Логи ошибок сервера и отладочные плагины, чтобы видеть причины отказов.

Пример запроса с curl для обновления поста (замените URL и токен):

curl -X POST \
  https://example.com/wp-json/wp/v2/posts/123 \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"title": "Новый заголовок"}'

Если ограничения сработали, сервер вернёт ошибку с кодом 403 или 422.

Итоговые рекомендации по безопасности REST API в WordPress

Для безопасной работы с REST API советую:

• Чётко определить, кто и что может менять через API.
• Использовать фильтры rest_pre_insert_<post_type> и rest_allow_update для контроля сохранения и обновления.
• Проверять входящие данные на корректность и запрещённый контент.
• При необходимости использовать готовые плагины, например Clearfy Pro, для управления правами без дополнительного кода.
• Тестировать все изменения тщательно перед запуском на рабочем сайте.