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

Что проверить до релиза, чтобы не оказаться в breach-отчёте

Почему это важно стартапу прямо сейчас

Стартап — идеальная мишень. Не потому что он маленький и «нечего красть», а потому что у него обычно мало ресурсов на безопасность, высокий темп разработки и низкий порог для доступа к инфраструктуре со стороны подрядчиков, инвесторов и первых сотрудников.

Взлом на ранней стадии убивает несоразмерно: один инцидент с утечкой данных клиентов уничтожает доверие, которое ещё не успело сформироваться, и создаёт юридические риски — особенно в контексте GDPR, 152-ФЗ и требований корпоративных заказчиков. По данным Verizon DBIR 2025, анализировавшего более 22 000 инцидентов, базовые атаки на веб-приложения — одна из четырёх доминирующих схем, и 88% из них начинались с украденных учётных данных [1].

OWASP обновил свой Top 10 в ноябре 2025 — впервые за четыре года [2]. Данные собирались из более чем 500 000 приложений и 175 000 CVE-записей. Новая редакция точнее отражает текущую угрозу: не изолированные баги в коде, а системные слабости на протяжении всего цикла разработки и доставки.

Ниже — структурированный базовый чеклист для команды, которая строит продукт и хочет не ошибиться в фундаменте.

Слой 1. Транспорт и HTTP-заголовки

Это самый быстрый способ получить ощутимый прирост безопасности с минимальными усилиями.

HTTPS везде

TLS 1.2 и 1.3 — единственные допустимые версии протокола. SSLv3 и TLS ниже 1.2 необходимо явно отключить [3]. Получить бесплатный сертификат через Let's Encrypt не составляет труда, а отсутствие HTTPS в 2025 году — это не только риск перехвата трафика, но и прямой удар по SEO и доверию пользователей.

Чеклист:

1. TLS 1.2/1.3 включён, SSL/TLS < 1.2 отключён.
2. Все HTTP-запросы редиректятся на HTTPS.
3. Сертификат актуален, автоматическое обновление настроено.
4. На CDN/реверс-прокси HTTPS работает end-to-end, а не только до edge.

HTTP Security Headers

Несколько правильно настроенных заголовков снижают поверхность атаки для XSS, clickjacking и protocol downgrade. Реализуются за день [4].

1. Strict-Transport-Security (HSTS) — браузер всегда использует HTTPS для домена. Включать только после того, как весь домен работает на HTTPS, иначе сайт ломается. Рекомендуемый max-age — 31536000 с флагом includeSubDomains.
2. Content-Security-Policy (CSP) — белый список источников скриптов, стилей, изображений. Самый мощный заголовок: ограничивает большинство XSS-атак. Начинать в режиме report-only, собирать нарушения, потом переводить в режим enforce.
3. X-Content-Type-Options: nosniff — запрещает браузеру угадывать MIME-тип ресурса, предотвращает атаки через подмену типа.
4. Referrer-Policy — контролирует, сколько информации о URL передаётся сторонним сервисам.
5. X-Frame-Options или frame-ancestors в CSP — защита от clickjacking.

Инструмент быстрой проверки: securityheaders.com.

CORS: не открывать шире, чем нужно

Wildcard Access-Control-Allow-Origin: * в сочетании с Access-Control-Allow-Credentials: true — одна из самых распространённых конфигурационных ошибок в API. По различным оценкам, порядка 40% веб-приложений имеют небезопасные настройки CORS [5]. Атакующий, эксплуатирующий такую конфигурацию, может от имени аутентифицированного пользователя читать данные и выполнять действия через вредоносный сайт.

Чеклист по CORS:

1. Origin-лист явно определён и не включает * при использовании credentials.
2. Нет динамического отражения Origin-заголовка без валидации.
3. Разрешены только необходимые HTTP-методы.
4. CORS-конфиги отличаются для dev, staging и production.

Слой 2. Аутентификация и управление сессиями

A01:2025 — Broken Access Control и A07:2025 — Identification and Authentication Failures стабильно занимают высокие позиции в OWASP уже несколько итераций [2]. Причина — учётные данные остаются самым удобным входом для атакующего.

Пароли и MFA

Слабая или вовсе отсутствующая MFA — прямая дорога к компрометации. В январе 2025 одна украденная пара логин/пароль без MFA открыла доступ к 60 миллионам записей о студентах в инциденте с PowerSchool [1]. В том же DBIR 2025 зафиксирован рост методов обхода MFA: токен-кражи, prompt bombing и атаки через infostealer-малварь.

