Материал

Что проверить перед запуском веб-приложения: чек-лист для команды

Опубликовано: 28 мая 2026 Время чтения: 9 мин

Одна упущенная точка — и первый пользователь находит дыру раньше вас

Почему чек-лист перед запуском — это не бюрократия

Каждая команда хотя бы раз запускалась с ошибкой, которую было бы легко поймать заранее. Открытый .env файл в корне, CORS настроенный на *, debug-режим в продакшне, таблица без индекса, которая легла под нагрузкой.

По данным Cybersecurity Insiders, в 2025 году больше половины организаций сообщили о взломе или компрометации веб-приложения в течение предыдущих 12 месяцев [1]. По данным Akamai, только в 2024 году было зафиксировано более 311 миллиардов атак на веб-приложения и API — на 33% больше, чем годом ранее [1]. Исследование Mozilla Observatory показало, что более 60% из миллиона наиболее посещаемых сайтов имеют неудовлетворительную оценку конфигурации заголовков безопасности [2].

При этом большинство уязвимостей, которые эксплуатируются в первые дни после запуска, — не нулевые дни. Это забытые настройки, непроверенные зависимости и спешные решения, принятые на финишной прямой.

Хороший pre-launch checklist — это не про то, чтобы замедлить команду. Это про то, чтобы выйти в прод уверенно, а не скрестив пальцы.

Блок 1. Окружение и конфигурация

Это первое, что проверяют атакующие. И первое, что забывает уставшая команда в день деплоя.

Переменные окружения и секреты

Убедитесь, что в продакшн-коде нет хардкода: никаких API-ключей, паролей к базам данных, токенов в исходниках или в истории git. Если ключ хоть раз попал в репозиторий — он скомпрометирован навсегда, даже если его удалили из последнего коммита [3].

Обязательные проверки:

.env файл возвращает 403 или 404, но не 200 с содержимым
.git/ директория недоступна снаружи (тест: yourdomain.com/.git/config)
Файлы резервных копий (.bak, .sql, .tar.gz) не лежат в webroot
Переменные окружения переданы через конфигурацию хостинга, а не захардкожены
Credentials продакшн-окружения отличаются от дев-окружения [4]
Используется менеджер секретов (AWS Secrets Manager, Doppler, HashiCorp Vault) — не просто .env-файл на сервере

Debug-режим и служебные эндпоинты

Debug-режим в продакшне — это подарок атакующему: стек-трейсы, переменные окружения, внутренние пути. Проверьте:

Debug/development-режим выключен
Тестовые роуты, seed-скрипты, phpinfo.php, /info, /debug, /admin удалены или закрыты аутентификацией
Source maps отключены или закрыты от публичного доступа — они раскрывают исходный код приложения в DevTools браузера [4]
Зависимости для разработки (devDependencies) не попали в продакшн-сборку

Конфигурация prod vs dev

Убедитесь, что staging-окружение максимально близко к production. "Работает на моей машине" — это не QA [5].

Блок 2. Безопасность: заголовки и транспорт

По данным исследования, менее 10% веб-приложений имеют все четыре критических заголовка безопасности правильно настроенными, а исправление занимает часы, но защита сохраняется неопределённо долго [2].

HTTP security headers

Настройте обязательный минимум:

Strict-Transport-Security (HSTS) — браузер переходит на HTTPS автоматически. Минимально: max-age=31536000. Осторожно с параметром preload — попав в список HSTS preload, вернуться назад крайне сложно [6].

Content-Security-Policy (CSP) — самый мощный заголовок. Определяет, из каких источников браузер может загружать скрипты, стили, изображения. Блокирует XSS-атаки даже при успешном инжекте вредоносного HTML. Рекомендуется сначала запустить в режиме Content-Security-Policy-Report-Only, отловить все нарушения и только потом включить принудительно [4].

X-Content-Type-Options: nosniff — запрещает браузеру угадывать MIME-тип. Без него браузер может интерпретировать загруженный PNG как JavaScript [6].

X-Frame-Options: SAMEORIGIN — защита от clickjacking.

Referrer-Policy — ограничивает, сколько информации о реферере передаётся при переходах.

