Открытые служебные файлы на сайте: как проверить .env, .git и бэкапы

Открытые служебные файлы — один из самых простых и опасных рисков на сайте. Если из браузера доступны .env, .git, dump.sql, backup.zip, phpinfo.php или composer.json, злоумышленник может получить пароли, исходный код, структуру базы, зависимости и техническую информацию о сервере.

Проблема часто появляется после переноса, временного бэкапа, отладки или неправильного document root.

Что проверять

Минимальный список опасных файлов и директорий:

• /.env;
• /.git/config;
• /composer.json;
• /composer.lock;
• /backup.zip;
• /dump.sql;
• /database.sql.gz;
• /phpinfo.php;
• /test.php;
• /adminer.php.

Не все файлы одинаково критичны, но каждый из них может дать лишнюю информацию.

Проверка через curl

Нужно проверять не только в файловой системе, но и по HTTP.

curl -I https://example.ru/.env
curl -I https://example.ru/.git/config
curl -I https://example.ru/composer.json
curl -I https://example.ru/backup.zip

Хороший результат — 403 или 404. Если файл отдаётся с кодом 200, это проблема.

.git в публичной директории

Если .git доступен из web root, можно получить историю, исходники и конфиги репозитория. На production .git лучше не держать в публичной директории или надёжно закрыть доступ.

location ~ /\.git {
    deny all;
}

Для Apache:

RedirectMatch 404 /\.git

.env и конфиги

.env часто содержит пароли базы, ключи API, SMTP-доступы, токены и секреты. Он не должен лежать в доступной из браузера директории.

location ~ /\.(env|ini|log|sql|bak)$ {
    deny all;
}

Но лучше не полагаться только на deny. Правильный document root должен смотреть в публичную папку, а конфиги должны быть уровнем выше.

Бэкапы в корне сайта

Файлы backup.zip, site.tar.gz, dump.sql часто временно кладут в корень сайта и забывают. robots.txt не защищает такие файлы. Если URL известен или угадывается, файл можно скачать.

find /var/www/site.ru -type f \( -name "*.sql" -o -name "*.zip" -o -name "*.tar.gz" -o -name "*.bak" \) -exec ls -lh {} \;

Бэкапы нужно хранить в закрытой директории или внешнем хранилище, а не рядом с index.php.

phpinfo.php

phpinfo показывает версию PHP, расширения, пути, переменные окружения и настройки. На production такой файл нужно удалять сразу после диагностики.

find /var/www/site.ru -type f -iname "*phpinfo*" -o -name "info.php"

composer.json и composer.lock

Эти файлы не всегда содержат секреты, но раскрывают стек, пакеты и версии. Это помогает подобрать известные уязвимости. Лучше не отдавать их публично.

Проверить document root

Для современных проектов public-директория должна быть web root. Например:

/var/www/site.ru
    app/
    config/
    vendor/
    web/
        index.php

nginx должен смотреть в web:

root /var/www/site.ru/web;

Если root смотрит на весь проект, наружу могут попасть config, vendor, .env и другие служебные файлы.

Чек-лист

1. Проверить .env, .git/config, composer.json по HTTP.
2. Найти архивы и дампы в директории сайта.
3. Удалить phpinfo.php и тестовые скрипты.
4. Закрыть скрытые файлы через nginx или Apache.
5. Проверить document root.
6. Вынести конфиги выше публичной директории.
7. Хранить бэкапы вне web root.
8. Повторить проверку после деплоя и переноса.

Служебные файлы не должны быть частью публичного сайта. Даже если “никто не знает URL”, это не защита. Такие файлы быстро находятся сканерами и часто становятся входной точкой для взлома.