Сигурност на WordPress: мерките, които спират повечето атаки

Повечето пробиви в сайтове на WordPress не са дело на хакер, който е избрал точно вас. Те идват от автоматизирани програми, които обхождат интернет и търсят остарели разширения, слаби пароли и грешни настройки. Добрата новина е, че същите няколко мерки спират повечето такива опити. Тук ги подреждаме по документацията на WordPress и по списъка на OWASP с най-честите рискове.

Какво казва OWASP

OWASP е общност, която от години публикува списък с десетте най-сериозни риска за уеб приложенията. Актуалното издание е OWASP Top 10:2025. За собственика на сайт на WordPress най-близки са четири от рисковете:

• A01 Нарушен контрол на достъпа: потребител вижда или прави неща, които не би трябвало.
• A02 Грешни настройки на сигурността: оставени настройки по подразбиране, излишни функции, видими съобщения за грешки.
• A03 Проблеми във веригата на доставки на софтуер: уязвимост идва от код на трета страна, например разширение или тема.
• A07 Проблеми с удостоверяването: слаби пароли, липса на втори фактор, лесни за отгатване потребителски имена.

Мерките по-долу отговарят точно на тези рискове.

Обновявания и източници на кода

Документацията на WordPress е ясна: старите версии не получават поправки за сигурността. Оставете автоматичните обновявания на ядрото включени (те съществуват от версия 3.7) и включете автоматично обновяване за разширенията и темите, на които вярвате (възможно от версия 5.5). Сваляйте WordPress само от wordpress.org.

Всяко разширение е отделен код, който може да има уязвимост. Изтривайте разширенията и темите, които не ползвате; изключеното разширение остава на сървъра. Проверете и версията на PHP при хостинга: WordPress препоръчва PHP 8.3 или по-нова, а по-старите версии нямат поддръжка и могат да изложат сайта на уязвимости. Повече за обновяванията има в статията за основите на WordPress.

Пароли и вход

• Не използвайте потребителски имена като „admin“ или „webmaster“ за администратора.
• Паролата не трябва да е кратка, само от цифри или само от букви, да съдържа името ви, фирмата, сайта или думи от речника.
• Включете двуфакторно удостоверяване за всички с права на администратор.
• Давайте на всеки потребител само ролята, която му трябва. Пробит администраторски профил позволява инсталиране на зловреден код.
• Входът в административния панел трябва да минава през HTTPS. Вижте SSL сертификатите.

Допълнителна защита е парола на ниво сървър за папката /wp-admin/ (HTTP Basic Authentication), която спира заявките, преди да стигнат до WordPress.

Права на файловете

Документацията препоръчва:

Папките /wp-admin/, /wp-includes/ и /wp-content/plugins/ трябва да могат да се променят само от вашия потребител. Ако хостингът ви е на Apache, можете да забраните достъпа до wp-config.php отвън с блок <Files "wp-config.php"> и Require all denied във файла .htaccess.

Забрана за редакция на код от панела

WordPress има вграден редактор на файловете на темите и разширенията. Ако някой влезе като администратор, това е най-лесният път да добави зловреден код. Изключете го с ред във wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Това премахва правата за редакция на теми, разширения и файлове от всички потребители. Не спира качването на файлове, затова е само една от мерките.

Други настройки

• Префикс на таблиците. При нова инсталация сменете префикса на таблиците в базата от wp_ на нещо друго. Много публикувани атаки с SQL инжекции разчитат на подразбиращия се префикс.
• SFTP вместо FTP. Ако хостингът го предлага, ползвайте SFTP, за да не минава паролата некриптирана.
• Защитна стена. Защитна стена за уеб приложения на сървъра или услуга пред него спира голяма част от автоматизираните атаки.

Резервни копия

Правете редовни копия на базата и на файловете. Документацията на WordPress съветва копията да се криптират или да се пазят независими контролни суми, за да проверите, че не са променени. Пазете и по-стари снимки на сайта, например седмични. Така ще имате копие отпреди пробива, ако той бъде открит със закъснение. Подробности има в статията за резервните копия.

Ако все пак намерите проблем в самия WordPress

Предполагаеми уязвимости в ядрото на WordPress се съобщават по реда, описан във въпросите за сигурността в наръчника на make.wordpress.org, а не в публичните форуми. Ако пробивът засегне лични данни на посетители, може да имате задължение да уведомите КЗЛД; вижте статията за GDPR за собственици на сайтове.