Чеклист:

1. MFA обязательна для всех административных и привилегированных аккаунтов.
2. Пароли проверяются по базам скомпрометированных учётных данных (Have I Been Pwned API).
3. Используется bcrypt, Argon2 или scrypt для хранения паролей — не MD5 и не SHA-1.
4. Ограничено число попыток входа (rate limiting, lockout после N неуспешных попыток).
5. Сессионные токены имеют короткий TTL, инвалидируются при выходе и смене пароля.
6. В SPA — PKCE при OAuth-флоу, без хранения client_secret в клиентском коде [6].

Управление сессиями

1. Cookie: флаги HttpOnly, Secure, SameSite=Strict или Lax.
2. CSRF-токены для state-changing операций.
3. Сессия инвалидируется на сервере при logout — не только на клиенте.
4. Refresh token хранится в HttpOnly-куке, не в localStorage.

Слой 3. Секреты и конфигурации

Это наиболее недооценённый риск в стартап-командах, и он прямо коррелирует с темпом разработки с AI-ассистентами.

Масштаб проблемы

GitGuardian в своём State of Secrets Sprawl 2025 зафиксировал почти 24 миллиона новых захардкоженных секретов в публичных репозиториях GitHub за 2024 год — рост на 25% год к году [7]. Репозитории с использованием GitHub Copilot показали утечку секретов на 40% чаще обычных. Самое тревожное: 70% секретов, утёкших в 2022 году, оставались валидными к началу 2025-го — их никто не ротировал [7].

В 2025 году цифра ещё выросла: GitGuardian зафиксировал уже 29 миллионов новых захардкоженных секретов — крупнейший прирост за всё время наблюдений [8]. При этом внутренние репозитории в 6 раз чаще публичных содержат секреты.

Это означает: чем быстрее команда пишет код с AI-помощниками, тем важнее автоматический контроль секретов до merge.

Чеклист по секретам

1. Никаких секретов в коде, env-файлах в репозитории, в Slack, Confluence или комментариях к PR.
2. Секреты хранятся в vault: AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault или Infisical.
3. Pre-commit хуки (git-secrets, detect-secrets, gitleaks) проверяют коммиты до их попадания в историю.
4. CI/CD pipeline сканирует репозиторий на наличие секретов автоматически.
5. Ротация секретов: регулярная и немедленная при любом подозрении на компрометацию.
6. Для каждой среды (dev, staging, production) — разные секреты.
7. .gitignore содержит .env, .pem, _key, credentials.json и аналоги.

Security Misconfiguration — A02:2025

Это новый второй номер в OWASP Top 10 2025, поднявшийся с пятой позиции [2]. Под мискonfiguration попадает широкий класс проблем:

1. Debug-режим включён в production.
2. Открытые S3-бакеты или storage с публичным доступом.
3. Дефолтные учётные данные у баз данных, Redis, Elasticsearch.
4. Лишние открытые порты и сервисы.
5. Слишком широкие права IAM/RBAC-ролей (нарушение принципа наименьших привилегий).
6. Детальные stack trace'ы в ответах API.
7. Отладочные эндпоинты (/debug, /actuator, /metrics) доступны снаружи.

Слой 4. Зависимости и supply chain

A03:2025 — Software Supply Chain Failures — новая категория в OWASP Top 10, дебютировавшая сразу на третьем месте [9]. OWASP впервые явно называет атаки на цепочку поставок, malicious packages, compro-мised maintainers и tampered build processes в числе ведущих угроз.

Почему зависимости — слепая зона

Согласно отчёту Black Duck OSSRA 2025, 70% open source зависимостей в среднем коммерческом приложении являются транзитивными — то есть их подтянули другие зависимости, а не разработчик явно [10]. Это значит, что команда часто не знает, что именно запускается в production.

SCA и SBOM

Software Composition Analysis (SCA) — автоматическое сканирование зависимостей на известные уязвимости. Базовые инструменты доступны бесплатно: Trivy, Syft (генерация SBOM), OWASP Dependency-Check, GitHub Dependency Graph [11].

Software Bill of Materials (SBOM) — машиночитаемый список всех компонентов приложения. Два стандарта: CycloneDX (проект OWASP, фокус на безопасности) и SPDX (Linux Foundation, фокус на лицензиях) [11]. SBOM переходит из разряда «хорошо иметь» в обязательное требование корпоративных заказчиков.

Чеклист:

