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

Чек-лист для команды, которая не хочет обнаружить IDOR, угнанные сессии и утёкшие токены уже в продакшне

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

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

При этом именно личный кабинет часто разрабатывается в режиме «функции есть — запускаемся», а безопасность проверяется по остаточному принципу: «QA прошёл, значит, всё норм». Это ошибка дорогостоящая, потому что базовые уязвимости в личных кабинетах, начиная от IDOR и заканчивая незащищёнными токенами, не требуют сложной эксплуатации — они эксплуатируются скриптами.

Эта статья — практический чек-лист для CTO, Tech Lead и AppSec-специалиста. Мы пройдём по каждому слою: аутентификация, управление сессиями, авторизация и контроль доступа, смена пароля и email, секреты в коде, HTTP-заголовки и настройки безопасности. В конце — краткое резюме о том, где в этом процессе помогает автоматизация.

1. Аутентификация: где ломается «вход»

1.1 Пароли и политика по NIST SP 800-63B-4

В июле 2025 года NIST финализировал Revision 4 стандарта SP 800-63B, который фактически переписал правила работы с паролями [1]. Ключевые изменения, актуальные для любого личного кабинета:

• Минимальная длина пароля — 8 символов (рекомендуется 15 и более).
• Обязательная проверка паролей по спискам скомпрометированных учётных данных (Have I Been Pwned и аналоги).
• Принудительная ротация паролей без признаков компрометации — отменена.
• Требования к специальным символам и «сложности» — убраны.
• Пользователь должен видеть пароль при вводе (кнопка «показать»).
• Подсказки к паролям и контрольные вопросы для восстановления — запрещены.

Перед запуском проверьте: соответствует ли ваша политика паролей актуальному NIST? Если вы по-прежнему требуете «минимум 1 заглавную, 1 цифру, 1 спецсимвол и смену каждые 90 дней» — это не безопаснее, это просто устаревшая схема, которая раздражает пользователей и никого не защищает [2].

Хранение паролей: на сервере должен лежать только хэш, рассчитанный по bcrypt, scrypt или Argon2 с уникальной солью. MD5, SHA-1 и несолёный SHA-256 — это уязвимость, а не защита [3].

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

По данным анализа Microsoft, MFA блокирует 99,9% атак на аккаунты, связанных с паролями [4]. OWASP прямо рекомендует рассматривать компрометацию пароля как неизбежность и проектировать защиту вокруг этого факта.

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

• Есть ли MFA в продукте? Если нет — хотя бы опциональный?
• Если используется SMS OTP — осознаёте ли вы риски SIM-swapping? Для высокочувствительных кабинетов рассмотрите TOTP (Google Authenticator, Authy) или passkeys.
• MFA включена для всех административных аккаунтов? Не только для пользователей, но и для сотрудников с доступом к production.

NIST SP 800-63B-4 вводит три уровня Authentication Assurance Level (AAL). AAL2, который соответствует большинству личных кабинетов с финансовыми данными, требует MFA обязательно [1].

1.3 Брутфорс и защита от перебора

Без ограничений на количество попыток входа ваш личный кабинет открыт для credential stuffing — атаки, при которой злоумышленник прогоняет слитые пары логин/пароль с других утечек. По данным за 2025 год, брутфорс используется в 37% атак на базовые веб-приложения [5].

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

• Есть ли rate limiting на эндпоинте входа? Разумная начальная настройка — не более 5–10 попыток в минуту с одного IP, после чего — throttling или временная блокировка.
• Блокировка аккаунта после N неудачных попыток работает? Не блокируете ли вы навечно (это открывает DoS против собственных пользователей)?
• CAPTCHA подключена? Хотя бы как второй рубеж при подозрительной активности.
• Эндпоинты /api/auth/login, /api/password/reset защищены отдельными, более жёсткими лимитами?

