# Exposed files on your website: .env, .git, backups and logs

> Which files on your website anyone can download (.env, .git, .sql backups, debug.log or PrestaShop var/logs), how to check for them and how to block them.

URL: https://webintacta.com/en/guides/exposed-files-website
Language: English (Spanish version: see the hreflang alternate of the HTML page)
Last updated: 2026-10-24

**In short:** An exposed file is one anyone can download by typing its address, without breaking into your site: a forgotten .zip or .sql backup in the web root, the .env file or a wp-config.php.bak with passwords, the .git folder, or error logs (debug.log in WordPress, var/logs in PrestaShop). You check by requesting those paths in a browser; they should return a 403 or 404 error. You fix it by deleting or blocking them on the server and, if they held passwords or keys, changing them: deleting the file does not undo a download that already happened.


By Jose Soriano (WebIntacta) · published 2026-10-24

Of everything the external scan finds, this is what surprises site owners most: nobody has to hack a website to get its passwords if someone left a copy in the public folder. It happens with backups made by hand before a migration, with sites deployed with Git, with debug mode left on, or with backup plugins that save the archive where they should not. It is easy to check and easy to fix, and here is how.

## Which files get left in the open

| File or folder | What it contains | Why it matters |
| --- | --- | --- |
| `.env` | Database passwords, API, payment and email keys | With it, someone can get into your database or use your Stripe or email keys |
| `wp-config.php.bak`, `.old`, `.save`, `~` | A copy of the WordPress configuration | The original `.php` is not visible, but a copy with another extension downloads as plain text, passwords included |
| `.zip`, `.tar.gz`, `.sql` backups | The whole site or the database | A database backup from a store contains customer data |
| `.git` folder | The code and its history | The history often keeps passwords someone committed by mistake and later "deleted" |
| `wp-content/debug.log` | WordPress errors | Server paths, plugin names and sometimes form data |
| `var/logs/` (PrestaShop 1.7, 8 and 9) | Store logs | Errors with internal paths and sometimes order or customer data |
| `phpinfo.php`, `info.php` | The full PHP configuration | Exact versions and paths: a map for looking up known flaws |
| Directory listing ("Index of /") | The list of files in a folder | Reveals backups and files nobody knew were there |

The most common ones on small business sites and online stores. The free scan checks these and other common names.

## How to check your site

Type your domain followed by each path into a browser: `https://your-site.com/.env`, `https://your-site.com/.git/config`, `https://your-site.com/wp-content/debug.log` or `https://your-site.com/var/logs/`. The right answer is a **403 (Forbidden)** or **404 (Not Found)** error. If a file downloads or you can see its contents, it is exposed.

With `curl` you see only the response code, without downloading anything:

```
for p in .env .git/config wp-config.php.bak wp-content/debug.log var/logs/ backup.zip; do
  printf "%-28s %s\n" "$p" "$(curl -s -o /dev/null -w "%{http_code}" "https://your-site.com/$p")"
done
```

Watch out for misleading results: some sites answer **200** with a normal page (a styled "not found" page) for any address. If you get 200, open the path in a browser and see what comes back. Also go through the public folder with your hosting file manager: look for `.zip`, `.sql`, `.tar.gz` and `.bak` files and folders with names like `backup`, `old` or `copy`.

