WordPress nonce на кэшированных страницах: почему возникает ошибка 403 и как ее исправить

Что такое nonce в WordPress и для чего он нужен

WordPress nonce — это не пароль и не полноценный механизм авторизации. Он помогает убедиться, что запрос поступил из формы или интерфейса, который WordPress считает допустимым, а не был подделан сторонним сайтом.

Nonce обычно создают через `wp_create_nonce()`, а проверяют с помощью `wp_verify_nonce()`, `check_ajax_referer()` или встроенного механизма проверки REST API. Токен связан с пользовательской сессией и временным интервалом. В WordPress nonce обычно действует ограниченный период, который может охватывать текущий или предыдущий временной интервал, поэтому его нельзя считать бессрочным ключом.

Если операция изменяет данные, nonce должен быть только одним из уровней защиты. Сервер также обязан проверять права пользователя через `current_user_can()` или другой подходящий механизм.

• Для AJAX nonce часто передается в POST-параметре или отдельном HTTP-заголовке.
• Для REST API WordPress обычно используется заголовок `X-WP-Nonce`.
• Nonce не заменяет проверку сессии, роли, capability или санитизацию входных данных.

Как кэш страницы ломает nonce

Проблема возникает, когда HTML с nonce сохраняется в page cache, кэше CDN, reverse proxy или кэше плагина оптимизации. Следующий посетитель получает не свежий HTML, сформированный для его запроса, а уже сохраненную копию страницы.

Для авторизованного пользователя это особенно критично: страница может содержать nonce, созданный для другой сессии. Даже если визуально страница одинакова для всех, токен внутри нее может быть персональным.

Устаревший nonce также появляется, когда срок хранения кэша превышает период актуальности токена. В этом случае ошибка возникает не сразу после публикации страницы, а через некоторое время.

Типичный симптом — у администратора или после очистки кэша все работает, а у обычного пользователя форма или AJAX-запрос завершается ошибкой. После повторной загрузки страницы результат может временно измениться, что усложняет диагностику.

• HTML страницы кэшируется вместе со скрытым полем nonce.
• CDN отдает старую копию документа с уже неактуальным токеном.
• Кэш может смешивать публичный HTML и персональные данные.
• Очистка только браузерного кэша не поможет, если старая копия хранится на сервере или CDN.

Как подтвердить, что причина именно в кэшировании

Начните со сравнения поведения страницы при включенном и отключенном кэше. Если после временного обхода page cache запрос начинает работать, это серьезный признак конфликта между кэшем и nonce.

Проверьте HTML-код страницы и найдите название поля или переменную, в которой передается nonce. Затем откройте DevTools браузера, перейдите на вкладку Network и посмотрите, какое значение фактически отправляется в AJAX- или REST-запросе.

Обратите внимание на заголовки ответа HTML. Они могут показать, была ли страница получена из кэша: например, через служебные заголовки CDN или плагина. Конкретные названия зависят от инфраструктуры, поэтому не следует ориентироваться только на один заголовок.

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

• Откройте вкладку Network и проверьте статус AJAX- или REST-запроса.
• Убедитесь, что `X-WP-Nonce` передается именно в REST-запросе.
• Временно очистите page cache, object cache и кэш CDN, если он используется.
• Изучите логи сервера или журнал WordPress, чтобы отличить ошибку nonce от ошибки прав доступа.
• Убедитесь, что сервер не принимает запрос только на основании наличия параметра nonce, а действительно проверяет его.

Самые надежные способы исправления

Выбор решения зависит от того, является ли страница персонализированной и насколько важно кэшировать ее полностью. Не нужно отключать весь кэш сайта из-за одной формы — обычно достаточно разделить публичный контент и динамические операции.

• Не кэшируйте страницы с персонализированными формами, кабинетом пользователя, корзиной, оформлением заказа или другими сессионными данными. Такие страницы лучше исключить из page cache на уровне плагина, сервера и CDN.
• Получайте nonce отдельным некэшируемым AJAX- или REST-запросом после загрузки страницы. В этом случае основной HTML остается быстрым и публичным, а токен запрашивается непосредственно перед операцией.
• Для endpoint, который возвращает nonce или другие персональные данные, используйте соответствующие заголовки, например `Cache-Control: no-store`. Это должно быть настроено на сервере или в коде endpoint, а не только в браузере.
• Разделяйте кэширование по cookie или состоянию авторизации. Авторизованные пользователи не должны получать ту же кэшированную HTML-копию, что и анонимные посетители.
• Для REST-запросов передавайте свежий токен в `X-WP-Nonce`, а не храните его в долго живущем кэшированном HTML.

