Exposed .env and .git Files: A Common, Critical Mistake
Some of the most damaging findings require no exploit at all. An attacker requests https://example.com/.env, and the server returns the database password, cloud keys and payment API secrets. Automated scanners request these paths across the internet every day.
Files attackers request
| Path | What it may contain |
|---|---|
/.env, /.env.production, /.env.local | Database credentials, API keys, signing secrets |
/.git/config, /.git/HEAD | Indicates an exposed repository, enabling full source download |
/config.php.bak, /wp-config.php~ | Editor and backup copies with credentials |
/backup.zip, /site.tar.gz, /db.sql | Full site or database backups |
/.DS_Store | Directory listings revealing other files |
/*.js.map | Source maps exposing original frontend code |
/phpinfo.php | Server configuration and environment variables |
/.aws/credentials, /.npmrc, /.docker/config.json | Cloud, registry and package tokens |
/server-status, /debug, /actuator/env | Runtime and environment data |
How they get exposed
- Deploying the whole project directory to the web root, including dotfiles.
- Web servers configured to serve every file in a directory.
- Copying files to the server manually and leaving backups behind.
- Build tools that output source maps or environment files into public folders.
- Frameworks with debug or management endpoints enabled in production.
Why an exposed .git directory is so serious
If /.git/ is accessible, attackers can reconstruct your entire repository, including history. That means all source code, every secret ever committed, internal URLs and comments. It also reveals vulnerabilities for targeted attacks.
Prevention
- Deploy build output only, not the project directory. The web root should contain only files meant to be public.
- Block dotfiles at the web server, for example denying any path segment beginning with a dot, except
/.well-known/. - Keep secrets out of files on web servers; use a secrets manager or platform environment variables.
- Disable directory listing.
- Do not create backups in the web root.
- Decide deliberately about source maps: upload them to your error tracker instead of serving them publicly, or accept that frontend code is visible and ensure it contains no secrets.
- Disable debug and management endpoints in production, or protect them with authentication and network restrictions.
If you find an exposed file
- Remove access immediately.
- Rotate every secret the file contained.
- Check logs for requests to that path, to estimate exposure.
- Investigate use of the exposed credentials.
Checking your sites
Check every domain and subdomain, not just the main site: old staging servers and marketing sites are frequent culprits. SecurityInfinity's scanners check all discovered hosts for exposed environment files, repositories, backups, source maps and debug endpoints, and confirm what is accessible. Start free.
Frequently asked questions
Are .env files safe in Next.js or Vite projects?
They are safe on your machine and build server. The risk is serving them publicly or embedding private values into client bundles via public environment variable prefixes.
Is it bad to serve source maps?
They expose original source code, which aids attackers. If your frontend contains no secrets, risk is moderate, but many teams prefer not to serve them publicly.
How do attackers find these files?
Automated scanners request common sensitive paths on every host they discover, often within hours of a site going live.