Пример: Google Cloud Armor позволяет настроить rate_based_ban на /login — агрессивные атакующие блокируются автоматически, нормальные пользователи не замечают ограничений [6].

1.4 Что делать с OAuth и SSO

OAuth 2.0 — это протокол авторизации, а не аутентификации. Ошибка, которая встречается повсеместно — путать OAuth-токен с подтверждением личности [7]. Если у вас OAuth через Google или другого провайдера, убедитесь:

• State-параметр в OAuth-флоу генерируется случайно и проверяется при callback (защита от CSRF в OAuth).
• Вы проверяете email из токена, а не просто принимаете любой access token.
• Redirect URI строго зафиксирован на стороне сервера, а не принимается из запроса.

2. Управление сессиями: как теряют кабинет после входа

Пользователь успешно вошёл. Теперь начинается вторая часть: как его сессия живёт, передаётся и завершается.

2.1 Флаги cookie: HttpOnly, Secure, SameSite

Сессионный токен или JWT, хранящийся в localStorage или sessionStorage, доступен любому JavaScript в вашей странице. Одна XSS-уязвимость — и весь токен утёкнет [8]. OWASP явно предупреждает: не храните authentication tokens, session IDs, JWT и refresh tokens в browser storage.

Правильный подход — HttpOnly; Secure; SameSite=Strict cookie. Каждый из флагов защищает от отдельного вектора атаки [9]:

• HttpOnly — токен недоступен из JavaScript, даже если XSS состоялась.
• Secure — токен передаётся только по HTTPS, никогда по HTTP.
• SameSite=Strict — токен не отправляется в cross-site запросах, блокирует CSRF.

Перед запуском проверьте в DevTools → Application → Cookies: выставлены ли все три флага для вашего сессионного токена?

2.2 Хранение JWT: где ошибаются

JWT-токены создают отдельный класс проблем. Самая распространённая — сессию нельзя инвалидировать до истечения срока [10]. Если токен угнан, он работает до exp. Это значит:

• Используйте короткоживущие access tokens (15–60 минут).
• Refresh token храните в HttpOnly cookie, а не в localStorage.
• Реализуйте server-side revocation list или механизм ротации токенов при logout.
• Проверяйте подпись JWT на сервере, не доверяйте заголовку alg. CVE с "alg": "none" — классика, которая продолжает встречаться.

2.3 Завершение сессии

Logout, который очищает cookie на клиенте, не инвалидируя сессию на сервере — это не logout [11]. Проверьте: после нажатия «Выйти» токен действительно перестаёт работать на сервере? Попробуйте после logout повторить запрос с сохранённым токеном.

Дополнительно: есть ли в кабинете «Завершить все сессии»? Это особенно важно для пользователей, которые входили с чужих устройств.

2.4 Idle timeout и абсолютный таймаут

Сессия, которая не истекает, — постоянный риск. Особенно актуально для финансовых и медицинских кабинетов. Рекомендуется два типа таймаута:

• Idle timeout — сессия завершается после N минут бездействия (например, 30 минут).
• Absolute timeout — сессия завершается в любом случае через X часов (например, 8 часов).

3. Авторизация и контроль доступа: самая дорогая ошибка

Broken Access Control занимает первое место OWASP Top 10 с 2021 года и сохраняет его в редакции 2025. OWASP зафиксировал нарушения контроля доступа в 94% протестированных приложений, с более чем 318 000 задокументированных случаев [12]. Это не абстрактная статистика — это вероятность того, что проблема есть в вашем продукте прямо сейчас.

3.1 IDOR: самая частая уязвимость личного кабинета

IDOR (Insecure Direct Object Reference) — это когда пользователь может получить доступ к чужому объекту, просто изменив идентификатор в запросе. В контексте личного кабинета типичные сценарии:

• /api/users/123/profile → меняем на 124 → видим чужие данные.
• /api/orders/789 → меняем на 790 → видим чужой заказ.
• /api/documents/456/download → меняем идентификатор → скачиваем чужой документ.

