Ако вече сте забелязали скок в заявките за търсене /wp-admin/admin-ajax.php или опити за свързване с xmlrpc.php във вашите дневници вече сте наблюдавали WordPress „под атака“ – дори в малък блог.
Това ръководство има за цел WordPress 6.9.4 (април 2026 г.) и PHP 8.1+. Фокусирам се върху втвърдяването „в рамките на WordPress“ (роли, разрешения, код, плъгини, REST, администратор-ajax, качвания), след това на сървърния слой, което предотвратява най-малката грешка в приложението да се превърне в компромис.
Заплахата
Нападателят не е нужно да „хакне WordPress“ в холивудския смисъл. На практика той използва често срещана слабост: уязвим плъгин, администраторски акаунт, използващ повторно компрометирана парола, изложен вътрешен API или копиран и поставен фрагмент без nonce.
Какво може да направи, ако сайтът ви е уязвим:
- Поемете контрол над акаунт (администратор или редактор) и публикуване на спам съдържание, вмъкване на линкове, промяна на пренасочвания.
- Изпълнете кода чрез уязвимост при качване, десериализация или включване на файл. Това е „най-лошият възможен“ сценарий.
- Кражба на данни (имейли, IP адреси, формуляри) или siphon токени (бисквитки, nonce-и, ако са лошо управлявани).
- Инсталирайте задна вратичка (уебшъл, скрит mu-плъгин, злонамерена cron задача) и се върнете след „почистване“.
- Монетизирайте трафика си SEO спам, условни пренасочвания, инжектиране на скриптове, измамни изскачащи прозорци.
Реалната честота: автоматизираните опити са ежедневни. Дори сайт без трафик получава сканирания. Най-често срещаните вектори остават (1) компрометирани идентификационни данни, (2) остарели плъгини/теми, (3) лоши практики за кодиране (AJAX/REST без разрешения), (4) неправилно конфигуриран сървър (писане навсякъде, липсващи заглавки).
Рискът, казано по-просто: WordPress е силно разширяемо уеб приложение. Всеки плъгин добавя маршрути, формуляри, крайни точки и възможности. Дори един компонент да пропусне стъпка за контрол на достъпа или валидиране, вашият сайт се превръща в най-слабото звено в ботнет мрежата, сканираща интернет.
Бързо обобщение
- По-малка повърхност за атака Деинсталирайте това, което не се използва, ограничете ролите, деактивирайте XML-RPC, ако е ненужно.
- Всяко чувствително действие = еднократно число + възможност (администратор, AJAX, REST). Не едното без другото.
- Изход при излизане, потвърждение при влизане :
sanitize_*на рецепцията,esc_*на показ. - Качени файлове Строги MIME типове, без изпълнение на PHP в
wp-content/uploads. - Подсилете сървъра заглавки, разрешения, деактивиране на редактирането на файлове, ограничения за достъп.
- Гледам WP-CLI, лог файлове, предупреждения и тестван план за възстановяване.
Уязвим код — какво НЕ трябва да правите
Ето един модел, който все още виждам в сайтове от „среден клас“: AJAX крайна точка, актуализираща опция, без проверка на възможностите, с липсващ или неправилно валидиран nonce и невалидирани данни. Това често завършва с дефейс или пренасочвания за SEO спам.
<?php
/**
* Plugin: Exemple vulnérable (NE PAS UTILISER)
* Problème : absence de contrôle de permission, nonce incorrect, validation faible.
*/
add_action('wp_ajax_nopriv_bpcab_save_settings', 'bpcab_save_settings_vulnerable');
add_action('wp_ajax_bpcab_save_settings', 'bpcab_save_settings_vulnerable');
function bpcab_save_settings_vulnerable() {
// Erreur fréquente : "je mets un nonce plus tard" → oublié en production
// Erreur : check_ajax_referer() absent ou mauvais paramètre
// Données non validées
$redirect_url = $_POST['redirect_url'] ?? '';
// Erreur critique : met à jour une option globale accessible à tous
update_option('bpcab_redirect_url', $redirect_url);
wp_send_json_success(array(
'message' => 'OK',
));
}
Как работи атаката (без инструменти):
- Крайната точка е достъпна за посетители (
wp_ajax_nopriv_*). - Няма няма контрол на достъпа Всеки може да извика AJAX действието.
- Стойността се съхранява такава, каквато е. Ако вашата тема или плъгин използва повторно тази опция в
wp_redirect()или линк, нападателят може да инжектира пренасочване към злонамерен сайт.
Често съм виждал този проблем в сайтове, използващи Elementor/Divi: чрез плъгин за snippets се добавя фрагмент „настройки на темата“, след което модул показва бутон „Прочетете още“, който използва същата опция. Само една отровена опция и имате условно пренасочване в целия сайт.
Сигурен код — правилната имплементация
Използваме същата функционалност (запазване на URL адрес за пренасочване), но с очакваните защити в WordPress 6.9.4:
- дадения случай Проверено от страна на сървъра.
- Проверка на възможностите : само администратори (или определена роля) могат да променят опцията.
- Строга валидация Приемаме само вътрешен URL адрес (или бял списък).
- Няма обществен достъп ако не е необходимо.
1) Заявка към скрипт + еднократен номер от страна на администратора
Реалистичен капан: много хора поставят еднократния номер на грешната кука (напр. wp_enqueue_scripts вместо admin_enqueue_scripts), или забравете да изчистите кеша (кеш плъгин + кеш на браузъра) и си мислите, че „нонсът не работи“.
<?php
/**
* Plugin: Exemple sécurisé (WP 6.9.4+, PHP 8.1+)
*/
add_action('admin_enqueue_scripts', function($hook) {
// Chargez uniquement sur votre page d’options pour limiter l’exposition
if ($hook !== 'settings_page_bpcab-security') {
return;
}
wp_enqueue_script(
'bpcab-security-admin',
plugins_url('assets/admin.js', __FILE__),
array(),
'1.0.0',
true
);
wp_localize_script('bpcab-security-admin', 'BPCAB_SECURITY', array(
'ajaxUrl' => admin_url('admin-ajax.php'),
'nonce' => wp_create_nonce('bpcab_save_settings'),
));
});
2) Защитена AJAX крайна точка (само за администратор)
Тук, ние не записва действие noprivАко имате реална нужда от достъп от страна на front-end-а, трябва да компенсирате с различен модел на оторизация (напр. влязъл потребител + специфична функционалност или токен на приложението). По подразбиране избягвайте това.
<?php
add_action('wp_ajax_bpcab_save_settings', 'bpcab_save_settings_secure');
function bpcab_save_settings_secure() {
// 1) Nonce : protège contre les requêtes CSRF depuis un navigateur connecté
check_ajax_referer('bpcab_save_settings', 'nonce');
// 2) Permissions : protège contre les comptes connectés non autorisés
if (!current_user_can('manage_options')) {
wp_send_json_error(array(
'message' => 'Permission refusée.',
), 403);
}
// 3) Validation : on accepte uniquement une URL interne (même domaine)
$redirect_url_raw = isset($_POST['redirect_url']) ? wp_unslash($_POST['redirect_url']) : '';
$redirect_url_raw = trim($redirect_url_raw);
if ($redirect_url_raw === '') {
update_option('bpcab_redirect_url', '');
wp_send_json_success(array('message' => 'Réglage effacé.'));
}
// Autorise uniquement les URLs "locales" : /chemin ou URL du site
$redirect_url = bpcab_validate_internal_url($redirect_url_raw);
if ($redirect_url === null) {
wp_send_json_error(array(
'message' => 'URL invalide. Utilisez une URL interne (même domaine).',
), 400);
}
update_option('bpcab_redirect_url', $redirect_url);
wp_send_json_success(array(
'message' => 'Réglage enregistré.',
));
}
/**
* Valide une URL interne.
* Retourne l’URL normalisée, ou null si refusée.
*/
function bpcab_validate_internal_url(string $value): ?string {
// Autoriser les chemins relatifs
if (str_starts_with($value, '/')) {
// Nettoyage basique : supprime les doubles espaces, etc.
$value = preg_replace('~s+~', '', $value);
return esc_url_raw($value);
}
// Autoriser les URLs absolues du même host
$value = esc_url_raw($value);
if ($value === '') {
return null;
}
$site_host = wp_parse_url(home_url(), PHP_URL_HOST);
$val_host = wp_parse_url($value, PHP_URL_HOST);
if (!$site_host || !$val_host) {
return null;
}
// Comparaison stricte du host (attention aux sous-domaines)
if (strcasecmp($site_host, $val_host) !== 0) {
return null;
}
return $value;
}
Защо работи (по-просто, по-скоро техническо)
Прост: Еднократният номер (nonce) не позволява на сайт на трета страна да задейства действието от ваше име, докато сте влезли в системата. current_user_can() Това предотвратява промяната на глобална настройка от акаунт на „абонат“ или „автор“. Валидирането предотвратява превръщането на вашия сайт в платформа за пренасочване.
Техника: check_ajax_referer() валидира еднократен номер (nonce), свързан с действие. Еднократният номер (nonce) не е абсолютна „криптографска“ тайна, а стандартна CSRF защита в WordPress. Проверката на възможностите разчита на системата за роли/възможности. И накрая, esc_url_raw() + wp_parse_url() намаляване на рисковете от инжектиране на URL адреси и отворени пренасочвания.
Създатели на страници на казус (Divi 5, Elementor, Avada)
Конструкторите на страници не увеличават магически риска, но често насърчават:
- добавяне на фрагменти в плъгин за код, понякога заредени навсякъде;
- създаване на формуляри (Elementor Forms, Divi Contact Form), които извикват уеб кукички;
- опции за показване/мета данни в динамични джаджи.
Практически съвет: Ако разкриете опция „URL“, която ще се използва от бутон на Elementor/Divi, валидирайте я, както е описано по-горе (само за вътрешна употреба), или наложете бял списък с домейни. SEO спам атаките процъфтяват върху непроверени полета за „линк“.
Конфигурация на сървъра
Укрепването на сървъра помага за ограничаване на въздействието, когато плъгинът има грешка. То не замества корекциите, но предотвратява сценария „качване на PHP → изпълнение“.
.htaccess (Apache): Блокиране на изпълнението на PHP при качвания
На Apache с AllowOverrideмясто .htaccess в wp-content/uploads/Ако използвате Nginx, вижте по-долу.
# À déposer dans wp-content/uploads/.htaccess
# Objectif : empêcher l'exécution de PHP dans les fichiers uploadés
<FilesMatch ".(php|phtml|phar)$">
Require all denied
</FilesMatch>
# Réduit les fuites d'infos
Options -IndexesРеалистичен капан: някои доставчици на хостинг услуги деактивират AllowOverrideВ този случай, вашият .htaccess се игнорира. Проверете заглавките/грешките на Apache или попитайте за поддръжка.
Nginx: еквивалент за качвания
Да се адаптира в блока server на вашия vhost. Тествайте конфигурацията преди презареждане.
# Empêche l'exécution de scripts dans uploads
location ~* ^/wp-content/uploads/.*.(php|phtml|phar)$ {
deny all;
return 403;
}
# Optionnel : pas de listing de répertoires
location ^~ /wp-content/uploads/ {
autoindex off;
}wp-config.php: Втвърдяване „в WordPress“
Тези константи са все още актуални в 6.9.4. Активирам ги почти систематично на клиентските сайтове.
<?php
// Désactive l’éditeur de fichiers dans l’admin (évite l’escalade si un admin est compromis)
define('DISALLOW_FILE_EDIT', true);
// Optionnel : interdit l’installation/mise à jour de plugins/thèmes depuis l’admin
// À activer si vous déployez via Git/CI et que vous voulez verrouiller l’admin.
// define('DISALLOW_FILE_MODS', true);
// Force SSL sur l’admin si votre site est en HTTPS (devrait l’être)
// define('FORCE_SSL_ADMIN', true);
// Limite les révisions (réduit la surface en cas d’injection dans le contenu + performance DB)
define('WP_POST_REVISIONS', 20);
// Désactive l’écriture de debug log en production (évite fuite de chemins/tokens)
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);HTTP заглавки (сигурност на браузъра)
Тези заглавки намаляват въздействието на XSS атаките и предотвратяват определени течове. WordPress не ги прилага всички по подразбиране, тъй като зависят от контекста (CDN, iframe-и и др.).
# Apache (.htaccess à la racine)
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header always set X-Frame-Options "SAMEORIGIN"
# CSP : à tester, peut casser des builders (Elementor/Divi) si trop stricte
# Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:;"
</IfModule>Забележка: „Чистият“ CSP често нарушава модулите за изграждане на страници (вградени скриптове, домейни на трети страни). Ако го инсталирате, правете го постепенно (режим Content-Security-Policy-Report-Only първо) и наблюдавайте.
Проверете дали вашият сайт е уязвим
Предпочитам ниско ниво на диагностика (WP-CLI + лог файлове), отколкото плъгин за сканиране, който добавя собствена повърхност за атака. Надеждният скенер си има своето място, но започнете с нещо просто.
WP-CLI: Проверка на версии, потребители и подозрителни плъгини
Изпълнете командата на сървъра (SSH). Запазете файла, преди да предприемете каквото и да е действие.
# Version WordPress
wp core version
# Plugins et mises à jour disponibles
wp plugin list --format=table
wp plugin list --update=available --format=table
# Thèmes
wp theme list --format=table
wp theme list --update=available --format=table
# Comptes admin (attention : ne publiez pas cette sortie)
wp user list --role=administrator --fields=ID,user_login,user_email,display_name,registeredКакво търсите:
- „изоставен“ плъгин (неактуализиран от дълго време) или неизвестен;
- неактивна, но присъстваща тема (безполезна повърхност за атака);
- администратор, който никой не разпознава, или подозрителен външен имейл.
WP-CLI: Идентифициране на mu-плъгини и cron задачи
Задни врати като „дискретни“ места: wp-content/mu-plugins и cron задачи, които повторно инжектират код.
# MU-plugins
wp plugin list --mu --format=table
# Cron (liste complète)
wp cron event list --format=tableSQL: Идентифициране на необичайни опции (инжекции, автоматично зареждане)
Ако имате SQL достъп (или чрез wp db query), търсене на:
- опции
siteurl/homeмодифициран; - огромни опции за автоматично зареждане (често признак на спам/инжектиране и намалява производителността).
# Attention : adaptez le préfixe si besoin
wp db query "SELECT option_name, LENGTH(option_value) AS size, autoload
FROM wp_options
ORDER BY size DESC
LIMIT 20;"Дървени трупи: бетонни сигнали
- Дневници за достъп пориви на вятъра
/wp-login.php,/xmlrpc.php,/wp-admin/admin-ajax.php, неизвестни REST крайни точки. - Регистрационни файлове за грешки : повтарящи се PHP грешки в специфичен плъгин (често свързани с уязвимост), предупреждения за файлове, създадени в
uploads. - Дневници за поща масово изпращане (компрометиран акаунт, отвлечен формуляр).
Диагностична диаграма
| симптом | Вероятна причина | проверка | Решение |
|---|---|---|---|
| Случайни пренасочвания към сайт на трета страна | Отровна опция, JS инжекция, нулиран плъгин | инспектира wp_options (siteurl/home), търсене на скриптове в заглавката/дола, сравняване на файлове с теми |
Заменете с чисти източници, премахнете нулирания плъгин, заключете опциите + валидиране на URL адреси |
| Индексирани са неизвестни страници „казино / фармацевтика“ | Създаване на публикация чрез компрометиран акаунт или REST/AJAX крайна точка | Редактиране на лог файлове, списък с автори, крайни точки, история на публикациите | Анулиране на акаунти/токени, corriger разрешения, почистване на съдържание, заявка за деиндексиране |
| Скок на процесора в admin-ajax.php | Публично AJAX действие, без дроселиране/кеширане | Достъп до лог файлове в admin-ajax, заявки за профили, идентифициране на действия | Изтрий nopriv Ненужно, проверете еднократния номер/възможностите, ограничението на скоростта на ниво сървър/WAF |
| .php файлове в качванията | Уязвимост при качване или произволно писане | търсене find wp-content/uploads -name "*.php" |
Премахване, блокиране на изпълнението на PHP, corriger плъгин, скенер за целостност |
Често срещани грешки в сигурността
| Грешка | малко неприличен | Решение |
|---|---|---|
| Копиране на „AJAX“ код, намерен онлайн, без еднократна грешка | CSRF + неоторизирани модификации | check_ajax_referer() + current_user_can() + стриктно валидиране |
Enregistrer wp_ajax_nopriv_* „за удобство“ |
Публична крайна точка, използваема от ботове | Изтрий nopriv Освен в обосновани случаи, в противен случай удостоверяване + ограничения |
употреба sanitize_text_field() за URL адрес |
Неподходящо валидиране, възможно е отворено пренасочване | esc_url_raw() + контрол на хоста (бял списък) |
Да забравя wp_unslash() от $_POST |
Данните са интерпретирани погрешно, валидациите са заобиколени | Нанесете wp_unslash() преди дезинфекция/валидиране |
| Тестване в производствена среда без резервно копие | Недостъпност, загуба на данни | План за подготовка + архивиране + връщане към предишни етапи |
| Фрагмент е добавен на грешното място (родителска тема, грешен код) | Загуба по време на актуализация, изпълнение твърде рано/твърде късно | Специализиран плъгин или MU-плъгин, адаптирани куки, контролиран приоритет |
| Конфликт в кеша (кеш на страница / кеш на обект) | Еднократно „изтекло“, непоследователно поведение | Изключване на администраторски страници, изчистване на кешовете, избягване на скриване на страници с еднократни стойности |
| Използвайте по-стар урок (преди PHP 8.1 / по-стара версия на WP) | Остарели функции, повторно въведени уязвимости | Проверете официалната документация за WP 6.9+, тествайте на PHP 8.1+ |
| Разрешенията за достъп до файлове са твърде отворени (777) | Писане на задни вратички, невидими модификации | 644/755, правилен собственик, заключено в производство |
Контролен списък за закаляване
- Актуализациите WordPress 6.9.4+, актуални плъгини/теми, премахнете (не само деактивирайте) това, което не е необходимо.
- сметки 2FA, ако е възможно, уникални пароли, премахване на ненужни администратори, ограничаване на редакторите.
- Роли Не предоставяйте администраторски права за публикуване на статия. Създайте отделна роля, ако е необходимо.
- XML-RPC : деактивирайте го, ако не ви е необходим (Jetpack/по-стари мобилни клиенти може да го използват).
- REST API Не блокирайте сляпо „глобално“ (това нарушава работата на Gutenberg и конструкторите), а защитете персонализираните си крайни точки (разрешения + валидиране).
- AJAX не
noprivненужно, nonce + възможност, ограничаване на скоростта от страна на сървъра, ако крайната точка е публична. - Качването блокиране на изпълнението на PHP в
uploadsСтроги MIME типове, без файлов редактор. - WP-config.php :
DISALLOW_FILE_EDIT, уникалните ключове са актуални, отстраняването на грешки е изключено в продукция. - Заглавия :
nosniff,SAMEORIGIN,Referrer-Policy, прогресивен CSP, ако е възможно. - архивиране минимален дневен, възложен на външни изпълнители, месечен тест за възстановяване.
- Мониторинг : известия за влизане, промени във файловете и редовни проверки на crons/mu-plugins.
Ами ако сайтът вече е компрометиран?
Ако подозирате компрометиране, избягвайте импулсивната реакция от рода на „Ще изтрия два файла и това ще свърши работа“. Атакуващите често оставят след себе си постоянни следи (cron, mu-plugin, администраторски потребител, API ключ).
- Изолирайте : поставете сайта в режим на поддръжка (или поне защитете администратора чрез IP/VPN) и спрете кървенето (временно деактивирайте създаването на акаунти, отрежете формулярите, ако е необходимо).
- Запазване на текущото състояние Направете копие на файловете и дъмп на базата данни. Avant Почистване. Използва се за анализ и понякога за доказване на инцидента.
- Променете тайните :
- Пароли за WordPress (всички администратори),
- Пароли за FTP/SSH/хостинг,
- пароли за бази данни,
- Ключови думи
AUTH_KEY/SECURE_AUTH_KEY… Вwp-config.php(принуждава прекъсване на сесиите).
- Идентифицирайте входната точка :
- Нулев или остарял плъгин/тема
- неизвестен администраторски акаунт,
- уязвимост при качване,
- персонализирана AJAX/REST крайна точка без разрешение.
- Заменете с чисти източници :
- Преинсталирайте ядрото на WordPress от официален източник (не го „чистете“ ръчно).
- Преинсталирайте плъгини/теми от wordpress.org или редактора.
- изтрийте всички неизвестни файлове, особено в
wp-content/uploads,mu-plugins,wp-includes.
- Почистете основата :
- Премахнете подозрителни потребители,
- инспектирам
wp_options(siteurl/начало, опции за кеширане, инжекции), - търсене на инжектирано съдържание (скриптове, iframe-ове) в публикации/уиджети.
- Проверете за постоянство :
wp cron event list(странни задачи),- MU-плъгини,
- системни задачи (сървърен crontab), ако имате достъп.
- Актуализирайте и втвърдете Приложете контролния списък, добавете правилата за качвания/заглавки, премахнете публичните крайни точки.
- Контрол на SEO Проверка на Google Search Console (индексирани страници, ръчни действия), почистване на Sitemap файлове, коригиране на пренасочвания.
- Документ Дата, вектор, корекции. Тази стъпка предотвратява повторението на инцидента 3 месеца по-късно.
Практическа бележка: Ако сте на споделен хостинг и съседните сайтове са компрометирани, можете да почиствате за неопределено време. В този случай мигрирайте към изолирана среда (контейнер, виртуална машина, управляван хостинг), преди да отворите отново.
Съвети за поддръжка и съвместимост
Разгръщайте като разработчик, а не като магьосник. На междинни сайтове уязвимостта често произтича от малък фрагмент, добавен набързо и след това забравен. Поставете персонализациите си в специален, версиониран плъгин (или MU-плъгин), вместо в родителската тема или в 12 разпръснати фрагмента.
Съвместимост с Divi 5 / Elementor / Avada: Избягвайте да блокирате REST API глобално. Gutenberg и много други конструктори разчитат на него. Вместо това използвайте:
- защитете вашите персонализирани крайни точки (строги разрешения за обратно извикване),
- деактивирайте само ненужното (XML-RPC, публични AJAX действия),
- Тествайте заглавките си (CSP) в тестова среда с вашите шаблони.
Производителността и безопасността се съчетават: Бавен уебсайт е по-труден за наблюдение (огромни лог файлове, времеви ограничения), а неограничена публична крайна точка може да се превърне в DoS атака за приложение. Ако имате публична крайна точка, внедрете кеширане, ограничаване на скоростта (WAF/CDN) и логика от страна на сървъра, която бързо отхвърля заявките.
Реалистични грешки, които трябва да се избягват при извършване на промени:
- копирайте кода в
functions.phpна родителската тема (загубена по време на актуализацията); - Забравянето на точка и запетая може да наруши работата на целия сайт (направете допълненията си при подготовката за публикуване);
- твърде ранно използване на hook (напр. извикване на
current_user_can()преди потребителят да бъде зареден); - не генерирайте постоянни връзки след промени в маршрута;
- Не изчиствайте кеша след промяна на nonce/скриптове.
ресурси
- Ресурси за разработчици на WordPress — Сигурност на плъгините
- Nonces (документация за разработчици)
- Препратка: current_user_can()
- Референция: check_ajax_referer()
- Препратка: esc_url_raw()
- WordPress.org — Втвърдяване на WordPress
- Изходен код на WordPress (огледало на GitHub)
- WordPress Core Trac (билети и промени)
- PHP Ръководство — Сигурност
Често задавани въпроси
Трябва ли XML-RPC да бъде деактивиран през 2026 г.?
Ако не използвате Jetpack, по-старо мобилно приложение или услуга, която разчита на него, тогава да. XML-RPC има дълга история на груба сила атаки и злоупотреби. Ако имате нужда от него, защитете го (WAF/ограничение на скоростта) и наблюдавайте лог файловете.
Достатъчно ли е „скриването на wp-login.php“?
Не. Намалява малко шума, но не поправя уязвимости в приложенията, слаби плъгини или компрометирани идентификационни данни. Приемайте го като мярка за удобство, а не като стратегия.
Само еднократно действие = безопасно?
Не. Nonce-ът основно предпазва от CSRF. Той не замества проверката за разрешения. Очакваната двойка е: еднократен номер + възможност.
Защо да избягвате wp_ajax_nopriv?
Защото създавате публична крайна точка. Ако тя извършва скъпоструваща операция (заявки, генериране на PDF файлове, изпращане на имейли) или чувствителна такава (запис в база данни), тя ще бъде сканирана и използвана неправилно. Ако трябва да направите това, добавете строга проверка, ограничения и в идеалния случай механизъм за удостоверяване.
Искам да блокирам REST API от съображения за „сигурност“. Добра идея ли е?
Рядко. Ще счупите Gutenberg, а понякога и Divi/Elementor/Avada, в зависимост от модулите. Вместо това, защитете персонализираните си крайни точки и ограничете излагането на данни (не публикувайте ненужна информация).
Къде е най-доброто място за поставяне на код за втвърдяване?
Специализиран, версиониран плъгин (или MU-плъгин). Избягвайте functions.php на родителската тема. В сайтове с конструктори това е класика: темата се променя и втвърдяването изчезва.
Кои файлове трябва да бъдат незаписваеми в производствения режим?
В идеалния случай, всичко друго, но не и wp-content/uploads (и понякога wp-content/cache (в зависимост от вашия стек). Колкото повече намалявате писането, толкова повече блокирате задните врати.
Как можете да разберете дали даден плъгин е „нулиран“ или подозрителен?
Предупредителни знаци: източникът не е официално разпознат, невъзможност за актуализиране, обфускирани файлове, необичайни външни повиквания, наличие на кодиран код. В случай на съмнение, заменете с официален източник.
Струва ли си CSP с Elementor/Divi?
Да, но постепенно. Започнете от Само отчетНаблюдавайте какво се поврежда и след това го поправете. Твърде стриктният CSP може да повреди вградените скриптове, които някои модули използват.
Ами ако кешът ми прекъсне еднократните стойности (грешки „Сигурни ли сте, че искате да направите това?“)?
Изключете администраторските страници и всички front-end страници, съдържащи nonce формуляри, от кеша на страниците. Изчистете кеша след внедряването. В някои стекове кешът на обектите може също да задържа фрагменти твърде дълго: тествайте, като го деактивирате временно, за да изолирате проблема.
Колко често трябва да тествам възстановяване?
Поне веднъж месечно и след всяка голяма промяна (миграция, нов конструктор, редизайн). Непровереното резервно копие е хипотеза, а не предпазна мрежа.