The [free scan](https://webintacta.com/en/free-website-security-scan) tries these paths and other common ones (configuration backups, database dumps, `.git`, `.env`, WordPress and PrestaShop logs, directory listings) and tells you which ones are open.

## How to fix it

### 1. Delete or move out of the public folder what should not be there

Backups do not belong in `public_html` or in any folder served on the web: they go off the server or, at the very least, in a folder above the public root. Leftover test files such as `phpinfo.php` and `.bak` copies: delete them. If you deploy with Git, the `.git` folder should not be on the server; if it has to be, block it.

### 2. Turn off whatever writes public logs

In WordPress, debug mode is not for a live site. In `wp-config.php`, `WP_DEBUG` and `WP_DEBUG_LOG` should be `false`. If you need the log for a while, `WP_DEBUG_LOG` accepts a path outside the public folder instead of `true`. In PrestaShop, make sure debug mode is off (**Advanced Parameters → Performance**) and that `var/logs/` is not served on the web.

### 3. Block them on the server

Even if you delete today's files, someone may leave another backup tomorrow. A server rule prevents it. On **Apache** (and LiteSpeed), in the `.htaccess` in the site root:

```
# No directory listings
Options -Indexes

# Hidden files (.env, .git, .htpasswd...) except .well-known
RewriteEngine On
RewriteRule "(^|/)\.(?!well-known/)" - [F]

# Backups, dumps and logs
<FilesMatch "\.(sql|bak|old|orig|save|swp|log|tar|gz|zip)$">
  Require all denied
</FilesMatch>
```

On **Nginx**, inside the `server` block:

```
autoindex off;

location ~ /\.(?!well-known) {
  deny all;
}

location ~* \.(sql|bak|old|orig|save|swp|log|tar|gz|zip)$ {
  deny all;
}

# PrestaShop: logs and cache
location ~ ^/var/ {
  deny all;
}
```

> Two things to watch. The `.well-known` folder must stay open: Let's Encrypt certificates and files such as security.txt use it. And if your site offers legitimate `.zip` downloads (a catalog, downloadable products served directly), adjust the extension rule so they are not blocked. Test the changes on a copy, or right after applying them.

`.htaccess` rules only work on Apache and LiteSpeed. If your server runs Nginx, which is common with some hosting providers and on self-managed servers, the rules go in its configuration: ask your provider if you do not have access.

## If it was already exposed

Deleting the file closes the door, but you do not know whether someone downloaded it first. Treat it as a leak:

1. **Change everything it contained:** the database password (and update it in the site's configuration), API, payment and email keys. In WordPress, also regenerate the security keys in `wp-config.php`.
2. **Check the access logs** for that path with a 200 response: it tells you whether someone downloaded it and when (`grep "/.env" access.log | grep " 200 "`).
3. **If it was a database backup with customer data**, it may be a personal data breach, which under the GDPR has to be reported to the supervisory authority within 72 hours (in Spain, the AEPD; elsewhere, your country's authority). I explain it in [data breach at your online store](https://webintacta.com/en/guides/online-store-data-breach-gdpr).
4. **Check whether the site is compromised:** with the database or admin passwords, someone could have got in. The signs are in [how to tell if your website is hacked](https://webintacta.com/en/guides/how-to-tell-if-website-is-hacked).

## If you would rather I do it

The [free scan](https://webintacta.com/en/free-website-security-scan) tells you in a few minutes which files you have open. If you want me to fix it, the report + hardening package (€299, excluding VAT) includes the [security report](https://webintacta.com/en/website-security-audit) and up to three hours to close the urgent issues: deleting or moving the files, adding the server rules and changing the affected keys. With [website maintenance](https://webintacta.com/en/website-maintenance), the regular scan warns you if one shows up again.

## Sources

- [OWASP WSTG: review old backup and unreferenced files for sensitive information](https://wstg.owasp.org/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information) (copies with another extension that download as text, compressed archives and editor backup files).
- [WordPress: debugging in WordPress](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) (`WP_DEBUG_LOG` saves `debug.log` in the content folder, and debugging is not recommended on live sites).
- [Apache: access control](https://httpd.apache.org/docs/2.4/howto/access.html) and [the Options directive](https://httpd.apache.org/docs/2.4/mod/core.html#options) (`-Indexes`).
- [nginx: access module](https://nginx.org/en/docs/http/ngx_http_access_module.html) and [autoindex](https://nginx.org/en/docs/http/ngx_http_autoindex_module.html).
- [RFC 8615: the /.well-known/ path](https://www.rfc-editor.org/rfc/rfc8615) (reserved paths that must stay accessible).
- [AEPD (Spain's data protection authority): personal data breach notification](https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion) (72-hour deadline; in Spanish).

## Frequently asked questions

### How do I know if my .env file is exposed?

Open your domain followed by /.env in a browser. If you see text with passwords or a file downloads, it is exposed; the right answer is a 403 or 404 error. If it was open, block it and also change every key it contained.

### Is it dangerous to have the .git folder on the server?

Yes, if it can be downloaded: it lets someone rebuild the code and its history, which often keeps old passwords. Best not to deploy it at all; if it has to be there, block it on the server.

### What is the WordPress debug.log and should I delete it?

It is the error log WordPress creates in wp-content when WP_DEBUG_LOG is on. On a live site, turn debugging off, delete the file and block .log files on the server.

### Why can anyone see my PrestaShop logs?

Because the var/logs folder (or log/ in PrestaShop 1.6) relies on server rules to stay private. On Nginx, .htaccess rules are not applied, so the folder has to be blocked in the server configuration.

### I had a database backup in the open. What do I do?

Delete it or move it out of the public folder, change the database password and check the logs for whether someone downloaded it. If it held customer data, assess with your advisor whether you have to report a breach to your supervisory authority (the AEPD in Spain) within 72 hours.

## About the author

[Jose Soriano](https://webintacta.com/en/about): Full-stack developer specialized in PrestaShop, WordPress and WooCommerce, who has passed the official PrestaShop course and exam. He has been building online stores and modules since 2023 and is the founder of WebIntacta, the website security service through which he scans, cleans and maintains small-business websites and online stores himself, remotely from Ibi (Alicante, Spain). WebIntacta facts: https://webintacta.com/en/about#datos