Почему всегда рекомендуется размещать файлы фреймворка вне публичного корня?
Учитывая, что иногда в фреймворке нет файлов .ini или .inc которые могут быть открыты браузером.
Ну, безусловно, нет ничего, что можно было бы получить от размещения исходных текстов в корневом каталоге. Поскольку выбор места для размещения файла является бесплатным, логично следовать принципу наименьших привилегий : вам не нужен веб-доступ к этим файлам, поэтому вы его не получите.
Более конкретная причина заключается в том, что базовые источники могут легко раскрывать бренд и версию структуры, используемой на веб-сайте (хотя эту информацию также можно получить, исследуя сгенерированный контент); это, в свою очередь, облегчит злоумышленникам использование известных или недавно обнаруженных уязвимостей.
Это безопаснее, потому что, если в веб-сервере есть некорректная конфигурация, возможно, что файлы сценариев (будь то .php, .asp или что-то еще) можно выплюнуть в текстовом виде, а потенциальный злоумышленник увидит весь ваш исходный код и определенные пароли. Поэтому лучше всего поставить только файл index.php в webroot, который, в свою очередь, включает скрипт начальной загрузки извне webroot.
Я помню один пример в реальном мире – в Латвии, где я живу, у нас есть большая социальная сеть «draugiem.lv» (в нашей стране более популярна, чем Facebook), и несколько лет назад весь их исходный код PHP просочился неправильно сконфигурированным сервером, как я описал ранее.
В дополнение к стандартным причинам, приведенным в других ответах: неверная конфигурация сервера, принцип наименьших привилегий и т. Д., Стоит отметить, что многие фреймворки, включая Zend Framework, могут использовать файлы конфигурации, которые находятся в форматах, отличных от PHP, например, .ini , .yml и т. д.
Если они были в общедоступном веб-корне, тогда – в зависимости от конфигурации сервера – они будут поданы непосредственно любому, кто их запрашивает. Поскольку эти файлы конфигурации обычно содержат конфиденциальную информацию, такую как пароли db, API-ключи и т. Д., Безусловно, желательно сделать их недоступными как можно недоступными.
В качестве примера рассмотрим application/configs/application.ini . Если корень doc находился на уровне папки проекта, тогда запрос для:
http://example.com/application/configs/application.ini
доставит ключи в замок.