How to Find an Exposed .env or .git File on Your Site

In short

An exposed .env or .git folder means your web server is handing your private configuration file to anyone who asks for it by name, no login required. These files often hold database passwords and API keys in plain text. SiteHealth's exposed-private-files check looks for exactly this on verified sites. You can also check it yourself in under a minute using nothing but a browser address bar.

Why do .env and .git files end up public?

They end up public because the file sits inside the folder your web server shows to visitors, and nothing tells the server to refuse it. A .env file is meant to live one level above your site's public folder, read only by your application code. When a project gets copied, deployed, or set up in a hurry, that file sometimes lands inside the public folder instead, and the server serves it like any other file on request.

The same thing happens with .git. Every folder built with Git has a hidden .git subfolder holding the entire project history. If a site gets deployed by copying the whole project folder onto the server, rather than exporting just the finished files, that .git folder travels along with it and sits reachable at yoursite.com/.git/config.

Three deployment habits cause most of these leaks in practice. First, dragging a whole project folder onto a server over FTP, which copies every hidden file along with the ones you meant to publish. Second, pointing the web server's public folder at the project root instead of a dedicated public/ subfolder, so anything sitting next to your code is reachable by name. Third, restoring from a backup zip that was made by compressing the entire project directory rather than exporting a clean build.

Is a phpinfo() page or a browsable folder the same problem?

Not exactly the same file, but the same category of mistake: a page or folder that was useful once, while building the site, and was never removed or locked down before launch. A phpinfo() page lists your exact server software versions, file paths, and loaded modules on one page, which hands an attacker a shortlist of known vulnerabilities to try against your specific setup. A browsable folder is a directory with no index.html or index.php inside it, which many servers respond to by listing every file in that folder as a clickable page — including backup files, old versions of pages, or spreadsheets someone uploaded and forgot about.

Check for both the same way you checked for .env: visit yoursite.com/phpinfo.php, yoursite.com/info.php, and any folder that sounds like it might hold uploads, backups, or admin tools, such as /uploads/, /backup/, or /admin/. A file listing instead of your normal page design means that folder is browsable.

How do I check if my .env file is exposed?

You check by requesting the file directly in a browser and reading what comes back. A correctly configured server returns a 403 or 404 error page. An exposed server returns the actual contents of the file.

1. Open a private or incognito browser window, so cached pages do not fool you.
2. Type https://yoursite.com/.env into the address bar and press enter.
3. Read the response. An error page, a blank page, or a redirect to your homepage all mean the file is not reachable.
4. If you instead see lines like DB_PASSWORD= or API_KEY= followed by real-looking values, the file is exposed.
5. Repeat with any other config file names your platform uses, such as .env.local, .env.production, or config.php.bak.
6. If your host lets you check server logs, search them for repeated requests to .env from IP addresses you do not recognise — that is a sign a scanner already found it.

How do I check for an exposed .git folder?

You check the same way, by requesting a path inside the folder that should never resolve to anything. Type https://yoursite.com/.git/config in a browser. An error page means you are fine. A page of text starting with [core] means your entire commit history, including anything ever committed and later deleted, is downloadable by anyone who knows to look. Also try https://yoursite.com/.git/HEAD — a response of ref: refs/heads/main confirms the same problem from a second angle.

Fixing this is a server configuration change, not a code change: block any request path starting with a dot, and make sure your deployment process copies only the finished, built files to the server rather than the whole project folder including its history.

What should I rotate after a leak?

Rotating means generating a brand-new credential and disabling the old one, not just deleting the exposed file. A file you remove today may already be sitting in someone else's downloaded copy, so the old values inside it stay dangerous until each one is individually replaced. Work through this list for anything that appeared in the exposed file:

• Database password — change it in your hosting control panel, then update the application's configuration to use the new one before you restart the site, or every page will fail to connect at once.
• Any API key for a third-party service — payment processors, email senders, maps, analytics — generate a new key in that service's dashboard and revoke the old one there, not just in your own files.
• Session or app secret keys — replace them, which will log every current user out once. That is a fair trade for closing the leak, and it takes effect the moment the new value is deployed.
• Admin or SMTP account passwords stored in the file — change these directly with the account itself, not just in your config, since the old password still works everywhere else it is used.
• Anything committed to Git history, if a .git folder was exposed — a value that was removed from the current file is still sitting in an old commit, downloadable in full by anyone who pulled the folder before you noticed.

None of this needs to happen in a single afternoon of panic. Rotate the database password and any payment-related key first, since those cause the most damage fastest, then work through the rest of the list over the same day.

Where does this go wrong on AI-built sites?

Sites shipped by AI builders like Lovable, Bolt, v0, or Replit are common candidates for this because the generated project usually includes a working .env file and a full .git history from day one, and moving the whole project to a live domain can carry both along unless someone deliberately strips them out first. Our guide on what to check before pointing a domain at an AI-built site covers the other launch steps worth doing at the same time, and the six-thing launch checklist is a good companion pass if you have not run either yet.

Manually retyping these two URLs after every deploy is easy to forget, which is exactly the kind of silent failure SiteHealth's checks exist for — the exposed-private-files check runs this test automatically on verified sites, alongside the browsable-folders and security-header checks that catch related misconfigurations.

Check your own site now

You do not need an account to find out where you stand. Run the free checker on the SiteHealth homepage — paste in your address and it looks at your site in about twenty seconds, no sign-up required.