1. SCA-сканирование запускается в CI на каждый PR и на каждый релиз.
2. Lock-файлы (package-lock.json, yarn.lock, poetry.lock, go.sum) зафиксированы в репозитории и не обновляются случайно.
3. Зависимости обновляются по расписанию с проверкой на CVE, а не только «когда сломалось».
4. SBOM генерируется автоматически при каждом production build.
5. Настроены алерты на критические CVE в используемых компонентах (через Dependabot, Renovate, Snyk).
6. Проверяется не только наличие уязвимости, но и достижимость (reachability) — реально ли уязвимый код вызывается.
7. Источники пакетов зафиксированы — нет подмены приватных пакетов публичными (dependency confusion).

Слой 5. Входные данные, инъекции и обработка ошибок

A05:2025 — Injection (SQL, OS, LDAP, XSS) и A10:2025 — Mishandling of Exceptional Conditions [2].

Injection

SQL injection остаётся первой по частоте уязвимостью в веб-приложениях, согласно Edgescan Vulnerability Statistics Report 2025: она занимает это место с 2022 года [12]. Несмотря на то что решение известно и стандартно, команды продолжают его не применять под давлением сроков.

Чеклист:

1. Параметризованные запросы или ORM — без конкатенации пользовательского ввода в SQL-строки.
2. Валидация входных данных на сервере — whitelist, а не blacklist.
3. Sanitization HTML-вывода для предотвращения XSS (например, DOMPurify на клиенте, escaping на сервере).
4. Файловые загрузки: проверка типа по сигнатуре (magic bytes), а не только по расширению; хранение вне webroot.
5. Ограничение размера запросов и тела (body size limit).

Обработка ошибок — A10:2025

Новая категория в OWASP 2025 консолидирует 24 CWE, связанных с некорректной обработкой исключений: fail-open логика, утечка stack trace, NULL dereference crash, CWE-209 (error messages с секретами) [2]. По опросу сообщества OWASP, 50% респондентов назвали эту категорию главной emerging concern.

Чеклист:

1. В production-ответах нет stack trace, внутренних путей к файлам, версий фреймворков.
2. Приложение при ошибке «закрывается», а не «открывается» (fail closed, deny by default).
3. Ошибки логируются внутри, а пользователю возвращается нейтральный generic-ответ.
4. Тайм-ауты и resource limits настроены — приложение корректно обрабатывает ситуации нехватки ресурсов.

Слой 6. Логирование, мониторинг и реагирование

A09:2025 — Security Logging & Alerting Failures сохраняет свою позицию. OWASP переименовал категорию, добавив слово «Alerting» — потому что «отличный logging без alerting имеет минимальную ценность для выявления инцидентов» [13].

Классический пример из OWASP: утечка данных о 3,5 миллиона детских медицинских записей оставалась незамеченной более семи лет — из-за отсутствия мониторинга [13].

Что логировать

1. Все попытки аутентификации: успешные и неуспешные, включая попытки с нестандартных IP.
2. Все действия с привилегированными аккаунтами и изменения прав доступа.
3. Все высокочувствительные транзакции (платежи, смена email/пароля, экспорт данных).
4. HTTP 4xx и 5xx ошибки в агрегированном виде.
5. Нетипичное поведение: скачки в частоте запросов, обращения к несуществующим эндпоинтам.

Что не класть в логи

1. Пароли и их части.
2. Полные номера карт, токены, API-ключи.
3. Персональные данные, которые не нужны для диагностики.

Alerting и IR

1. Алерты настроены на: множественные неуспешные попытки входа, необычную географию, нетипичный объём API-запросов.
2. Есть хотя бы минимальный incident response playbook: кто принимает решение, кто отключает, кто уведомляет.
3. Логи хранятся централизованно и защищены от модификации (immutable logging).
4. Время обнаружения инцидента измеряется и планируется к улучшению.

Инструменты для стартапа: Datadog, Grafana + Loki, AWS CloudWatch, Sentry (для application errors). Главное — настроить алерты, а не просто собирать данные.

Типичные ошибки и как их не допустить

Перечислим самые распространённые паттерны, по которым стартапы попадают в breach-отчёты.

1. «Мы маленькие, нас не взломают». Автоматизированные боты сканируют весь интернет непрерывно — они не выбирают цели по размеру. Атакуют не компании, а уязвимые эндпоинты.

1. «Закроем позже, сейчас нужно быстро выпустить». Security debt накапливается экспоненциально. По данным OWASP и опыту AppSec-команд, встроить безопасность в архитектуру с нуля значительно дешевле, чем retrofit-patch уже работающую систему [6].