В классификации MITRE это CWE-639; в API Security Top 10 — BOLA (Broken Object Level Authorization), API1:2023 с оценкой "Easy" по эксплуатируемости [13].

Реальный масштаб: IDOR-уязвимость в API автомобильных сигнализаций позволила исследователям из Pen Test Partners захватить любую машину во флоте; IDOR в системе Optus открыл доступ к почти 10 миллионам записей клиентов [14].

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

• Каждый API-эндпоинт, возвращающий данные по идентификатору, проверяет ownership на сервере? Проверка "пользователь авторизован" ≠ проверка "пользователь имеет право на этот конкретный объект".
• Идентификаторы объектов не sequential? Используйте UUID v4 вместо id=1, 2, 3.
• Логируются ли попытки перебора идентификаторов (например, пользователь запрашивает /api/users/1 через /api/users/1000)?
• Проведён ли test с двумя аккаунтами: токен аккаунта A, запрос к ресурсу аккаунта B?

3.2 Вертикальная эскалация привилегий

Обычный пользователь не должен уметь вызвать эндпоинты администратора. Это очевидно — но на практике встречается регулярно.

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

• Все admin-эндпоинты защищены проверкой роли на сервере (не только скрыты в UI)?
• Параметры роли не передаются из клиента (например, "role": "admin" в теле запроса)?
• API возвращает правильные HTTP 403 для недостаточных прав (а не 200 с пустым ответом или ошибку в теле)?

3.3 Принцип deny-by-default

Архитектурный фундамент безопасного контроля доступа — разрешено только то, что явно разрешено. Если при добавлении нового эндпоинта разработчик «забыл» добавить проверку прав — по умолчанию должно блокироваться, а не разрешаться [15].

4. Восстановление пароля и смена email: уязвимые точки

Процедуры восстановления доступа — отдельная поверхность атаки, которую часто тестируют хуже основного флоу входа.

4.1 Типовые уязвимости в reset password

В 2025 году была опубликована критическая уязвимость CVE-2025-58434 в платформе FlowiseAI: эндпоинт /api/v1/account/forgot-password возвращал в теле ответа не просто «письмо отправлено», а валидный tempToken, имя пользователя, email и хэш пароля. Атакующему хватало email жертвы и двух HTTP-запросов для полного захвата аккаунта [16].

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

• API ответа на запрос сброса пароля возвращает только generic-сообщение ("If this email exists, you'll receive instructions"), никакого токена или данных пользователя.
• Токен сброса одноразовый и автоматически инвалидируется после первого использования.
• Токен имеет короткое время жизни (15–60 минут).
• Токен доставляется только на предварительно зарегистрированный email.
• Смена пароля через токен разрывает все активные сессии.

4.2 Host header poisoning в reset-ссылках

Ещё один сценарий: приложение формирует ссылку для сброса пароля, используя заголовок Host из входящего HTTP-запроса. Атакующий подменяет Host на свой домен — пользователь кликает по ссылке на attacker.com, токен утекает [17].

Проверьте: URL в письмо для сброса пароля формируется из захардкоженного домена (конфигурация), а не из request.headers.host.

4.3 Смена email требует повторной аутентификации

Если пользователь может сменить email аккаунта без подтверждения текущего пароля, атакующий со стянутым сессионным токеном получает возможность сменить email и запустить reset password на свой адрес. OWASP API Security Top 10 (API2:2023) описывает именно такой сценарий [7].

Перед запуском: операции смены email, телефона и пароля требуют повторного ввода текущего пароля?

5. Секреты в коде и конфигурации: что нельзя выпускать в продакшн

Это проблема, которая существовала до эпохи AI-кодинга, но существенно обострилась с ней. Когда ИИ-ассистент генерирует готовый кусок кода с hardcoded API key «для примера», этот ключ нередко уходит в PR и затем в прод, если никто не проверил диф внимательно.

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