Permissions-Policy — ограничивает доступ к браузерным API: камера, микрофон, геолокация, платёжные API.

Проверить заголовки можно через securityheaders.com или Mozilla Observatory.

CORS

CORS, настроенный на *, — одна из самых распространённых уязвимостей [4]. Исследователи bug bounty программ фиксируют CORS-уязвимости в продакшн-приложениях стабильно в 2024–2025 годах [7].

Проверьте:

Access-Control-Allow-Origin не установлен в * для эндпоинтов с аутентификацией
Белый список origins явно перечислен: конкретные домены, а не regex с лазейками
Preflight-запросы (HTTP OPTIONS) валидируются корректно [8]
Access-Control-Allow-Credentials: true не используется вместе с wildcard origin

SSL/TLS

Сертификат действителен, не истёк, выдан на правильный домен и субдомены
Использование TLS 1.2+ (TLS 1.0 и 1.1 устарели)
Автопродление сертификата настроено и протестировано
Redirect с HTTP на HTTPS работает корректно

Блок 3. Аутентификация и авторизация

По версии OWASP Top 10, Broken Access Control — риск №1 уже несколько лет подряд [9].

Аутентификация

Пароли хранятся в bcrypt/Argon2/scrypt, но не в MD5/SHA1/plain text
Реализована политика сложности паролей
Многофакторная аутентификация доступна и протестирована [10]
Brute-force защита: rate limiting на /login, блокировка после N неудачных попыток, CAPTCHA
"Forgot password" флоу не раскрывает, существует ли email в системе
Session ID генерируется случайно, хранится в HttpOnly + Secure cookie, обновляется после логина [11]
Logout полностью инвалидирует сессию на стороне сервера

Авторизация

Вертикальная эскалация привилегий проверена: обычный пользователь не может получить доступ к admin-функциям
Горизонтальная эскалация проверена: пользователь A не видит данные пользователя B
Принцип минимальных привилегий: пользователи базы данных имеют только необходимые права
API эндпоинты закрыты аутентификацией — нет "забытых" открытых роутов

Блок 4. Зависимости и supply chain

Это область, где риски растут быстрее всего. В 2025 году атакующие скомпрометировали популярные GitHub Actions (reviewdog/action-setup, tj-actions/changed-files), что привело к утечке секретов из CI-раннеров тысяч проектов [12]. SolarWinds в 2020 году затронул более 18 тысяч организаций через троянизированное обновление ПО [13].

Аудит зависимостей

Запустите npm audit, pip-audit, bundler-audit или аналог — в зависимости от стека. Одна уязвимая транзитивная зависимость может компрометировать всё приложение [3]. Проверьте:

Прямые и транзитивные зависимости
Lock-файлы зафиксированы в репозитории (package-lock.json, Pipfile.lock, yarn.lock)
Версии зафиксированы, а не используются нефиксированные диапазоны (^ и ~ создают риски)
Нет "package hallucinations" — пакетов с подозрительными именами, которые могли быть предложены AI-инструментом, но не существуют в реестре (или существуют только как вредоносные тёзки)

SBOM и инвентаризация

Software Bill of Materials (SBOM) — это машиночитаемый список всех компонентов приложения. Инструменты: Syft, CycloneDX [14]. Наличие SBOM критично для быстрого реагирования: когда появляется новая уязвимость (как Log4Shell), вы за минуты знаете, затронуты ли вы.

CI/CD пайплайн

Сам пайплайн — тоже часть supply chain:

Используются конкретные хэши для GitHub Actions, а не @latest или @v1
Секреты пайплайна изолированы и не передаются в ненужные джобы
Артефакты сборки подписаны и верифицируются [14]

Блок 5. Валидация и защита от инжекций

Любой ввод от пользователя — потенциально враждебный. Это не паранойя, это основа безопасности [15].

Проверьте:

SQL-запросы используют параметризацию или ORM, но не конкатенацию строк
Пользовательский ввод экранируется перед выводом в HTML (XSS)
CSRF-токены реализованы для всех мутирующих операций (POST, PUT, DELETE, PATCH)
Валидация работает и на клиенте, и на сервере (клиентскую можно обойти)
File upload: ограничены типы файлов, максимальный размер, файлы не сохраняются в webroot
Нет eval(), exec() или аналогов с пользовательскими данными

