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

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

Почему личный кабинет — приоритетная цель

Личный кабинет — это не просто форма входа и страница профиля. Это точка концентрации пользовательских данных: персональные сведения, история заказов, платёжные инструменты, документы, адреса, паспортные данные. Для злоумышленника взломанный аккаунт одного пользователя ценнее дырки в публичном endpoint — он даёт прямой доступ к реальным данным реального человека, которые можно монетизировать или использовать для дальнейших атак.

Масштаб проблемы конкретен. По данным экспертно-аналитического центра InfoWatch, в 2024 году из российских компаний утекло 1,581 млрд записей персональных данных — на 30% больше, чем в 2023-м [1]. Роскомнадзор зафиксировал 135 подтверждённых фактов утечек с более чем 710 млн записей [7]. Почти треть всего объёма слитых данных — аутентификационная информация: логины, пароли, номера телефонов, адреса e-mail [1]. Именно через скомпрометированные учётные данные злоумышленники чаще всего попадают в личные кабинеты банков, маркетплейсов и сервисов.

Эта статья — практическое руководство для CTO, Tech Lead и AppSec-специалистов: что именно проверить в личном кабинете перед запуском, как расставить приоритеты и где наиболее вероятно найти критические уязвимости.

Блок 1. Аутентификация: первая линия обороны

1.1 Пароли и политика хранения

Слабое хранение паролей — одна из самых распространённых и одновременно наиболее легко устранимых ошибок. Перед запуском проверьте:

• Используется ли медленный хэш — bcrypt, Argon2 или PBKDF2 с достаточным cost-фактором? MD5 и SHA-1 без соли не являются допустимыми механизмами хранения паролей [8].
• Применяется ли уникальная соль для каждого пользователя?
• Хранятся ли пароли только в виде хэша — никакого plaintext, никакого симметричного шифрования, которое можно расшифровать?

NIST SP 800-63B-4, финальная редакция которого опубликована в июле 2025 года, устанавливает, что сервисы должны сравнивать вводимые пользователями пароли со списком скомпрометированных (breach corpus) и запрещать их использование [4]. Также стандарт рекомендует отказаться от обязательной периодической смены пароля без признаков компрометации — это противоречит практике, но именно такова текущая позиция NIST, основанная на исследованиях поведения пользователей.

Минимальная длина пароля должна составлять не менее 8 символов (NIST рекомендует 15+), а максимум — не ниже 64 символов. Пользователям нужно разрешать вставку пароля (paste) — это облегчает использование менеджеров паролей [4].

1.2 Многофакторная аутентификация

MFA остаётся одним из наиболее эффективных механизмов защиты аккаунтов. Двухфакторная аутентификация требует двух независимых факторов подтверждения — например, пароль плюс одноразовый код из TOTP-приложения [9].

Что проверить перед запуском:

• Реализован ли механизм MFA для входа?
• Используется ли TOTP (Google Authenticator, Authy) или push-уведомления как более предпочтительный вариант по сравнению с SMS?
• Если SMS используется — понимает ли команда риски SIM-свопинга?
• Защищён ли сам процесс привязки и отвязки второго фактора от несанкционированного изменения?

1.3 Защита от брутфорс-атак

OWASP рекомендует комбинировать несколько механизмов вместо одного [6]:

• Rate limiting на endpoint входа: ограничение числа запросов с одного IP за временной интервал.
• Временная блокировка аккаунта после 3–5 неудачных попыток (с осторожностью: механизм блокировки сам может использоваться для DoS реальных пользователей) [6].
• CAPTCHA, которая появляется после серии неудачных попыток, а не сразу.
• Экспоненциальный delay между попытками.
• Мониторинг и алертинг на массовые попытки входа.

Важная деталь: механизм rate limiting не должен сбрасываться при успешном входе — счётчик нужно удерживать независимо от результата [10].

Блок 2. Управление сессиями

2.1 Куки и JWT: что выбрать и как настроить

Сессии в личном кабинете управляются либо через серверные сессии с куки-идентификатором, либо через JWT (JSON Web Tokens). Каждый подход имеет риски, которые нужно знать заранее.

Если используются куки:

