Laravel - это мощный PHP-фреймворк, который сам по себе предлагает много встроенных механизмов безопасности. Но даже при правильном выборе инструментария слабое место часто оказывается не в ядре фреймворка, а в том, как мы его используем. Маленькая оплошность, копипаста из Интернета или спешка может привести к ситуации где одна из ваших страниц может быть точкой входа для злоумышленника.
Защита от CSRF есть, пока вы её не отключите
Laravel по умолчанию защищает приложение от межсайтовой подделки запросов (CSRF).
Но если вы забудете добавить токен или намеренно его отключите, эта защита перестанет работать.
Как избежать ошибки:
Во всех HTML-формах обязательно используйте
@csrf.Для AJAX-запросов добавляйте заголовок
X-CSRF-TOKENиз метатега.
Пример безопасной формы:
<form method="POST" action="/profile/update">
@csrf
<input type="text" name="name">
<button type="submit">Сохранить</button>
</form>SQL-инъекции: современные фреймворки не уберегают от ошибок разработчика
Laravel защищает вас от SQL-инъекций если вы используете Eloquent или query builder правильно.
Частая ошибка:
$users = DB::select("SELECT * FROM users WHERE email = '$email'");Почему это опасно:
Строка может содержать вредоносный ввод, позволяя выполнить произвольные SQL-команды.
Правильный подход:
$user = User::where('email', $email)->first();Или, если вы вынуждены использовать сырые запросы, то обязательно параметризируйте:
$users = DB::select('SELECT * FROM users WHERE email = ?', [$email]);Laravel автоматически экранирует параметры, нейтрализуя потенциальные атаки.
XSS-атаки: почему стоит доверять Blade
Cross-Site Scripting (XSS) возникает, когда небезопасный ввод выводится в браузер без фильтрации.
Опасная практика:
{!! $message !!}Это отключает экранирование, и, если злоумышленник поместил script-код, он будет выполнен у всех пользователей.
Что делать:
Используйте стандартный синтаксис
{{ $variable }}, он автоматически экранирует HTML.Если вам всё же нужно выводить HTML, обрабатывайте его заранее (например, через
strip_tagsили сторонний санитайзер).
"Mass Assignment" - скрытая угроза правам доступа
Mass assignment - это когда вы массово заполняете модель данными из запроса, не фильтруя поля:
User::create($request->all());Если в модели нет ограничения, злоумышленник может изменить поля вроде is_admin или role.
Как исправить:
Определите массив
$fillableв модели только с доверенными полями.Или используйте
$request->only(['name', 'email'])вместоall().
Не оставляйте отладку включённой в продакшене
Когда APP_DEBUG=true, Laravel показывает детали ошибок, трассировки стека, имена файлов и другие данные, которые легче всего использовать злоумышленнику.
Настройка для правильной эксплуатации:
APP_ENV=production
APP_DEBUG=falseТакие настройки гарантируют, что наружу не вытекут внутренние данные приложения.
Обработка загрузки файлов гораздо опаснее, чем кажется
Разрешение на загрузку файлов без строгой проверки расширений, размеров и MIME-типа это частая дверь для атак.
Правильная валидация:
$request->validate([
'file' => 'required|file|mimes:jpg,jpeg,png,pdf|max:2048',
]);И дополнительные меры безопасности:
Храните файлы за пределами публичной директории.
Переименовывайте файлы при сохранении.
Не допускайте загрузки исполняемых форматов.
Уязвимость .env и APP_KEY
Если файл .env станет доступным извне, в чужие руки попадут:
пароли от базы данных;
ключи API;
сессионные ключи (
APP_KEY).
Что делать:
Никогда не коммитьте
.envв репозиторий.Храните
.envтолько на сервере и защищайте доступ к нему.При утечке сразу меняйте
APP_KEY(учтите: это инвалидирует текущие сессии).
Laravel может многое, но безопасность гарантирована лишь тогда, когда вы:
используете встроенные механизмы по назначению;
тщательно проверяете ввод;
внимательно настраиваете среду и деплой;
и не игнорируете базовые принципы защищённой разработки.
Лучшие инструменты и фреймворки не заменяют здравый смысл и дисциплину в коде.