1. «У нас нет секретов в коде, мы внимательно смотрим на PR». Смотрят не до конца. AI-ассистенты ускоряют написание кода, но не автоматически исключают хардкоженные значения. Данные GitGuardian прямо подтверждают корреляцию между использованием Copilot и ростом числа утечек секретов [7]. Дифы дочитывают не до конца — это факт, а не упрёк.

1. «Мы используем npm/pip — там всё проверено». Transitive dependencies никто не проверял за вас. Supply chain attacks начинаются не с вашего кода, а с чужого пакета, которому доверяет ваш пакет [9].

1. «Debug-режим выключен в production». Проверили ли вы это для всех сервисов, включая внутренние admin-панели и internal tools?

1. «Мы обновимся, когда появится критическая CVE». К моменту публичного CVE у атакующих уже есть эксплойт. Регулярное обновление зависимостей по расписанию — это управление риском, а не перфекционизм.

Кейс: что происходит без базовой гигиены

В январе 2025 года в инциденте с PowerSchool один подрядчик без MFA открыл злоумышленнику доступ к 60 миллионам записей студентов [1]. В 2025 году компания Samsung Germany обнаружила, что учётные данные подрядчика, украденные ещё в 2021 году инфостилером, не ротировались четыре года — итог: утечка 270 тысяч записей [1].

Это не истории об изощрённых атаках. Это истории о непримените базового: MFA и ротации секретов.

Контроль перед merge и релизом: где реально возникает риск

Стартапы часто внедряют инструменты безопасности, но не встраивают проверки в момент принятия решения. Инструмент, который сканирует раз в неделю, не поможет, если уязвимая зависимость приедет в production в пятничный deploy.

Критические точки контроля:

1. До merge PR: SAST-проверка кода, поиск секретов в диффе, проверка изменений в зависимостях и lock-файлах.
2. В CI/CD pipeline: SCA на зависимости, проверка конфигов, SBOM-генерация.
3. Перед релизом: быстрый ответ на вопрос «что блокирует этот выпуск» — не длинный отчёт на 200 пунктов, а конкретный сигнал по критичным находкам.

Именно здесь инструменты вроде HighVibe закрывают реальный gap: не тотальное сканирование всего репозитория, а анализ конкретного изменения и связанного контекста — нового кода, конфигов, зависимостей и релизного контекста. Команда получает короткий ответ: можно безопасно принять это изменение или нет, с объяснением и следующим шагом. Это дополнительный слой контроля рядом с SAST/SCA/CI — не замена им.

Приоритизация: с чего начать, если ресурсов мало

Если бюджет времени ограничен, вот порядок по соотношению усилий и снижаемого риска:

1. Секреты в коде — сканирование и pre-commit хуки. Бесплатно, за день.
2. MFA для всех привилегированных аккаунтов. Бесплатно, за несколько часов.
3. HTTPS + базовые security headers (HSTS, X-Content-Type-Options, X-Frame-Options). Бесплатно, за день.
4. Зависимости: включить Dependabot/Renovate, настроить автоматические CVE-алерты.
5. Параметризованные запросы вместо конкатенации. Технический рефактор.
6. Настроить централизованный сбор логов и базовые алерты на брутфорс и аномалии.
7. CORS: ревью всех API-эндпоинтов, убрать wildcard там где есть credentials.
8. SCA в CI, SBOM-генерация на каждый build.
9. CSP в режиме report-only, итеративное ужесточение.
10. Threat modeling для ключевых сценариев работы приложения.

Инструменты для стартапа: опенсорс и freemium

Перечислим конкретные инструменты с доступным бесплатным уровнем:

1. Semgrep — SAST, 4000+ правил, интеграция в CI/CD, OWASP Top 10 mapping.
2. Trivy (Aqua) — SBOM-генерация + уязвимости в контейнерах и зависимостях.
3. Syft (Anchore) — генерация SBOM из container images и исходников.
4. OWASP Dependency-Check — SCA для Java, .NET, Python, Node.
5. gitleaks / detect-secrets — поиск секретов в репозитории и pre-commit.
6. OWASP ZAP — динамическое тестирование (DAST) веб-приложений, бесплатный.
7. securityheaders.com — моментальная проверка HTTP-заголовков.
8. Dependabot / Renovate — автоматические PR для обновления зависимостей.
9. Grafana + Loki — централизованное логирование, self-hosted.
10. Have I Been Pwned API — проверка паролей пользователей при регистрации и смене.

