#Что происходит и как определить неисправность
Когда WordPress открывает редактор, но возвращает HTTP 403 именно при сохранении записи, источник блокировки может быть на уровне прав пользователя, защитного модуля веб-сервера, брандмауэра приложений или REST API. Отключать защиту целиком без подтверждения причины нельзя.
#Вероятные причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Срабатывает правило защитного фильтраСрабатывает правило защитного фильтра. В запросе сохранения 403 и совпадающая запись ModSecurity/WAF | В запросе сохранения 403 и совпадающая запись ModSecurity/WAF | Определить правило и исключение только для безопасного запроса. |
| Недостаточно прав/истёк сеансНедостаточно прав/истёк сеанс. В интерфейсе появляется ошибка авторизации, новый вход изменяет поведение | В интерфейсе появляется ошибка авторизации, новый вход изменяет поведение | Сверить роль, права записи и cookies. |
| Плагин безопасности блокирует POST/RESTПлагин безопасности блокирует POST/REST. Сохранение работает при выключенном конкретном правиле на тестовой копии | Сохранение работает при выключенном конкретном правиле на тестовой копии | Изменить точечную настройку плагина, не снижая общую защиту. |
#Пошаговая диагностика и исправление
- Зафиксируйте URL, пользователя и статьюПод учётной записью с разрешением на редактирование откройте Записи → Все записи → Изменить. Попробуйте сохранить короткое изменение в тестовой записи. Запишите время и учётную роль. Если 403 только на одной записи, причиной может быть фильтр по содержимому.
- Найдите заблокированный запрос в браузереВ редакторе нажмите F12 → Сеть, включите сохранение журнала, нажмите «Обновить». Найдите красный POST/PUT-запрос, например к /wp-json/wp/v2/posts/..., и посмотрите HTTP 403 и тело ответа. Не копируйте cookies, nonce и токены в публичный отчёт.
- Проверьте права и повторную авторизациюВыйдите из WordPress, откройте страницу входа с точным HTTPS-доменом, авторизуйтесь снова. В «Пользователи» администратор должен проверить роль, возможность редактировать эту запись и роль её автора. Не повышайте всех редакторов до администраторов.
- Проверьте время и источник 403 на сервереВ панели хостинга откройте журнал ошибок домена/ModSecurity/WAF за момент запроса. Если есть идентификатор правила, запишите его и адрес маршрута. Код 403 от внешнего CDN может не попадать в журнал Apache/Nginx — проверьте журнал соответствующего провайдера.
- Сравните запись без подозрительного содержимогоНа тестовой копии создайте новую запись с одним коротким абзацем и попробуйте сохранить. Если она сохраняется, а проблемная — нет, проверяйте фильтр по HTML, вставленным ссылкам и блокам. Не вырезайте опасное содержимое из публичной статьи, пока не нашли точное правило.
- Временно изолируйте конфликт безопасности на копииЕсли журнал указывает на плагин безопасности или конкретное правило WAF, временно отключите только это правило на тестовом сайте и повторите запрос. Правку в рабочей защите согласуйте с администратором безопасности; обход 403 через отключение ModSecurity для всего домена небезопасен.
- Проверьте REST API и проксиОткройте /wp-json/ на своём домене без секрета, посмотрите HTTP-ответ. Если публичный ответ доступен, это не доказывает, что авторизованный POST проходит: сравните заблокированный запрос, заголовки X-WP-Nonce и правила прокси/кеша.
- Примените адресное исправление и проверьте ролиВерните защиту в штатное состояние и задайте узкое исключение только по обоснованному правилу/маршруту, если оно действительно ложно срабатывает. Сохраните запись от нужной роли и убедитесь, что посторонний пользователь не получил возможность изменения.
#Как проверить результат
Обновление тестовой и нужной записи возвращает корректный ответ, изменения видны на сайте, а запрещённые операции по-прежнему защищены 403.
#Если не помогло
Если 403 сопровождается сообщением rest_cookie_invalid_nonce — проверьте cookies, домен и кеширование страниц админки. Если ответ формирует внешняя защита, ищите там событие блокировки.