15 ошибок в аутентификации, которые каждый VIBE-кодер выкатывает в прод: — 5 апреля 2026 г. в 08:58:08.066
15 ошибок в аутентификации, которые каждый VIBE-кодер выкатывает в прод: Вот полный разбор **1/** хранение JWT в localStorage > XSS-атака = кража всех токенов на странице > localStorage доступен для чтения любым скриптом на сайте > используйте httpOnly cookies вместо этого **2/** JWT подписан слабым или дефолтным секретом > "secret" и "your_jwt_secret_here" проверяются атакующими в первую очередь > если это из туториала — считайте, что уже скомпрометировано > сгенерируйте полноценный случайный секрет на 256 бит **3/** нет ротации refresh-токенов > украденный refresh-токен работает бесконечно без ротации > ротируйте при каждом использовании, сразу инвалидируйте старый > обычно это настраивается одной строкой в большинстве auth-библиотек **4/** нет блокировки аккаунта после неудачных попыток входа > brute force проходит без какого-либо сопротивления > после 10 неудачных попыток аккаунт должен блокироваться > добавьте lockout + экспоненциальный backoff **5/** middleware аутентификации применяется непоследовательно > AI генерирует middleware для одних роутов и пропускает другие > пропущенные остаются полностью открытыми > вручную аудитируйте каждый endpoint, не предполагая, что он защищён **6/** разные сообщения об ошибке для неверного email и пароля > "user not found" vs "wrong password" сообщает атакующему, какие email существуют > возвращайте одно и то же общее сообщение в обоих случаях > никогда не подтверждайте и не опровергайте существование аккаунта **7/** токены восстановления пароля без срока действия > ссылка на сброс из трёхмесячной давности должна быть невалидной > у вас, скорее всего, нет > задайте короткий TTL — максимум 15–60 минут **8/** redirect_uri в OAuth не валидируется > используется для редиректа auth-кодов на URL под контролем атакующего > явно whitelist’ите все допустимые redirect URI > никогда не допускайте open redirect в OAuth-флоу **9/** нет подтверждения email при регистрации > фейковые аккаунты и спам без какого-либо барьера > подтверждайте email перед выдачей полного доступа > именно verification link, а не просто приветственное письмо **10/** сессии не инвалидируются на сервере при logout > cookie очищается на клиенте, но серверная сессия остаётся валидной > инвалидируйте запись сессии в базе данных при выходе > одного client-side удаления недостаточно **11/** пароли хранятся без bcrypt или argon2 > MD5, SHA256 без соли, plain text > всё это регулярно фигурирует в утечках > только bcrypt или argon2, без исключений **12/** auth endpoint’ы не требуют HTTPS > учётные данные по HTTP видны в любой сети > принудительно используйте HTTPS на уровне инфраструктуры > никакого fallback на HTTP для auth-роутов **13/** проверка ролей на клиенте вместо сервера > нельзя доверять frontend’у в вопросе идентификации пользователя > валидируйте роли и права на каждом серверном запросе > frontend — это UI, а не безопасность **14/** нет 2FA для админских или чувствительных маршрутов > один скомпрометированный пароль = полный доступ ко всему > добавьте TOTP или magic link 2FA минимум для админских маршрутов > обязательно для всего, что работает с пользовательскими данными **15/** тестовые креды остались в проде > admin:admin или test@test.com:password123 — это реальные точки входа, а не удобство > перед релизом аудитируйте и удалите все тестовые аккаунты Вставь это в Cursor перед следующим билдом auth.