Чек-лист безопасности перед деплоем веб-приложения
Каждое веб-приложение перед выходом в продакшн должно пройти минимальную проверку безопасности. Даже небольшие уязвимости, оставленные без внимания, могут привести к утечке данных, компрометации сервера или потере доверия пользователей. Ниже представлен практический чек-лист, который поможет владельцам сайтов и разработчикам убедиться, что основные векторы атак закрыты до публикации проекта.
1. HTTPS и SSL/TLS-сертификаты
Первое, что необходимо проверить — это корректная настройка шифрования соединения. Незащищённый трафик может быть перехвачен злоумышленниками с помощью атак типа Man-in-the-Middle.
- Убедитесь, что HTTPS настроен корректно на всех страницах и ресурсах сайта, включая статические файлы и API-эндпоинты.
- Проверьте, что SSL/TLS-сертификат действителен, правильно установлен и охватывает все используемые домены и поддомены.
- Убедитесь, что используются только современные версии протоколов — TLS 1.2 и TLS 1.3. Устаревшие SSLv3 и TLS 1.0 должны быть отключены.
- Проверьте наличие и корректность заголовка HSTS (HTTP Strict Transport Security) с достаточным значением max-age (не менее 31536000 секунд).
- Убедитесь, что HTTP-запросы автоматически перенаправляются на HTTPS.
2. Аутентификация и авторизация
Слабая система аутентификации — одна из наиболее распространённых причин взлома веб-приложений. Необходимо убедиться, что механизмы проверки личности и управления доступом реализованы правильно.
- Пароли пользователей должны храниться в виде хешей с использованием современных алгоритмов: bcrypt, Argon2 или scrypt. Использование MD5 или SHA-1 недопустимо.
- Если используются JWT-токены, убедитесь, что задан разумный срок их действия (exp), а алгоритм подписи — RS256 или HS256 с надёжным секретом.
- Проверьте, что контроль доступа (RBAC/ABAC) работает корректно: пользователи не должны иметь возможности получить доступ к ресурсам, не предназначенным для их роли.
- Убедитесь в наличии защиты от брутфорс-атак: блокировка аккаунта или CAPTCHA после нескольких неудачных попыток входа.
- Реализуйте многофакторную аутентификацию (MFA) для административных панелей и критически важных разделов.
3. Валидация и обработка входных данных
Недостаточная проверка пользовательского ввода открывает путь к наиболее опасным классам уязвимостей — инъекциям и межсайтовому скриптингу.
- Все входные данные должны валидироваться на стороне сервера, а не только в браузере. Клиентская валидация легко обходится.
- Проверьте устойчивость приложения к атакам типа SQL Injection: используйте параметризованные запросы и ORM вместо конкатенации строк.
- Убедитесь в наличии защиты от XSS (Cross-Site Scripting): экранируйте вывод данных и используйте заголовок Content-Security-Policy (CSP).
- Проверьте устойчивость к CSRF-атакам: все формы и мутирующие запросы должны содержать CSRF-токен.
- Ограничьте размер загружаемых файлов и проверяйте их MIME-тип и расширение на стороне сервера.
4. Безопасность API
Если ваше приложение использует REST или GraphQL API, каждый эндпоинт является потенциальной точкой входа для злоумышленника. API-безопасность требует отдельного внимания.
- Убедитесь, что все API-эндпоинты требуют аутентификации, если они не предназначены для публичного доступа.
- Включите rate limiting для защиты от злоупотреблений и DDoS-атак на уровне приложения.
- Для GraphQL API отключите интроспекцию в продакшн-среде и ограничьте глубину и сложность запросов.
- Проверьте корректность настройки CORS (Cross-Origin Resource Sharing): заголовок Access-Control-Allow-Origin не должен содержать wildcard
*для защищённых ресурсов. - Убедитесь, что API не возвращает избыточные данные (over-fetching) и не раскрывает внутреннюю структуру системы в сообщениях об ошибках.
5. Заголовки безопасности и конфигурация сервера
- Проверьте наличие заголовков: X-Content-Type-Options, X-Frame-Options, Referrer-Policy и Permissions-Policy.
- Убедитесь, что версия сервера и фреймворка не раскрывается в HTTP-заголовках (Server, X-Powered-By).
- Отключите листинг директорий и доступ к служебным файлам (
.env,.git,composer.json). - Проверьте, что режим отладки (debug mode) отключён в продакшн-окружении.
Данный чек-лист охватывает базовые, но критически важные аспекты безопасности веб-приложения. Однако ручная проверка по списку не заменяет полноценного тестирования на проникновение. Профессиональный пентест позволяет выявить скрытые уязвимости, логические ошибки и цепочки атак, которые невозможно обнаружить без специализированных инструментов и опыта.
Не уверены в безопасности вашего проекта? Закажите профессиональный пентест в MonMyIP — мы проводим комплексное тестирование веб-приложений, REST и GraphQL API, аудит SSL/TLS-конфигурации и оценку безопасности всей веб-инфраструктуры. Наши специалисты помогут вам выйти в продакшн с уверенностью в защите вашего сервиса и данных пользователей.