• API_KEY, SECRET_KEY, DATABASE_PASSWORD, JWT_SECRET и другие секреты в .env-файлах, которые попали в репозиторий.
• .env или .env.production в .gitignore? Проверьте историю коммитов — секреты могли попасть раньше, чем файл был добавлен в ignore.
• Debug-флаги, включённые в production (DEBUG=True, APP_DEBUG=true).
• Токены и ключи в логах CI/CD — большинство платформ маскируют переменные, помеченные как секреты, но явные echo $SECRET_KEY в скриптах это не блокирует [18].
• Fallback-значения секретов в коде: SECRET = os.getenv("SECRET_KEY", "hardcoded-fallback-value") — если переменная не выставлена, приложение молча использует захардкоженный fallback.

5.2 Что делать

• HashiCorp Vault, AWS Secrets Manager или GCP Secret Manager вместо env-переменных напрямую [19].
• Инструменты static secrets scanning: truffleHog, detect-secrets, gitleaks — их можно запустить в pre-commit hook и в CI.
• Ротация скомпрометированных секретов: если ключ попал в коммит — ротируйте немедленно, даже если репозиторий приватный. Доступ к приватному репо шире, чем вам кажется.

6. HTTP-заголовки и конфигурация безопасности

Несколько строк конфигурации веб-сервера закрывают целый класс атак.

6.1 Content Security Policy (CSP)

CSP — это HTTP-заголовок, который говорит браузеру, с каких источников разрешено загружать скрипты, стили, медиа. Основная задача — снизить ущерб от XSS: даже если атакующий внедрил скрипт, браузер откажется его запускать, если источник не в whitelist [20].

Минимально рабочий подход — Content-Security-Policy: default-src 'self'. Перед запуском используйте Content-Security-Policy-Report-Only для мониторинга нарушений без блокировки, отладьте политику, затем переключитесь на enforcement.

Проверить CSP вашего сайта: CSP Evaluator от Google.

6.2 Другие критичные заголовки

• Strict-Transport-Security (HSTS) — принудительный HTTPS, защита от downgrade-атак.
• X-Content-Type-Options: nosniff — браузер не будет угадывать MIME-тип, что предотвращает ряд инъекций.
• X-Frame-Options: DENY или frame-ancestors 'none' через CSP — защита от clickjacking.
• Referrer-Policy: no-referrer или strict-origin — токены не утекают в заголовок Referer при переходах.
• Permissions-Policy — ограничение доступа к камере, микрофону, геолокации.

Проверить все заголовки: SecurityHeaders.com.

6.3 TLS и шифрование

• TLS 1.2 минимум, предпочтительно TLS 1.3. SSL 3.0, TLS 1.0, TLS 1.1 — отключены.
• Сертификат актуален, HSTS выставлен с достаточным max-age (минимум год для production).
• Weak cipher suites отключены.

7. Логирование и мониторинг: как не пропустить атаку

Личный кабинет без логирования событий безопасности — это система, которую атакуют, а вы узнаёте об этом из новостей или от клиентов.

OWASP Top 10 включает «Insufficient Logging & Monitoring» в список критических рисков. Атака на Target в 2013 году оставалась незамеченной неделями — алерты на подозрительную активность игнорировались [21].

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

• Логируются ли события: попытки входа (успешные и неуспешные), смена пароля, смена email, смена платёжных данных, запросы на ресурсы с 403, аномально большое число запросов к API?
• Логи не содержат паролей, полных номеров карт, токенов, персональных данных.
• Есть ли алертинг на подозрительную активность: серия неудачных входов, запросы перебора ID, попытки войти в admin-панель?
• Логи хранятся отдельно от production-среды, где атакующий с доступом к серверу не может их удалить?

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

Сведём всё в один операционный список.

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

