Fundamentals
What is a .env file?
The dotenv format, where it comes from, what usually lives inside, and why it must stay private.
7 min read
Free defensive check · Ownership verified · Nothing stored
Is your .env public?
Check whether sensitive environment configuration files are accidentally exposed on your website.
- No secrets stored
- Ownership verification
- Safe server-side check
- Results in seconds
$ ismyenvpublic check example.com
✓ ownership verified (DNS TXT)
| Path | HTTP status | Result |
|---|---|---|
| GET /.env | 404 | not found |
| GET /.env.local | 403 | access denied |
| GET /.env.production | 200 | app fallback page, no config data |
| GET /.env.prod | 404 | not found |
No exposed .env detected
How it works
Three steps. About a minute.
- 01
Enter your domain
Type the domain you want to check. We validate it and make sure it points to a public website.
- 02
Verify ownership
Add a temporary DNS TXT record or a small file under /.well-known. Checks only run on domains you control.
- 03
Run the check
We request four well-known environment file paths and analyze the responses in memory. Nothing is kept.
Curious about the details? Read how the check and the detection work.
Why does this matter?
A .env file is configuration, not content.
Many frameworks read settings from a .env file: database connection details, API credentials, mail server logins, encryption keys and service configuration.
The file is meant to be read by your application on the server. If it ends up inside the directory your web server publishes, or a rule that should block it is missing, anyone who requests /.env can download it. Automated scanners request these paths constantly, so an exposure rarely stays unnoticed for long.
Checking takes a minute. Fixing a leaked database password or cloud key usually takes much longer, which is why it is worth verifying after every server change.
# Application
APP_KEY=••••••••••••
# Database
DB_HOST=••••••••
DB_PASSWORD=••••••••••••
# Third-party services
MAIL_PASSWORD=••••••••
AWS_SECRET_ACCESS_KEY=••••••••••••
STRIPE_SECRET_KEY=••••••••••••Built to be defensive
A narrow check, on purpose.
What the check does
- Runs only after you prove control of the domain
- Requests four fixed paths and one random calibration path
- Tells custom 404 pages and app fallbacks apart from real config files
- Reports only a status, the path and a confidence level, never values
What it never does
- No crawling, directory brute forcing or custom paths
- No subdomain enumeration or port scanning
- No exploitation attempts and no requests to internal networks
- No storage of response contents, secrets or scan history
Fix guides
Protect your environment files
Fundamentals
How to protect your .env file from public access
Keep secrets out of the web root, block dotfiles, and know what to do after an exposure.
9 min read
Web servers
How to block .env files in Nginx
Location blocks that deny dotfiles, keep /.well-known reachable, and survive config refactors.
8 min read
Web servers
How to block .env files in Apache
Require all denied for dotfiles in the vhost or .htaccess, and the AllowOverride trap.
7 min read
Frameworks
Laravel .env security
Point the document root at public/, disable debug mode, cache config and rotate APP_KEY safely.
9 min read
Frameworks
Node.js .env security
Static file middleware, public env prefixes in bundlers, Docker images and secret managers.
9 min read
Questions
Good to know
- Why do I have to verify ownership?
- Checking for exposed configuration files on someone else's website would be reconnaissance. Verification makes sure the check is only used by people responsible for the domain.
- Which paths are checked?
- Exactly four: /.env, /.env.local, /.env.production and /.env.prod, plus one request to a random non-existent path to learn how your site answers for missing files. No crawling, no brute forcing.
- Do you see or store my secrets?
- If a file is exposed, its content is inspected in memory only to recognize the KEY=value format and then discarded. Values are never returned to your browser, written to logs or stored.
- Does a green result mean my website is secure?
- No. It means no exposure was detected for the tested paths at the time of the check. Other files, backups or misconfigurations are outside the scope of this check.
One click. One check. No exposed secrets.
Verify your domain and find out in seconds whether your environment file is reachable.