Documentation
How the .env exposure check works
Last updated
Overview
A check has three stages:
- Validation. The domain you enter is normalized (lower-cased, internationalized names converted to punycode) and rejected if it is an IP address, contains credentials or a port, or is a local or reserved name. It must resolve to public IP addresses.
- Ownership verification. You publish a temporary token in DNS or in a file on your website.
- The check. Our server requests a fixed list of paths and classifies each answer.
Ownership verification
When you start, the service generates a random verification token such as ismyenvpublic-verification=8c738dc70ed44e13…. It contains no information about you, is bound to exactly one domain, and expires after about 20 minutes. Publish it in one of two ways:
DNS TXT record
Create a TXT record at _ismyenvpublic.example.com (or on the root domain) whose value is the token. We query it directly from DNS. Propagation usually takes seconds to a few minutes, depending on your provider.
Verification file
Serve a plain-text file at https://example.com/.well-known/ismyenvpublic.txt containing only the token. The request follows at most three redirects, and only when they stay on the same path and move between http and https or between example.com and www.example.com. A redirect to another domain never counts as proof of ownership.
After successful verification, the check can be run for 30 minutes. You can remove the record or file afterwards.
Exactly which requests are made
For a verified domain, the scanner sends plain GET requests to:
/.env,/.env.local,/.env.production,/.env.prod- one calibration request to a random path that cannot exist, such as
/ismyenvpublic-check-3f9a…, to learn how the site responds to missing resources.
HTTPS is used first. Plain HTTP is used only if HTTPS is unreachable. Requests identify themselves with the user agent IsMyENVPublic/1.0 (+https://ismyenvpublic.org/security), send no cookies, and are limited to a few seconds each. There is no crawling, no brute forcing, no custom paths, no subdomains and no other ports.
How exposure is detected
An HTTP 200 response alone never means that a file is exposed. Many sites answer every path with a custom error page or with the single-page app's index.html. Each response is therefore evaluated on several signals:
| Signal | What we look at |
|---|---|
| Status code | 404/410 mean not found, 401/403 mean access denied, 429 and 5xx make the path inconclusive. |
| Redirects | A redirect to a different path (for example a login page) means the file is not served. It is noted, not followed. |
| HTML detection | Content-Type, a leading doctype or <html> tag, or several typical tags mark the response as a web page rather than a configuration file. |
| Calibration comparison | A normalized fingerprint and the size of the response are compared with the response to the random path. Matching answers are soft-404 pages. |
| Environment syntax | Lines of the form KEY=value (optionally prefixed with export) are counted and compared with the number of non-comment lines. Key names are matched against common configuration patterns such as APP_*, DB_*, DATABASE_*, REDIS_*, MAIL_*, AWS_*, API_*, *SECRET*, *TOKEN* and *PASSWORD*. |
| Firewalls and CDNs | Challenge and block pages from common web application firewalls are recognized. A challenge on every request makes the result inconclusive. |
A response is classified as exposed with high confidence when it is not HTML, at least three lines are assignments, they make up at least 80% of the content, key names are upper-case and at least one matches a known configuration pattern. Weaker but clear matches get medium confidence. Content that only partly resembles configuration is reported as inconclusive so that you can take a look yourself.
What the results mean
- Safe: every tested path was missing, denied, redirected away or answered with an error page. No exposure was detected by this check. That doesn't mean the website is secure in every other respect.
- Exposed: at least one path returned content with the characteristics of an environment file. Treat the credentials in it as compromised.
- Inconclusive: at least one path could not be evaluated reliably, for example because of a firewall challenge, a timeout, a server error or a redirect to another domain.
What happens to the response content
Contents are analyzed in memory and discarded
Protection against misuse
Because the server makes requests on behalf of users, it is hardened against server-side request forgery (SSRF). Only http and https on the default ports are used. Every DNS answer is validated, and a domain that resolves to any private, loopback, link-local, multicast, reserved or cloud metadata address is refused. Connections go to the validated IP only, so DNS rebinding doesn't work. Every redirect is validated the same way. Verification, checks and token creation are rate-limited per IP address and per domain. Details are on the security page.
Limitations
- Only the four listed paths on the entered hostname (and its www counterpart through redirects) are tested.
- Backup copies such as
.env.bak,.env~or files in subdirectories are not checked. Follow the protection guide to block them all with one rule. - If HTTPS works, plain HTTP is not tested separately. Make sure both server blocks share the same deny rules.
- A result describes a single moment. Re-run the check after deployments and configuration changes.