Блок 6. Производительность и нагрузка

Падение при первом наплыве пользователей — классический сценарий провального запуска. CrowdStrike в 2024 году наглядно показал, что непроверенные обновления под нагрузкой могут вывести из строя 8,5 миллиона устройств [16].

Нагрузочное тестирование

Перед запуском проведите нагрузочное тестирование на staging-окружении, максимально близком к production [5]. Инструменты: k6 (лучшая интеграция с CI/CD), Apache JMeter (широкая поддержка протоколов), Locust (Python-команды) [17].

Что измерять:

Latency p95/p99 — не среднее, а хвост: именно там живёт пользовательский опыт в худшем случае
Throughput plateau — максимальный RPS до начала деградации latency
Error rate под нагрузкой
Корреляция нагрузки с CPU, memory, database connections на сервере [18]

Производительность страниц

Lighthouse / PageSpeed Insights: целевые Core Web Vitals (LCP < 2.5s, FID < 100ms, CLS < 0.1)
Изображения оптимизированы: WebP/AVIF, lazy loading, корректные размеры, alt-атрибуты
Статика отдаётся с правильными Cache-Control заголовками
CDN настроен для статических ресурсов (если применимо)
Database: медленные запросы проверены, нужные индексы расставлены [19]

Database

Миграции применены и проверены в staging
Бэкап перед деплоем сделан и проверен на восстановление — "бэкап существует" и "бэкап восстанавливается" это разные вещи [19]
Connection pool настроен корректно под ожидаемую нагрузку

Блок 7. Мониторинг и логирование

"Деплоиться без мониторинга — как лететь на самолёте с закрытыми глазами" [20]. По данным одного из исследований, 82% приложений не имеют адекватного логирования, а среднее время обнаружения взлома составляло 287 дней [13].

Логирование

Ошибки приложения логируются с достаточным контекстом для расследования
Логи не содержат чувствительных данных: пароли, токены, PAN карт не попадают в логи
Логи агрегируются централизованно (ELK, Loki, Splunk, Datadog Logs)
Структурированный формат (JSON) удобнее grep-ов по тексту

Метрики и алерты

Перед запуском настройте "золотые сигналы" Google SRE [21]:

Latency — время ответа
Traffic — количество запросов
Errors — частота ошибок (особенно 5xx)
Saturation — загрузка ресурсов (CPU, memory, disk, connections)

Алерты должны быть настроены ДО запуска, а не после первого инцидента. Проверьте, что алерт реально срабатывает: сделайте тестовый incident в staging.

Uptime и health checks

Health-эндпоинт (/health, /ping) проверяет зависимости: базу, кэш, внешние сервисы
Uptime monitoring настроен (Pingdom, BetterStack, Grafana Cloud)
Notification channels проверены (Slack, PagerDuty, email) — сообщение реально доходит

Блок 8. Функциональное и кросс-браузерное тестирование

Базовая гигиена, которую откладывают до последнего.

Все критические user flows пройдены вручную или автотестами: регистрация, логин, ключевые бизнес-сценарии, оплата
Кросс-браузерное тестирование: Chrome, Safari, Firefox, Edge — как минимум последние 2 версии
Mobile responsive проверен на реальных устройствах или BrowserStack/Sauce Labs: iOS, Android, разные разрешения
Формы: валидация, обработка ошибок, состояние загрузки, success/error сообщения
Обработка edge cases: пустые состояния, очень длинный текст, специальные символы, большие файлы
404-страница кастомная и помогает пользователю, а не просто показывает "Not Found"
Broken links проверены (Screaming Frog, Ahrefs, команда wget --spider)

Блок 9. SEO и технические метаданные

Уникальные <title> и <meta description> на ключевых страницах
Open Graph теги для корректного превью в мессенджерах и соцсетях
sitemap.xml сгенерирован и доступен
robots.txt настроен: убедитесь, что не запрещён весь сайт (классическая ошибка)
Canonical URLs настроены для избежания дублирования
В продакшне не осталось noindex тегов от staging