• Установить флаги Secure (только HTTPS), HttpOnly (недоступны JS) и SameSite=Strict или SameSite=Lax [11].
• Атрибут SameSite предотвращает CSRF-атаки, при которых браузер автоматически отправляет куки на сторонний сайт [11].
• Установить разумный Max-Age или Expires.

Если используется JWT:

• Хранить токены в HttpOnly-куках, а не в localStorage — это защищает от кражи через XSS [12].
• Устанавливать короткий срок действия access-токена (minutes, не hours).
• Реализовать механизм invalidation или токен-блэклистинга при logout [13].
• Не хранить в JWT чувствительные данные, которые не должны быть доступны клиенту.

2.2 Жизненный цикл сессии

• Регенерация session ID после успешной аутентификации — обязательна для предотвращения session fixation атак.
• Инвалидация всех активных сессий при смене пароля.
• Явный logout с уничтожением сессии на сервере — не только удаление куки на клиенте.
• Timeout по неактивности: пользователь, который не совершал действий N минут, должен быть выведен из системы [13].

Блок 3. Контроль доступа: самое уязвимое место

Broken Access Control — лидер OWASP Top 10 с 2021 года. По оценкам OWASP, эта категория охватывала 94% проверенных приложений [2]. Наиболее распространённая форма — IDOR (Insecure Direct Object Reference): приложение проверяет, аутентифицирован ли пользователь, но не проверяет, принадлежит ли ему запрашиваемый объект.

3.1 IDOR и BOLA: меняем число в параметре

Классический сценарий: пользователь видит свой заказ по адресу /api/orders/12345. Меняет 12345 на 12346 — и получает заказ другого пользователя с именем, адресом и платёжными данными. Вся цепочка — одна смена числа в запросе [14].

OWASP API Security Top 10 описывает эту проблему как BOLA (Broken Object Level Authorization) — тот же паттерн, но в контексте API [2].

Что проверить:

• Каждый запрос к данным пользователя должен содержать проверку: принадлежит ли объект текущему аутентифицированному пользователю?
• Наиболее надёжный паттерн — встраивать проверку прав прямо в SQL/ORM-запрос: если объект не принадлежит пользователю, запрос возвращает пустой результат, а не объект с последующей проверкой [15].
• Идентификаторы объектов в формате UUID не решают проблему IDOR — UUID предотвращает угадывание, но не заменяет авторизацию [14].

3.2 Скрытые в UI эндпоинты

Распространённая ошибка: функциональность администратора скрыта в интерфейсе от обычных пользователей, но API-эндпоинты, которые она вызывает, не защищены на уровне сервера. Злоумышленник не использует UI — он отправляет запросы напрямую через curl или Burp Suite [15].

Перед запуском проверьте все административные и служебные эндпоинты на наличие server-side authorization checks. Клиентские проверки (скрытие кнопок, disabled-элементы) — не защита.

3.3 Горизонтальная и вертикальная эскалация привилегий

• Горизонтальная: пользователь А получает доступ к данным пользователя Б с теми же правами.
• Вертикальная: обычный пользователь получает доступ к административным функциям.

Оба вектора нужно тестировать вручную — автоматические сканеры плохо находят IDOR из-за необходимости понимать бизнес-логику приложения [16].

Блок 4. HTTP-заголовки безопасности

HTTP security headers — бесплатная и быстрая защита, которую при этом игнорирует значительная часть сайтов в production. По данным анализа топ-1 млн сайтов 2025 года, у более 40% отсутствует HSTS, а корректный CSP есть менее чем у 25% [3].

OWASP Secure Headers Project определяет список обязательных заголовков [17]:

Content-Security-Policy (CSP)

Самый мощный заголовок: сообщает браузеру, из каких источников допустимо загружать скрипты, стили, изображения. Даже если атакующий внедрил <script> через XSS-уязвимость, CSP не даст браузеру его выполнить [3].

Критическая ошибка настройки: script-src 'self' 'unsafe-inline' 'unsafe-eval' — это полностью обесценивает CSP. Используйте nonces или hashes вместо 'unsafe-inline'.

Рекомендуемый подход: начинать с Content-Security-Policy-Report-Only для мониторинга нарушений, затем переходить к enforce-режиму [18].

