Авторизация и аутентификация

f

Что вам гарантирует правильная авторизация в Laravel

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

Система не даст вам случайно оставить дыру: встроенные middleware проверяют каждый запрос, а миграции для таблиц users, tokens и sessions создаются автоматически. Вы не пропустите забытую проверку — Laravel заставит вас явно указать, какие маршруты открыты всем, а какие — только авторизованным.

Но гарантии не работают, если вы не проверили настройки. Например, по умолчанию Laravel не требует двухфакторной аутентификации — её надо включать вручную. Или: если вы используете API без Sanctum, токены могут быть незащищены от перехвата.

Главные риски, которые превращают защиту в фикцию

Вы думаете, что password_hash в PHP работает магией? Нет — если в настройках не указана сложность bcrypt (рекомендуется 12 раундов), хеш слабеет в десятки раз. А если в вашем приложении используется сессия с фиксированным ID — злоумышленник может подменить её через XSS. Ваша база данных может быть идеальной, а вот HTTP-заголовки — нет.

Самый частый риск: вы даёте пользователю запомнить пароль на «вечно», а потом забываете очистить старые токены. Ладно, токен — это строка, но если вы не используете refresh-токены, то после утечки одного токена злоумышленник получает пожизненный доступ. Другой риск: вы не проверяете IP при входе — и тогда атака с подбором пароля может идти с разных адресов.

Каждый из этих рисков нейтрализуется одной строкой в конфиге или middleware. Но вы должны знать, где именно что включать. Например, для rate limiting в Laravel достаточно добавить в маршрут ThrottleRequests, а для CSRF — просто @csrf в формах. Если этого нет — считайте, что защиты нет совсем.

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

Прежде чем запускать даже тестовый вход, возьмите чек-лист. Сначала убедитесь, что ваше приложение работает через HTTPS — иначе любой пароль летит открытым текстом по Wi-Fi. Потом откройте файл config/session.php: стоит ли время жизни куки не больше 2 часов? А параметр same_site установлен в 'lax' или 'strict'?

Затем запустите консоль: php artisan make:auth — это стандартный скелет, но вы удивитесь, сколько разработчиков его не запускают. После него проверьте, что в .env есть настройки для почты (MAIL_*) — сброс пароля без них не работает. И обязательно проверьте, что таблица password_resets существует — без неё восстановление доступа обернётся ошибкой.

Самый простой способ проверить — просто откройте публичный маршрут /dashboard. Если он доступен без логина — значит, вы забыли middleware 'auth' в web.php. Исправляйте, пока не поздно.

Встроенные решения Laravel: что вы получаете из коробки

Laravel Breeze — это минимальный набор, с которым вы запускаете регистрацию, вход, выход, сброс пароля, подтверждение email. Он не даёт вам управления ролями — только базовая аутентификация. Laravel Jetstream (да, он ещё актуален в 2026) добавляет двухфакторную аутентификацию, управление сессиями, API с Sanctum, и интерфейс для удаления аккаунта. Вы сразу видите, кто и с каких устройств заходил — в админке есть вкладка «Активные сеансы».

Для API вам нужен Sanctum или Passport. Sanctum легче — хранит токен только в куке, при этом не требует отдельной таблицы для токенов (использует ту же сессию). Passport даёт полноценный OAuth, но если у вас нет подписок или сторонних приложений — овчинка не стоит выделки. Выбор между ними прост: если у вас одностраничное приложение, SPA — берите Sanctum. Если нужны сервер-к-серверу с доступом от имени пользователя — Passport.

Помните: эти решения гарантируют только базовую безопасность. Они не защитят от атаки на основе идеального подбора пароля, если вы не включили recaptcha. Они не шифруют данные на уровне базы — это отдельная задача.

Как решать проблемы, если что-то пошло не так

Представьте: пользователь жалуется, что не может войти даже с правильным паролем. Первое — посмотрите логи: storage/logs/laravel.log. Там будет строка типа «Invalid credentials» или «Trying to authenticate non-existent user». Если ошибки нет — значит, проблема в сессии. Попробуйте очистить куки в браузере, а на сервере — выполнить php artisan session:clear (только для разработки). В продакшне никогда не очищайте все сессии — просто откройте БД и удалите строку конкретного пользователя.

Если токен протух, а пользователь жалуется — проверьте exp в токене. По умолчанию у Sanctum токен живёт 5 минут с момента запроса. Если вы реализуете бесконечную сессию через remember_token — убедитесь, что в таблице users есть столбец remember_token, иначе функция сразу выдаст ошибку. И главное: если вы перенесли проект на другой хостинг — перегенерируйте APP_KEY, иначе все пароли станут нечитаемы.

Не делайте так: не пишите кастомную аутентификацию, если не разобрались с тем, что даёт Laravel. 90% ошибок — это когда разработчик пишет свой login с md5. Вы же лучше.

Почему не стоит жалеть 10 минут на настройку

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

Гарантия того, что вы всё сделали правильно, — это когда каждый вход в систему записывается в таблицу successful_logins, а каждый неудачный — в failed_logins. Заведите такую модель — это займёт 15 минут. А теперь подумайте: стоит ли 15 минут вашего времени сохранности целой базы?

Добавлено: 23.04.2026