Почему index.php находится в папке public, а не в общей папке?

Если вы знакомы со структурой сайта libArea, то знаете, что файл index.php находится в папке public. Это хорошая идея держаться index.php за пределами корневого каталога вашего проекта:

Публичный каталог (public)

Публичный каталог (/public) является домом для всех общедоступных и статических файлов вашего приложения, включая изображения, таблицы стилей и файлы JavaScript. Там же находится index.php.

Другие фреймворки и приложения PHP могут использовать другой подход и добавлять index.php файл непосредственно в root каталог. Пока вы направляете сервер в «общедоступный» каталог, содержащий index.php файл, сайт должен отображаться так, как ожидалось.

В LibArea файл index.php находится в public папке с другими «безопасными для просмотра» ресурсами, такими как css, js, изображения и т.д. Это способствует хорошей практике безопасности, чтобы общедоступные файлы были общедоступными, а частные файлы — частными.

Поощряйте надлежащие методы обеспечения безопасности, чтобы общедоступные файлы были общедоступными, а другие, нет.

Но как насчет приложений, которые добавляют index.php в корень?

Есть много популярных веб-приложений, которые не следуют этой структуре и предоставляют index.php в корневом каталоге.

Существует (если обобщать и упрощать) два подхода.

Использование папки /public — это подход к безопасности с использованием «белого списка», означающий, что все запрещено, кроме того, что находится в белом списке (все в общей папке).

Неиспользование папки /public — это подход к безопасности с использованием «черного списка», означающий, что разрешено все, кроме того, что занесено в черный список (правила, определенные в файле конфигурации вашего веб-сервера).

LibArea использует подход «белого списка» к веб-безопасности. Это сделано потому, что мы считаем, что держать весь наш системный код в корневой папке — не очень хорошая идея. (Аналогично обстоят дела и с Content Security Policy).

Настройка веб-сервера (для локальной отладки)

Пример конфигурации для XAMPP, PHP 8.1.2, httpd-xampp.conf:

<VirtualHost *:80>
    ServerAdmin webmaster@lib.loc
        DocumentRoot "d:/xampp/htdocs/lib.loc/public"
        ServerName lib.loc
    ServerAlias www.lib.loc
    ErrorLog "d:/xampp/htdocs/lib.loc/error.log"
        CustomLog "d:/xampp/htdocs/lib.loc/access.log"
    <Directory "d:/xampp/htdocs/lib.loc/public">
        Require all granted
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

Или для пакета: XAMPP для Windows 8.1.4 (PHP 8.1.4), файл (httpd-vhosts.conf):

<VirtualHost *:80>
    ServerAdmin webmaster@lib.loc
    DocumentRoot "D:/xampp/htdocs/lib.loc/public"
    ServerName lib.loc
</VirtualHost>

Больше информации: https://libarea.com/ru/web-server-configuration/

P.S. обычно техническая поддержка хостинга (если вы объясните ей ситуацию по поводу public) знает о чем разговор и довольно охотно поможет сделать подобающие настройки. Тем более подобная практика применяется и в некоторых других приложениях.

Если уж разговор зашел про локальный хостинг, то можно ещё столкнуться при авторизации с ошибкой: Protected from CSRF

Чтобы исправить её необходимо закомментировать 2 строки в файле: public/.htaccess

# php_value session.cookie_httponly 1
# php_value session.cookie_secure 1

И если есть, то это:

#  <IfModule mod_headers.c>
#    Header onsuccess edit Set-Cookie ^(.*) "$1; SameSite=Strict; HttpOnly; Secure"
#  </IfModule>

На реальном хостинге всё должно работать…

English:

Using a /public folder is a white-list approach to security, meaning everything is banned except for the things that are white listed (everything in the public folder).

Not using a /public folder is a black-list approach to security, meaning everything is allowed except for things that are black listed (rules defined in your webserver configuration file).

LibArea uses a white-list approach to web security. This is because we don't think it's a good idea to keep all of our system code in the root folder.

The situation is similar with Content Security Policy.