HTTP Strict Transport Security (HSTS)

Сообщает браузеру, что с этим доменом нужно общаться только через HTTPS. Защищает от атак с понижением протокола и перехвата куки [17].

Рекомендуемая конфигурация: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (2 года, как рекомендует OWASP).

X-Frame-Options / frame-ancestors

Защита от clickjacking — атак, при которых приложение встраивается в iframe на вредоносном сайте, и пользователь совершает действия, не осознавая этого [19].

Современный подход: директива frame-ancestors в CSP заменяет X-Frame-Options для поддерживающих браузеров [17].

Остальные обязательные заголовки

• X-Content-Type-Options: nosniff — запрещает браузеру «угадывать» MIME-тип файла.
• Referrer-Policy — ограничивает передачу URL в заголовке Referer.
• Permissions-Policy — контролирует доступ к браузерным API (камера, микрофон, геолокация).

Блок 5. Защита данных и шифрование

5.1 TLS и передача данных

• Все соединения только через HTTPS/TLS 1.2+, предпочтительно TLS 1.3.
• TLS 1.0 и 1.1 — отключить; SSLv3 — отключить.
• Проверить конфигурацию cipher suites: исключить слабые алгоритмы (RC4, 3DES).
• Корректная настройка сертификата: срок действия, цепочка доверия, CAA-записи в DNS.

5.2 Данные в состоянии покоя

• Персональные данные, платёжная информация и другие чувствительные поля — шифровать в базе данных.
• Конфигурационные файлы с секретами не хранить в репозитории — только в vault-системах или через переменные окружения.
• Логи не должны содержать пароли, токены, номера карт и другие чувствительные данные.

5.3 Восстановление пароля

Форма восстановления пароля — нередко самое уязвимое место в системе аутентификации. Проверить:

• Ссылка для сброса пароля одноразовая и имеет ограниченный срок жизни (максимум 15–30 минут).
• Ссылка инвалидируется после использования.
• Rate limiting на endpoint запроса восстановления.
• Не раскрывать, существует ли email в системе (user enumeration через форму восстановления).

Блок 6. Инъекции и валидация входных данных

SQL Injection по данным OWASP 2021 затрагивает 82% приложений [8]. Правила для личного кабинета:

• Использовать параметризованные запросы / prepared statements — не конкатенацию строк в SQL.
• Валидация и санитизация всех пользовательских данных на сервере — клиентская валидация не является защитой.
• Экранирование вывода для предотвращения Reflected и Stored XSS.
• Проверить все поля профиля, поиска, фильтрации: имя, адрес, номер телефона — любое поле, которое сохраняется и отображается, потенциально уязвимо для Stored XSS.

Блок 7. API и мобильный клиент

Если личный кабинет работает через API (SPA, мобильное приложение), проверки расширяются:

• Все API-эндпоинты требуют аутентификации — нет «забытых» открытых методов.
• Авторизация проверяется на уровне каждого endpoint, не только на уровне middleware.
• CORS настроен корректно: Access-Control-Allow-Origin: * в production — красный флаг [9].
• API не возвращает лишних полей: проверить, что в ответе нет данных других пользователей, внутренних идентификаторов, отладочной информации.
• Rate limiting настроен не только на endpoint входа, но и на остальные чувствительные операции.

Особое внимание — мобильному API: исторически он проходит меньше code review, быстро добавляет новые endpoint'ы и хуже защищён от несанкционированного доступа [16].

Блок 8. Логирование и мониторинг

Перед запуском нужно убедиться, что инциденты будут заметны:

• Логируются все попытки аутентификации — успешные и неудачные.
• Логируются изменения чувствительных данных (смена email, пароля, телефона).
• Логируются обращения к административным функциям.
• Настроены алерты на аномальные паттерны: массовые попытки входа, нетипичный объём запросов к данным, повторяющиеся ошибки авторизации.
• Логи защищены от модификации и доступны только авторизованному персоналу.

Отдельно проверить: не попадают ли в логи пароли, токены или другие секреты — это частая ошибка при логировании request/response целиком.

Блок 9. Зависимости и конфигурация

85% веб-приложений использует компоненты с известными уязвимостями — это одна из наиболее простых для эксплуатации и одновременно наиболее простых для предотвращения проблем [8].