Пример получения nonce отдельным запросом

Схема ниже показывает общий подход: страница может кэшироваться, а nonce получается после ее загрузки. Реальный URL и формат ответа зависят от вашего endpoint.

fetch('/wp-json/my-plugin/v1/nonce', {
  method: 'GET',
  credentials: 'same-origin',
  cache: 'no-store'
})
  .then(response => response.json())
  .then(data => {
    const nonce = data.nonce;
    // Используйте nonce в следующем запросе.
  });

Передача nonce в REST-запросе

Для стандартной интеграции с WordPress REST API nonce передают в заголовке `X-WP-Nonce`. Сервер в любом случае должен проверить аутентификацию, права доступа и входные данные.

fetch('/wp-json/my-plugin/v1/item', {
  method: 'POST',
  credentials: 'same-origin',
  headers: {
    'Content-Type': 'application/json',
    'X-WP-Nonce': nonce
  },
  body: JSON.stringify({ title: 'Пример' })
});

Проверка серверного кода: nonce не заменяет авторизацию

Даже свежий nonce не означает, что пользователь имеет право выполнять операцию. Обработчик должен отдельно проверять capability, например `edit_posts`, `manage_options` или специальное разрешение, соответствующее конкретному действию.

Для AJAX проверяйте nonce в начале обработчика с помощью соответствующего механизма WordPress. Для REST API возвращайте ошибку, если пользователь не аутентифицирован или не имеет необходимых прав. После этого санитизируйте и валидируйте все входные значения.

Не пытайтесь решить проблему с кэшем, увеличивая срок действия nonce или отключая его проверку. Это может скрыть симптом, но ослабит защиту и не устранит проблему персонализации HTML.

• Nonce проверяет актуальность и происхождение запроса, но не подтверждает наличие необходимой роли.
• Операции изменения, удаления или публикации данных должны проверять capability.
• Ошибки доступа следует логировать так, чтобы не записывать сами токены в открытом виде.
• Не передавайте nonce через URL, если для этого нет четкой необходимости: URL могут попасть в логи, историю и сторонние системы.

if ( ! check_ajax_referer( 'my_action', 'nonce', false ) ) {
    wp_send_json_error( 'Недействительный nonce', 403 );
}

if ( ! current_user_can( 'edit_posts' ) ) {
    wp_send_json_error( 'Недостаточно прав', 403 );
}

// Далее: валидация данных и выполнение операции.

Распространенные ошибки при настройке кэша

Самая частая ошибка — кэшировать всю страницу без анализа ее содержимого. Публичная статья или страница может безопасно кэшироваться, но добавленная на нее форма с nonce делает HTML частично динамическим.

Другая проблема — очищать только один уровень кэша. Старая копия может остаться в плагине, веб-сервере, CDN или браузере. После изменения правил проверяйте все уровни и дождитесь обновления либо принудительно очистите соответствующий кэш.

Не следует вставлять nonce в JavaScript-файл, который имеет длительный срок кэширования. Если скрипт содержит токен, он фактически становится персонализированным ресурсом. Лучше передавать свежие значения через некэшируемый endpoint или локализованные данные с учетом правил кэширования.

Также опасно отдавать страницу с персональными данными по общему публичному URL. В этом случае проблема шире, чем nonce: кэш может показать одному пользователю данные другого.

• Не полагайтесь только на очистку браузерного кэша.
• Не кэшируйте ответы endpoint, который возвращает nonce или данные сессии.
• Не отключайте проверку nonce из-за ошибок 403.
• Не используйте один статичный токен для всех пользователей.
• После изменений протестируйте страницу и как гость, и как авторизованный пользователь.

Практический чек-лист перед запуском

Перед включением полноэкранного кэширования пройдите все сценарии, в которых HTML содержит nonce или другие сессионные данные. Это поможет обнаружить проблему до того, как ее заметят пользователи.

• Составьте список страниц с формами, AJAX-действиями, REST-операциями и личными кабинетами.
• Определите, какие страницы можно кэшировать как публичные, а какие необходимо исключить.
• Проверьте, не попадают ли nonce в кэшированный HTML, JavaScript или ответ CDN.
• Для динамических токенов предусмотрите отдельный endpoint с `Cache-Control: no-store`.
• Проверьте заголовок `X-WP-Nonce` в REST-запросах.
• Убедитесь, что сервер проверяет capability, сессию, nonce и входные данные.
• Протестируйте поведение после завершения срока кэша и после принудительной очистки всех уровней кэширования.