Перейти до змісту

Чекліст безпеки сайту для власника малого бізнесу

Десять пунктів, які можна пройти за один день, і для кожного - спосіб переконатися, що його справді виконано. Знадобляться браузер, доступ до панелі хостингу, а для кількох пунктів - термінал.

Автор: ZNIMOK

Як користуватися чеклістом

Ідіть за списком по черзі: перші пункти закривають найпоширеніші проблеми. Кожен пункт завершується рядком «Як перевірити» - це спосіб упевнитися в результаті, а не лише інструкція з налаштування. Повертайтеся до списку після редизайну, переїзду на інший хостинг або встановлення нового плагіна.

1. Вчасно оновлюйте ПЗ

Старе ПЗ з опублікованими вразливостями - найпростіший шлях усередину невеликого сайту. Ідеться про CMS, плагіни, теми, PHP і сам сервер. Оновлення закривають ці вразливості.

  • Увімкніть автоматичні малі оновлення, якщо CMS їх підтримує. У WordPress фонові автооновлення є з версії 3.7.
  • Невикористані плагіни й теми видаляйте, а не просто вимикайте: їхні файли лишаються на сервері.
  • Тримайтеся підтримуваної гілки PHP. На php.net є таблиця підтримуваних версій з датою, до якої кожна гілка отримує безпекові виправлення.

Як перевірити: на сторінці оновлень в адмінці CMS не має бути жодного невстановленого оновлення, а версія PHP у панелі хостингу має належати до підтримуваної гілки.

2. Увімкніть HTTPS скрізь, потім додайте HSTS

Кожна сторінка має відкриватися через HTTPS із дійсним сертифікатом, а кожна адреса http:// - перенаправляти на https://. Заголовок HSTS після цього каже браузерам на певний час звертатися до вашого домену лише через HTTPS.

Приклад заголовка: Strict-Transport-Security: max-age=31536000; includeSubDomains. Додавайте includeSubDomains лише тоді, коли всі піддомени працюють через HTTPS.

Браузери ігнорують заголовок, якщо він прийшов через звичайний HTTP, а найперший візит лишається незахищеним, доки браузер хоч раз не отримає заголовок. Цю прогалину закриває список HSTS preload, але для нього потрібні max-age щонайменше на рік і includeSubDomains.

Як перевірити: відкрийте http://your-site.example і переконайтеся, що потрапили на https://. Потім виконайте curl -I https://your-site.example і знайдіть рядок Strict-Transport-Security.

3. Не залишайте адмінку відкритою

Сторінки входу в CMS, панель хостингу та інструменти бази даних на кшталт phpMyAdmin чи Adminer - перші адреси, які пробують автоматизовані атаки.

  • Увімкніть двофакторну автентифікацію для кожного облікового запису адміністратора.
  • Не використовуйте логін admin і тримайте кількість адміністраторів мінімальною.
  • Обмежте кількість спроб входу. Доступ до інструментів бази даних і панелі хостингу за можливості дозвольте лише з певних IP-адрес або через VPN.

Як перевірити: з телефона через мобільний інтернет відкрийте сторінку входу в CMS, /phpmyadmin, /adminer.php і адресу панелі. Якщо інструмент бази даних показує форму входу будь-кому, обмежте до нього доступ.

4. Майте резервні копії, які ви вже відновлювали

Від резервних копій залежить, чи обійдеться інцидент годиною роботи, чи тижнем. Зберігайте хоча б одну копію поза акаунтом хостингу, щоб зламаний або закритий акаунт не забрав копії з собою.

Ніколи не зберігайте копії в публічній теці сайту. Файли на кшталт backup.zip чи dump.sql у корені сайту може завантажити кожен, хто вгадає назву.

Як перевірити: раз на квартал відновіть свіжу копію на тестовому сайті й відкрийте його. Потім спробуйте відкрити https://your-site.example/backup.zip - має бути 404 або 403.

5. Захистіть пошту домену

Навіть якщо ви рідко надсилаєте листи, ваш домен можуть підставити в підроблені повідомлення. Опублікуйте SPF, DKIM і політику DMARC; наш розбір DMARC пояснює кожен запис і безпечний порядок дій.

Як перевірити: надішліть собі лист зі свого домену, відкрийте оригінальні заголовки й знайдіть spf=pass, dkim=pass і dmarc=pass.

6. Додайте базові заголовки безпеки

Кілька заголовків відповіді ускладнюють поширені атаки через браузер:

Заголовок Типове значення Що робить
X-Content-Type-Options nosniff Забороняє браузеру вгадувати тип файлу
Content-Security-Policy Почніть із малого, наприклад frame-ancestors 'self' Визначає, звідки можна вантажити скрипти і хто може вбудовувати сторінку
X-Frame-Options DENY або SAMEORIGIN Старіший спосіб заборонити вбудовування (clickjacking)
Referrer-Policy strict-origin-when-cross-origin Обмежує, що ваші адреси розкривають іншим сайтам