• Проверить все зависимости через SCA-инструменты (Snyk, OWASP Dependency-Check, npm audit, pip audit).
• Обновить зависимости с известными CVE перед запуском.
• Отключить debug-режим в production-конфигурации.
• Удалить или закрыть тестовые аккаунты, дефолтные пароли, примерные данные.
• Проверить directory listing: сервер не должен показывать содержимое директорий.
• Убедиться, что stack trace и внутренние ошибки не отображаются конечному пользователю.

Отдельно проверить конфигурационные файлы: не попали ли в репозиторий ключи API, токены, строки подключения к базе данных, приватные ключи. Это особенно актуально, если код писался с помощью AI-ассистентов — временные ключи и debug-настройки нередко оседают в коде незаметно для разработчика. HighVibe анализирует именно такие изменения: конфиги, миграции, служебные файлы и новые зависимости, которые появились в PR и которые легко пропустить при быстром ревью перед релизом.

Практический чек-лист: что проверить перед запуском

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

1. Пароли хэшируются через bcrypt/Argon2/PBKDF2 с солью.
2. Минимальная длина пароля — 8 символов (рекомендуется 15+).
3. Реализован MFA.
4. Rate limiting на endpoint входа (5 попыток / 15 минут с IP).
5. Временная блокировка или CAPTCHA после серии неудачных попыток.
6. Ссылка для сброса пароля одноразовая, живёт не более 30 минут.
7. Форма восстановления не раскрывает существование email.

Сессии:

1. Куки с флагами HttpOnly, Secure, SameSite.
2. Session ID регенерируется после входа.
3. Инвалидация всех сессий при смене пароля.
4. Timeout по неактивности реализован.
5. Logout уничтожает сессию на сервере.

Контроль доступа:

1. Каждый запрос к данным проверяет принадлежность объекта текущему пользователю.
2. Проверка авторизации — на сервере, не только в UI.
3. Административные endpoint'ы защищены независимо от фронтенда.
4. Ручное тестирование IDOR: смена ID в параметрах запросов.

HTTP-заголовки:

1. CSP настроен без unsafe-inline/unsafe-eval.
2. HSTS с max-age не менее 1 года.
3. X-Content-Type-Options: nosniff.
4. Referrer-Policy и Permissions-Policy настроены.

Шифрование и данные:

1. TLS 1.2+ на всех соединениях; TLS 1.0/1.1 отключены.
2. Чувствительные данные зашифрованы в БД.
3. Секреты не в репозитории.
4. Логи не содержат паролей и токенов.

Зависимости и конфигурация:

1. SCA-сканирование зависимостей выполнено.
2. Debug-режим отключён в production.
3. Тестовые аккаунты и дефолтные пароли удалены.
4. Stack trace не отображается пользователям.
5. Directory listing отключён.

API:

1. CORS не разрешает * в production.
2. Все API-endpoint'ы требуют аутентификации.
3. Ответы API не содержат лишних полей.

Типичные ошибки и как их избежать

Ошибка 1: «Работает — значит безопасно» Функциональное тестирование не обнаруживает IDOR, XSS и broken access control. Нужно отдельное security testing — хотя бы ручное по OWASP WSTG.

Ошибка 2: Авторизация только на уровне middleware Middleware проверяет, что пользователь вошёл в систему, но не проверяет, может ли он обратиться к конкретному объекту. Нужна object-level authorization в каждом handler'е.

Ошибка 3: UUID вместо авторизации UUID предотвращает угадывание ID, но если UUID утёк (через лог, другой API-ответ, URL из письма), IDOR остаётся возможным. UUID — не замена авторизации [14].

Ошибка 4: Клиентская валидация без серверной Все проверки на клиенте легко обходятся через Burp Suite или прямые запросы к API. Серверная валидация обязательна.

Ошибка 5: Security headers как «настроим потом» CSP, HSTS и другие заголовки часто откладываются «до следующего спринта» и остаются ненастроенными месяцами после запуска.

Ошибка 6: Секреты в коде Особенно характерно для проектов с активным использованием AI-ассистентов: ключи, токены и временные конфиги попадают в код в процессе итерационной разработки и остаются незамеченными при ревью.