1. Пароли хэшируются bcrypt/scrypt/Argon2 с солью.
2. Политика паролей соответствует NIST SP 800-63B-4: минимум 8 символов, проверка по спискам утечек.
3. Форсированная ротация паролей без признаков компрометации — отключена.
4. Защита от брутфорса: rate limiting + временная блокировка после N попыток.
5. MFA доступна (обязательна для admin-аккаунтов).
6. OAuth state parameter проверяется; redirect_uri захардкожен на сервере.

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

1. Сессионные токены в HttpOnly; Secure; SameSite=Strict cookie.
2. Токены не хранятся в localStorage/sessionStorage.
3. JWT: короткое время жизни access token + revocation-механизм.
4. Logout инвалидирует сессию на сервере.
5. Idle timeout и absolute timeout настроены.
6. После login генерируется новый session ID (защита от session fixation).

Авторизация и доступ

1. Каждый API-эндпоинт проверяет ownership объекта, не только факт авторизации.
2. Идентификаторы объектов — UUID, не sequential integers.
3. Admin-эндпоинты проверяют роль на сервере, а не только в UI.
4. Принцип deny-by-default: новый эндпоинт без явного разрешения — заблокирован.
5. Тест с двумя аккаунтами пройден: аккаунт A не может читать/писать ресурсы аккаунта B.

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

1. API сброса пароля возвращает generic-ответ, без токенов в теле.
2. Токен сброса одноразовый, живёт ≤60 минут.
3. URL для сброса пароля строится из конфига, не из Host header.
4. Смена email и пароля требует текущего пароля.
5. После сброса пароля все активные сессии завершаются.

Секреты и конфигурация

1. .env файлы с секретами отсутствуют в репозитории (включая историю).
2. Нет hardcoded fallback-значений для секретов в коде.
3. Debug-режим выключен в production.
4. Секреты управляются через Vault/Secrets Manager.

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

1. CSP настроен и протестирован.
2. HSTS, X-Content-Type-Options, X-Frame-Options выставлены.
3. TLS 1.3 (минимум 1.2), старые протоколы отключены.

Логирование

1. Ключевые события (вход, смена данных, 403, аномалии) логируются; чувствительные данные в логах отсутствуют.

9. Где в этом процессе помогает автоматизация

Описанный чек-лист — это работа, которую надо делать не один раз «перед запуском», а с каждым PR и релизом. Проблема в том, что команды под давлением дедлайнов дочитывают диф не до конца; новая или транзитивная зависимость приезжает незаметно; служебный код, конфиги и миграции читают хуже всего.

Именно здесь встаёт вопрос о дополнительном слое контроля до merge и релиза. Инструменты SAST (Semgrep, CodeQL) помогают найти паттерны небезопасного кода; SCA (Snyk, Dependabot) — уязвимые зависимости; secrets scanning (gitleaks, truffleHog) — утечки токенов.

Для команд, которые используют AI-ассистентов при разработке, возникает ещё один риск: сгенерированный код может выглядеть рабочим, но содержать hardcoded ключи, небезопасные паттерны авторизации или debug-флаги. Здесь HighVibe помогает как слой контроля на уровне конкретного изменения — не как замена SAST/SCA, а как короткий практический сигнал перед merge: можно ли безопасно принять именно это изменение сейчас. Это особенно актуально для конфигов, миграций и служебного кода, который при code review читают по диагонали.

10. Что делать, если всё это звучит как слишком много работы

Это нормальная реакция. Список из 30 пунктов перед запуском при горящих дедлайнах — это давление. Но есть приоритизация:

Критично (блокирует запуск):

• Ownership-проверки в API (IDOR) — это самый частый вектор утечки данных.
• Флаги cookie: HttpOnly, Secure, SameSite — это закрывается одной строкой конфига.
• Секреты в коде — прогоните gitleaks прямо сейчас, это займёт минуту.

Важно (следующий спринт):

• MFA для admin-аккаунтов.
• Логирование событий безопасности.
• CSP и security headers.

