У режимі налагодження Laravel на будь-яку помилку показує детальну сторінку: повідомлення винятку, стек викликів з файлами й рядками, фрагменти коду, параметри запиту. Для API - те саме в JSON (exception, file, line, trace).
Що з цього отримує зловмисник:
- шляхи на сервері й структуру коду - де лежить застосунок, які пакети й версії;
- фрагменти коду навколо помилки - логіку, назви таблиць, іноді секрети в коді;
- SQL-запити з помилок бази - структуру таблиць і колонок;
- значення змінних у стеку - залежно від помилки, це можуть бути дані користувачів чи облікові дані.
Помилку викликати легко: некоректний параметр, зайвий символ в URL, неочікуваний тип у JSON. Сканери в інтернеті цілеспрямовано шукають сторінки налагодження Laravel.
Історичний приклад важкості: у старих версіях Ignition (сторінки помилок Laravel) була вразливість, що в режимі налагодження давала виконання коду на сервері (CVE-2021-3129). Режим налагодження на продакшені перетворив її з «теоретичної» на масово експлуатовану.
Правила:
APP_DEBUG=falseіAPP_ENV=productionна продакшені - завжди;- перевірка при деплої: скрипт розгортання чи health-check, що зупиняється, якщо
APP_DEBUGувімкнено в продакшені; php artisan aboutпоказує поточний режим;- інструменти розробки (Telescope, Debugbar, Horizon, Pulse, Log Viewer) на продакшені - вимкнені або закриті авторизацією (
Gate::define('viewTelescope', ...)). Debugbar на продакшені розкриває SQL-запити, сесії й заголовки кожного запиту; - сторінки помилок - власні, без деталей (
resources/views/errors/500.blade.php), а деталі - в логах і системі моніторингу (Sentry, Flare).
Для налагодження продакшену - логи й моніторинг помилок з контекстом запиту, а не тимчасове ввімкнення APP_DEBUG («на хвилинку» - досить, щоб сканер його помітив).
Пов'язані витоки з тієї ж категорії: доступні через вебсервер .env, .git, storage/logs, phpinfo(). Корінь вебсервера має вказувати на public/, а не на корінь проєкту.