Чек-ліст безпеки перед деплоєм вебзастосунку
Кожен вебзастосунок перед виходом у продакшн повинен пройти мінімальну перевірку безпеки. Навіть невеликі прогалини в конфігурації можуть призвести до витоку даних, злому акаунтів або повного компрометування сервера. Нижче — практичний чек-ліст, який допоможе власникам сайтів та розробникам переконатися, що основні вектори атак закриті ще до публічного запуску.
1. HTTPS та SSL/TLS сертифікати
Захищене з'єднання — це фундамент будь-якого сучасного вебсайту. Перед деплоєм обов'язково перевірте наступне:
- Чи правильно налаштований HTTPS на всіх сторінках та піддоменах?
- Чи дійсний SSL/TLS сертифікат і чи правильно він встановлений (відсутність помилок ланцюжка довіри)?
- Чи встановлений заголовок HSTS (HTTP Strict Transport Security) з достатнім значенням
max-age? - Чи вимкнені застарілі протоколи SSLv3, TLS 1.0 та TLS 1.1?
- Чи використовуються лише сильні шифрувальні набори (cipher suites)?
2. Автентифікація та авторизація
Слабка система автентифікації — одна з найпоширеніших причин зламу вебзастосунків. Переконайтеся, що:
- Паролі зберігаються у хешованому вигляді з використанням алгоритмів bcrypt або Argon2 — жодного MD5 чи SHA1 без солі.
- Токени JWT мають розумний термін дії та підписані надійним алгоритмом (наприклад, RS256).
- Реалізований механізм контролю доступу на основі ролей (RBAC) — кожен користувач бачить лише те, що йому дозволено.
- Увімкнена двофакторна автентифікація (2FA) для адміністративних акаунтів.
- Відсутні дефолтні облікові дані (admin/admin, root/root тощо).
3. Валідація та санітизація вхідних даних
Більшість критичних вразливостей — XSS, SQL Injection, Command Injection — виникають через недостатню перевірку даних від користувача. Перевірте:
- Чи виконується валідація всіх вхідних даних на стороні сервера (клієнтська валідація — лише UX, не безпека)?
- Чи застосовуються параметризовані запити або ORM для захисту від SQL Injection?
- Чи екрануються дані перед виведенням у HTML для захисту від XSS-атак?
- Чи налаштований заголовок Content Security Policy (CSP)?
4. Безпека API
Якщо ваш застосунок використовує REST або GraphQL API, це окремий вектор атаки, який потребує уваги:
- Чи вимагають усі ендпоінти API автентифікації та авторизації?
- Чи увімкнений rate limiting для захисту від брутфорсу та DDoS?
- Чи відсутні у відповідях API зайві чутливі дані (надмірне розкриття інформації)?
- Для GraphQL — чи обмежена глибина запитів та вимкнений introspection у продакшні?
5. Заголовки безпеки та конфігурація сервера
- Чи встановлені заголовки X-Frame-Options, X-Content-Type-Options, Referrer-Policy?
- Чи приховані версії серверного ПЗ (nginx, Apache, PHP) у відповідях?
- Чи вимкнений вивід детальних повідомлень про помилки у продакшні?
Цей чек-ліст охоплює лише базові перевірки. Повноцінний пентест включає значно глибший аналіз: тестування бізнес-логіки, перевірку мікросервісної архітектури, аудит інфраструктури та багато іншого. Якщо ви не впевнені в безпеці свого застосунку — замовте професійний пентест у MonMyIP. Наші фахівці проведуть комплексну перевірку вашого вебзастосунку та нададуть детальний звіт із рекомендаціями щодо усунення вразливостей.