Тренды: что меняется в 2025–2026

По данным Habr-аналитики о безопасности веба в 2025–2026 годах, XSS, SQLi и CSRF остаются в топе, но инструментарий атакующих усиливается AI-компонентами [14]. Несколько тенденций заслуживают внимания:

1. AI-assisted credential stuffing. Боты с AI-навигацией могут атаковать тысячи приложений одновременно без специфических скриптов под каждый сайт, что существенно снижает порог входа для атакующего [6].

1. MCP-конфиги как новый вектор утечки секретов. GitGuardian в отчёте 2026 года обнаружил более 24 000 уникальных секретов в конфигурационных файлах MCP-серверов. Документация MCP часто рекомендует класть credentials прямо в конфиги [8].

1. Non-human identities как основная поверхность атаки. Сервис-аккаунты, CI/CD токены, машинные credentials — этот класс идентификаторов растёт быстрее human-пользователей, а контроль над ним слабее.

1. Supply chain как системный риск. OWASP поместил Software Supply Chain Failures на третье место не случайно. Атаки через зависимости не начинаются в production — они начинаются в репозиториях разработчиков и CI-раннерах [9].

Заключение: что делать дальше

Безопасность веб-приложения — не проект с датой завершения. Это практика.

Базовый чеклист из этой статьи закрывает наиболее вероятные векторы атаки для типичного стартапа. Он не заменяет полноценную AppSec-программу, пентест или compliance-требования, если вы работаете в финтехе, медтехе или с корпоративными данными. Но он отвечает на вопрос «с чего начать и что обязательно», не требуя выделенного security-инженера с первого дня.

Три вещи, которые стоит сделать на этой неделе:

1. Запустить gitleaks или detect-secrets на репозиторий прямо сейчас.
2. Проверить, включена ли MFA на всех GitHub/GitLab, AWS/GCP/Azure, admin-аккаунтах команды.
3. Открыть securityheaders.com и проверить свой домен.

Остальное — расставьте по приоритетам согласно списку выше.

Источники

[1] Verizon — "2025 Data Breach Investigations Report" — https://www.verizon.com/business/resources/reports/dbir/

[2] OWASP Foundation — "OWASP Top 10:2025" — https://owasp.org/Top10/2025/

[3] Calmops — "HTTPS & Security Headers: TLS, CSP, HSTS and Secure Deployment" — https://calmops.com/programming/web/https-security-headers-tls-csp-hsts/

[4] DCHost — "HTTP Security Headers Guide: HSTS, CSP, X-Frame-Options and Referrer-Policy" — https://www.dchost.com/blog/en/http-security-headers-guide-how-to-correctly-set-hsts-csp-x-frame-options-and-referrer-policy/

[5] SecureBin / Medium — "CORS Misconfiguration: How Attackers Steal Data Cross Origin" — https://securebin.ai/blog/cors-misconfiguration-security-risk/

[6] Clerk — "Authentication Security in Web Applications" — https://clerk.com/articles/authentication-security-in-web-applications

[7] GitGuardian — "State of Secrets Sprawl 2025" — https://www.gitguardian.com/state-of-secrets-sprawl-report-2025

[8] GitGuardian — "State of Secrets Sprawl 2026" — https://www.gitguardian.com/state-of-secrets-sprawl-report-2026

[9] OWASP Foundation — "A03:2025 — Software Supply Chain Failures" — https://owasp.org/Top10/2025/

[10] SupplyChain Strategy — "Beyond the SBOM: The next evolution in software supply chain security" — https://supplychainstrategy.media/blog/2025/04/25/beyond-the-sbom-the-next-evolution-in-software-supply-chain-security/

[11] Cyber Secify — "SBOM for SaaS Startups: When, How, Tools" — https://cybersecify.com/blog/sbom-management-saas-startups/

[12] Edgescan — "Inside the 2025 Verizon DBIR: Critical Insights on Web Application Security" — https://www.edgescan.com/inside-the-2025-verizon-dbir/

[13] OWASP Foundation — "A09:2025 — Security Logging and Alerting Failures" — https://owasp.org/Top10/2025/A09_2025-Security_Logging_and_Alerting_Failures/

[14] Habr — "Безопасность веба: итоги 2025 года и взгляд в будущее" — https://habr.com/ru/publications/1001388/

[15] OWASP Foundation — "DevSecOps Guideline" — https://owasp.org/www-project-devsecops-guideline/