Инструменты для проверки

Для первичного аудита перед запуском можно использовать:

• OWASP ZAP — бесплатный DAST-сканер для веб-приложений.
• Burp Suite Community — для ручного тестирования авторизации и IDOR.
• securityheaders.com — проверка HTTP-заголовков онлайн.
• SSL Labs — анализ TLS-конфигурации.
• OWASP Dependency-Check — поиск уязвимых зависимостей.
• npm audit / pip audit — для проверки зависимостей в Node.js и Python.

Автоматические сканеры хорошо находят header-проблемы, инъекции и конфигурационные ошибки, но плохо справляются с IDOR и нарушениями бизнес-логики — эти вещи требуют ручной проверки.

Заключение: что делать прямо сейчас

Безопасность личного кабинета — не одноразовая задача «поставить галочку перед релизом», а постоянный процесс. Но именно перед первым запуском есть наиболее высокая вероятность, что фундаментальные проблемы ещё не зафиксированы в production и их можно исправить с минимальными издержками.

Минимально жизнеспособный security-review перед запуском:

1. Пройти по чек-листу выше и закрыть критические пункты (аутентификация, управление сессиями, контроль доступа).
2. Проверить HTTP-заголовки через securityheaders.com.
3. Запустить OWASP ZAP в автоматическом режиме.
4. Вручную проверить IDOR на ключевых API-эндпоинтах.
5. Убедиться, что в production-сборке нет debug-режима, тестовых аккаунтов и секретов в коде.

В командах, где AI-ассистенты активно используются в разработке, особого внимания требуют PR с изменениями конфигов, новыми зависимостями и служебным кодом — именно там чаще всего оседают незаметные риски. Инструменты, анализирующие конкретное изменение перед merge и выдающие короткий, понятный сигнал для команды, — не замена AppSec-программе, но практичный дополнительный слой контроля перед релизом. HighVibe (highvibe.dev) строится именно на этой логике: анализ конкретного изменения, а не весь репозиторий целиком — и ответ на вопрос «можно ли безопасно принять это изменение сейчас».

Источники

[1] InfoWatch — «Россия: утечки информации ограниченного доступа, 2023–2024» — infowatch.ru

[2] OWASP — «OWASP Top Ten 2021 / A01:2021 – Broken Access Control» — owasp.org

[3] Security Factor 365 — «HTTP Security Headers: The Complete 2026 Checklist» — sf.peopleworksservices.com

[4] NIST — «SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management» — csrc.nist.gov

[5] ITFB — «Чек-лист безопасности сервера: 15 пунктов» — itfb.com.ua

[6] OWASP — «Blocking Brute Force Attacks» — owasp.org

[7] CNews — «В 2024 году в Сеть утекли более 710 млн записей о россиянах» — cnews.ru

[8] aTeam Soft Solutions — «Web Application Security Checklist 2025: Complete OWASP Top 10 Implementation Guide for CTOs» — ateamsoftsolutions.com

[9] workspace.ru — «Безопасность веб-приложений: лучшие практики 2025» — workspace.ru

[10] Ahmad Sopyan / Medium — «Authentication part-6: Broken brute-force protection, IP block» — medium.com

[11] Syncfusion — «Secure JWT Storage: Best Practices» — syncfusion.com

[12] Wisp CMS — «Ultimate Guide to Securing JWT Authentication with httpOnly Cookies» — wisp.blog

[13] Statsig — «Session identifiers: cookies, tokens & security best practices» — statsig.com

[14] AquilaX — «Broken Access Control and IDOR Explained» — aquilax.ai

[15] Acunetix — «Broken Access Control: An OWASP Top 10 Risk» — acunetix.com

[16] Strobes — «Your Go-To Web Application Pentesting Checklist» — strobes.co

[17] OWASP — «Secure Headers Project» — owasp.org

[18] DoHost — «Implementing Security Headers: HSTS, X-Frame-Options, and Content Security Policy» — dohost.us

[19] OWASP — «HTTP Headers Cheat Sheet» — cheatsheetseries.owasp.org

[20] Netwrix — «NIST password guidelines: SP 800-63B Rev. 4 explained» — netwrix.com