Блок 10. Операционная готовность: бэкапы и откат

Даже идеально протестированный деплой может пойти не так. Вопрос не в том, случится ли инцидент, а в том, как быстро вы восстановитесь [22].

Стратегия отката

Перед деплоем у команды должен быть чёткий ответ на вопрос: "Как мы откатываемся за 10 минут?" Варианты:

Blue-green deployment: два идентичных окружения, переключение трафика в одно действие
Canary release: постепенный выкат на % пользователей с автоматическим откатом по метрикам
Kubernetes: kubectl rollout undo откатывает деплой мгновенно
Простой и надёжный вариант: тегированные релизы в реестре образов и документированный rollback playbook

Бэкапы

Бэкап базы данных сделан непосредственно перед деплоем
Восстановление из бэкапа проверено — не только факт наличия файла [19]
Бэкапы хранятся отдельно от production-среды
RTO и RPO определены: за сколько вы готовы восстановиться и сколько данных можете потерять

Типичные ошибки, которые дорого стоят

На практике инциденты при запуске чаще всего вызывает не отсутствие знаний, а спешка и "мы уже проверяли это раньше". Несколько паттернов, которые стоит запомнить:

"Работает на staging — значит, работает в prod." Staging отличается от production данными, конфигурацией, трафиком и зависимостями. Всегда [5]. Тестировали только в dev-окружении — это не QA.

"Добавим мониторинг после запуска." Первые часы после запуска — самые насыщенные с точки зрения инцидентов. Именно в это время мониторинг нужен больше всего.

"Зависимости не менялись." Транзитивные зависимости обновляются при каждом npm install без lock-файла. И даже lock-файл не гарантирует безопасность, если зависимость была скомпрометирована после того, как вы её добавили [12].

"AI написал, значит, проверено." Инструменты AI-кодинга ускоряют разработку, но не автоматически проверяют конфигурации безопасности, корректность CORS, наличие секретов в коде или безопасность зависимостей. Быстро написанный PR — не то же самое, что безопасный PR. Именно здесь инструменты контроля изменений, такие как HighVibe, могут сыграть роль дополнительного слоя проверки: они анализируют конкретные изменения в коде, конфигурациях и зависимостях до merge и релиза, выделяя реальные риски, а не просто генерируя длинный отчёт.

"Откат — это просто." Без предварительного плана откат под давлением инцидента превращается в хаотичный процесс. Механизм отката должен быть описан, протестирован и понятен всей команде ДО деплоя [22].

Чек-лист одной страницей

Для удобства — сокращённая версия для быстрой сверки перед деплоем.

Окружение и секреты:

[ ] Нет секретов в коде и git-истории
[ ] .env и .git/ недоступны снаружи
[ ] Debug-режим выключен, тестовые роуты удалены
[ ] Source maps закрыты

Безопасность:

[ ] HTTPS + HSTS настроен
[ ] CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
[ ] CORS не на *, whitelist явный
[ ] Аутентификация: rate limiting, HttpOnly cookies, logout инвалидирует сессию
[ ] Авторизация: проверена вертикальная и горизонтальная эскалация
[ ] SQL Injection и XSS: параметризованные запросы, экранирование вывода

Зависимости:

[ ] npm audit / pip-audit пройден
[ ] Lock-файлы зафиксированы
[ ] SBOM сгенерирован

Производительность:

[ ] Нагрузочный тест на staging проведён
[ ] Медленные запросы к БД идентифицированы и оптимизированы
[ ] Бэкап БД сделан перед деплоем и проверен на восстановление

Мониторинг:

[ ] Алерты настроены и протестированы
[ ] Centralized logging работает
[ ] Uptime monitoring настроен

Функциональность:

[ ] Критические user flows пройдены
[ ] Mobile + кросс-браузер проверен
[ ] robots.txt не закрывает весь сайт

Откат:

[ ] Rollback-план описан и понятен команде
[ ] Механизм отката протестирован

Заключение