Хорошая практика (квартал):

• Переход на Secrets Manager.
• Автоматизация проверок в CI.
• Полноценный penetration test.

Заключение

Безопасность личного кабинета — это не сертификат, который получают раз и навсегда. Каждый новый PR, каждая новая зависимость, каждый изменённый конфиг — потенциальная точка риска. Хорошая новость: большинство критических уязвимостей, которые приводят к реальным инцидентам, устраняются не дорогостоящими изменениями архитектуры, а вниманием к деталям: правильными флагами cookie, проверкой ownership на сервере, отсутствием секретов в коде и generic-ответами в reset password flow.

Запустите личный кабинет со 30 проверками — и у вас будет не идеальная безопасность (её не существует), но значительно более высокий порог для атакующего.

Источники

[1] NIST — "SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management" — https://pages.nist.gov/800-63-4/sp800-63b.html

[2] Kaspersky — "New 2024 NIST requirements for password strength and storage" — https://www.kaspersky.com/blog/2024-password-and-otp-requirements-nist-sp-800-63/52544/

[3] ArcherPoint — "2025 Cybersecurity Brute Force Update" — https://archerpoint.com/2025-cybersecurity-brute-force-update/

[4] OWASP — "Multifactor Authentication Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html

[5] CCI Training — "Brute Force Attacks in 2026: Prevention, Tools & Defense" — https://ccitraining.edu/blog/guide-to-prevent-brute-force-attacks/

[6] OneUptime — "How to Configure Rate Limiting Rules to Prevent Brute-Force Attacks" — https://oneuptime.com/blog/post/2026-02-17-how-to-configure-rate-limiting-rules-to-prevent-brute-force-attacks-in-google-cloud-armor/view

[7] OWASP — "API2:2023 Broken Authentication" — https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/

[8] OWASP — "Session Management Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

[9] OnSecurity — "Session Management Vulnerabilities: What Developers Get Wrong and How to Fix Them" — https://onsecurity.io/article/session-management-vulnerabilities-what-developers-get-wrong-and-how-to-fix-them/

[10] Clerk — "Next.js Session Management: Solving NextAuth Persistence Issues" — https://clerk.com/articles/nextjs-session-management-solving-nextauth-persistence-issues

[11] TrustedSec — "AppSec Cheat Sheet: Session Management" — https://trustedsec.com/blog/appsec-cheat-sheet-session-management

[12] OWASP — "Broken Access Control (A01:2025)" — https://blog.intelligencex.org/broken-access-control-owasp-a01-2025-complete-guide

[13] OWASP — "Insecure Direct Object Reference (IDOR)" — https://owasp.org/www-community/attacks/insecure_direct_object_reference

[14] SentinelOne — "What Is Insecure Direct Object Reference (IDOR)?" — https://www.sentinelone.com/cybersecurity-101/cybersecurity/insecure-direct-object-reference/

[15] Authgear — "Defending Against Broken Access Control Vulnerabilities: A Comprehensive Guide" — https://www.authgear.com/post/what-is-broken-access-control-vulnerability-and-how-to-prevent-it/

[16] Cyber Security News — "FlowiseAI Password Reset Token Flaw Enables Account Takeover (CVE-2025-58434)" — https://cyberpress.org/flowiseai-token-flaw/

[17] GBHackers — "Password Reset Link Poisoning Leads to Full Account Takeover" — https://gbhackers.com/password-reset-link-poisoning/

[18] BearPass — "Секреты в DevOps и CI/CD: как не хранить пароли в коде" — https://bearpass.ru/blog/upravlenie-sekretami-v-devops-i-cicd

[19] Codeby School — "DevSecOps: Автоматизация безопасности в CI/CD" — https://codeby.school/blog/informacionnaya-bezopasnost/devsecops-bez-boli-gotovyy-gitlab-ci-pipeline-za-15-minut

[20] OWASP — "Content Security Policy Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html

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