Також приберіть номери версій із заголовків Server і X-Powered-By; OWASP радить узагалі не надсилати X-Powered-By. Як перевірити: виконайте curl -I https://your-site.example або подивіться заголовки відповіді в інструментах розробника браузера.

7. Опублікуйте файл security.txt

Файл security.txt (RFC 9116) за адресою /.well-known/security.txt підказує людям, які знайшли проблему на вашому сайті, як із вами звʼязатися. Без нього корисне повідомлення може загубитися в загальній скриньці або не дійти взагалі.

Мінімальний файл складається з двох рядків: Contact: mailto:security@your-domain.example і Expires: 2027-10-01T00:00:00Z. Обидва поля обовʼязкові. RFC 9116 радить ставити дату закінчення менш ніж на рік уперед, тож додайте нагадування в календар, щоб вчасно оновити файл.

Як перевірити: відкрийте в браузері https://your-site.example/.well-known/security.txt.

8. Приберіть залишки

Після розробки й переїздів на сервері лишаються файли: .env, тека .git, phpinfo.php, старі копії конфігурації, логи налагодження, тестові сторінки. Кожен із них може розкрити паролі або налаштування.

Як перевірити: перегляньте файли в корені сайту через файловий менеджер панелі хостингу, зробіть резервну копію і видаліть усе, що ви не можете впізнати як частину робочого сайту.

9. Наглядайте за DNS і доменом

  • Увімкніть автопродовження домену і захистіть акаунт у реєстратора двофакторною автентифікацією.
  • Видаліть записи DNS, що вказують на сервіси, якими ви більше не користуєтеся. Забутий CNAME на видалений хмарний ресурс може дати змогу комусь іншому захопити піддомен.
  • Розгляньте запис CAA: у ньому вказано центри сертифікації, яким дозволено випускати сертифікати для вашого домену.

Як перевірити: вивантажте зону DNS у свого провайдера і пройдіться по кожному запису з питанням «Чи ми ще цим користуємося?».

10. Хоча б мінімально стежте за сайтом

Щодня дивитися на сайт ви не будете, тож доручіть це інструментам: сповіщення про доступність від хостингу або окремого сервісу, сповіщення CMS про входи і зовнішня перевірка після кожної помітної зміни. ZNIMOK не відстежує сайти постійно, тож після змін запускайте перевірку самостійно.

Що підтвердить зовнішня перевірка

Частину пунктів видно ззовні. Безкоштовна перевірка безпеки сайту від ZNIMOK дивиться на перенаправлення з HTTP на HTTPS, сертифікат TLS, HSTS, Content-Security-Policy, захист від вбудовування, X-Content-Type-Options, прапорці файлів cookie, номери версій у заголовках, security.txt, CAA, DNSSEC, висячі CNAME, строк дії домену і записи пошти (SPF, DKIM на поширених селекторах, DMARC, MTA-STS, TLS-RPT). Також вона звіряє версії ПЗ, які показує сайт, із відкритими даними про вразливості й завершення підтримки.

Резервні копії, паролі, двофакторну автентифікацію і все, що за сторінкою входу, зовнішня перевірка не бачить. Ці пункти залишаються за вами. Повний перелік перевірок показує, що ми перевіряємо, а що ні.

Запитання

Як часто проходити цей чекліст?

Повністю - раз чи двічі на рік, а потрібні пункти - після кожного переїзду хостингу, редизайну чи нового плагіна. Для оновлень і резервних копій потрібен окремий регулярний графік.

Чи достатньо зовнішньої перевірки?

Ні. Вона показує те, що бачить будь-хто в інтернеті, і саме звідти починаються автоматизовані атаки. Але всередину сервера чи адмінки вона не зазирає.

Чи замінює чекліст тест на проникнення?

Ні. Тест на проникнення - це ручна спроба зламу з вашого дозволу. Чекліст охоплює базу, яка має бути на місці ще до того, як за такий тест варто платити.

Джерела

  1. RFC 9116: security.txt (англійською) rfc-editor.org
  2. RFC 6797: HTTP Strict Transport Security, англійською rfc-editor.org
  3. MDN: заголовок Strict-Transport-Security (англійською) developer.mozilla.org
  4. OWASP: HTTP Security Response Headers Cheat Sheet cheatsheetseries.owasp.org
  5. Довідник WordPress: Hardening WordPress (англійською) developer.wordpress.org
  6. Довідник WordPress: Brute Force Attacks (англійською) developer.wordpress.org

Подивіться на свій сайт ззовні

Безкоштовний звіт про HTTPS, заголовки, записи пошти і видимі версії ПЗ за кілька хвилин. Без реєстрації.

Перевіряйте лише свої сайти або ті, на які маєте дозвіл. Як працює наш сканер