Pre-launch checklist — это не попытка превратить каждый деплой в многодневный аудит. Это система проверок, которую команда прогоняет быстро, потому что большинство пунктов уже решены заранее: автоматизированы в CI, задокументированы, протестированы на staging.

Хороший запуск выглядит так: команда знает, что проверила. Знает, как откатиться. Знает, что смотреть в первые часы. Это не достигается за ночь перед деплоем — это результат встроенного процесса.

Источники

[1] Engineerbabu — "Web Application Security Checklist: 9 Best Practices" — https://engineerbabu.com/blog/web-application-security-checklist/

[2] Agentik OS — "HTTP Security Headers: 2026 Complete Guide" — https://www.agentik-os.com/blog/http-security-headers-complete-guide-2026

[3] Veld Systems — "Web Application Security Checklist for Startups" — https://veldsystems.com/blog/web-app-security-checklist

[4] AI QA Monkey — "Pre-Launch Security Checklist: What to Verify Before Going Live" — https://aiqamonkey.com/blog/pre-launch-security-checklist.php

[5] Cheeeck — "Pre-Launch Website Checklist: 50 Items Every Developer Should Verify" — https://www.cheeeck.com/blog/prelaunch-check

[6] OWASP — "HTTP Headers Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html

[7] Medium / InstaTunnel — "CORS of Confusion: How a Misconfigured Header Can Punch a Hole in Your Security" — https://medium.com/@instatunnel/cors-of-confusion-how-a-misconfigured-header-can-punch-a-hole-in-your-security-6749e8c3f541

[8] OWASP — "Secure Headers Project" — https://owasp.org/www-project-secure-headers/

[9] OWASP — "Web Security Testing Guide (WSTG)" — https://owasp.org/www-project-web-security-testing-guide/

[10] Penetolabs — "OWASP Top 10 Checklist for Securing Modern Web Applications" — https://penetolabs.com/owasp-top-10-checklist-for-securing-modern-web-applications/

[11] GitHub / 0xRadi — "OWASP Web Application Security Testing Checklist" — https://github.com/0xRadi/OWASP-Web-Checklist

[12] Aikido — "Software Supply Chain Security Vulnerabilities" — https://www.aikido.dev/blog/software-supply-chain-security-vulnerabilities

[13] aTeam Soft Solutions — "Web Application Security Checklist 2025: Complete OWASP Top 10 Implementation Guide for CTOs" — https://www.ateamsoftsolutions.com/web-application-security-checklist-2025-complete-owasp-top-10-implementation-guide-for-ctos/

[14] DevSecOps School — "The Ultimate DevSecOps Scanning Checklist for 2025" — https://devsecopsschool.com/blog/the-ultimate-devsecops-scanning-checklist-for-2025/

[15] Vumetric — "Application Security Checklist Before A Launch Or Update" — https://www.vumetric.com/blog/application-security-checklist-before-a-launch-or-update/

[16] Medium / WhatInDev — "Top Software Failures of 2024: Costly Lessons for the Tech Industry" — https://medium.com/javarevisited/the-biggest-software-failures-of-2024-8e9413350f4c

[17] Ranorex — "Load Testing Tools: JMeter, k6, Gatling, Locust Compared" — https://www.ranorex.com/blog/load-testing-tools/

[18] DEV Community — "Best Load Testing Tools for Developers in 2025: k6, JMeter, Locust, and More" — https://dev.to/_d7eb1c1703182e3ce1782/best-load-testing-tools-for-developers-in-2025-k6-jmeter-locust-and-more-4513

[19] Stormatics — "Checklist: Is Your PostgreSQL Deployment Production-Grade?" — https://stormatics.tech/blogs/checklist-is-your-postgresql-deployment-production-grade

[20] Resolution Atlassian — "Your Ultimate 8-Point Deployment Checklist for 2025" — https://www.resolution.de/post/deployment-checklist/

[21] GoReplay — "Production Readiness Checklist: 7 Key Steps for 2025" — https://goreplay.org/blog/production-readiness-checklist/

[22] Mergify — "Your 8-Point Software Deployment Checklist for 2025" — https://articles.mergify.com/software-deployment-checklist/