Почему запуск Flask-приложения с app.run(debug=True) считается опасным в production-окружении?

Короткий ответ

Режим debug=True включает интерактивный веб-дебаггер Werkzeug, который при необработанном исключении позволяет выполнять произвольный Python-код в браузере через консоль отладчика — это критическая угроза безопасности при доступности приложения извне.

Как это работает подробнее

В debug-режиме Flask (через Werkzeug) перехватывает необработанные исключения и показывает подробную трассировку с интерактивной консолью на каждом кадре стека; эта консоль по умолчанию защищена только PIN-кодом, который при определённых условиях можно подобрать или который виден в логах запуска.

Пример кода

example.pyКопировать

# Плохо для production:
app.run(debug=True, host="0.0.0.0")
# Лучше для production: запуск под gunicorn, debug выключен
# gunicorn -w 4 -b 0.0.0.0:8000 myapp:app
# и app.config["DEBUG"] = False (или переменная окружения FLASK_DEBUG=0)

Что использовать на практике

• Практика. Debug-режим полезен только на локальной машине разработчика, недоступной из интернета. В production используют debug=False (или вообще не запускают через встроенный app.run, а используют production WSGI-сервер — gunicorn/uWSGI) и отдельный централизованный логгер ошибок (например, Sentry).

Подводные камни

• Риск. Включают debug=True «для удобства отладки» на staging/production сервере, доступном извне; путают debug=True (небезопасный интерактивный дебаггер) с обычным подробным логированием, которое безопасно включать и в production.