Pre-launch security audit

Exposed Files Checklist: What to Scan Before a Website Goes Live

Automated crawlers and vulnerability scanners index new domains within hours of launch. This checklist walks through what to check on your staging environment — before DNS points at it and before those scanners get there first.

• Why timing matters
• What to check for
• HTTP status codes
• Server configuration
• Build artifacts
• Run ExposureCheck
• Launch workflow
• FAQ

Why the staging window matters

Internet-wide scanners — including Shodan, Censys, commercial vulnerability databases, and automated bots — probe large blocks of IP space continuously and index new hostnames within hours of first seeing them. Once a URL returns a 200 response for /.env, that response can be logged, scraped, and retained even if you block the path the next day.

The pre-launch window — your staging environment before DNS cutover, and the first 24 hours post-launch — is the critical moment. Catching an exposed file before launch costs minutes to fix. Catching it after a scanner has already exfiltrated the contents means rotating all exposed credentials, reviewing access logs, and potentially notifying affected users. The gap between those two outcomes is entirely a function of when you check.

What to scan for

These are the ten categories of sensitive paths that ExposureCheck tests for. Each includes the most commonly exposed paths in that category:

Reading HTTP status codes

When you probe a path manually with curl -I, the response status code tells you exactly what's happening:

Quick manual check with curl (use -I for HEAD requests — no body download, faster):

# Check specific paths on staging
curl -I https://staging.yoursite.com/.env
curl -I https://staging.yoursite.com/.git/config
curl -I https://staging.yoursite.com/wp-config.php.bak

# Check for directory listing
curl https://staging.yoursite.com/uploads/
# Look for "Index of /" in the response body

Blocking sensitive paths in server configuration

The right fix is a server-side block. Deleting files from the web root is better still — but if they might reappear on the next deploy (e.g., a .env copied by a deploy script), a server rule is the reliable safety net.

nginx

# Block dotfiles and common sensitive paths
location ~ /\. {
    deny all;
    return 404;
}
location ~* \.(sql|bak|backup|old|orig|log|gz|tar)$ {
    deny all;
    return 404;
}
location ~* /(credentials|serviceAccountKey|private|id_rsa)\.json$ {
    deny all;
    return 404;
}
# Disable directory listing
autoindex off;

Apache (.htaccess)

<FilesMatch "^(\.env|\.git|\.DS_Store|wp-config\.php\.bak|credentials\.json)$">
  Order allow,deny
  Deny from all
</FilesMatch>

<FilesMatch "\.(sql|bak|backup|old|orig|log|gz)$">
  Order allow,deny
  Deny from all
</FilesMatch>

# Disable directory listing
Options -Indexes

Vercel (vercel.json)

{
  "rewrites": [
    { "source": "/\\.env(.*)", "destination": "/404" },
    { "source": "/\\.git(.*)", "destination": "/404" },
    { "source": "/credentials.json", "destination": "/404" }
  ]
}

Netlify (_redirects)

/.env          /404.html  404
/.git/*        /404.html  404
/backup.sql    /404.html  404

Build artifact checklist

Modern JavaScript build pipelines (Vite, webpack, Next.js) introduce their own exposure risks if not configured carefully. Before launch, verify:

• Source maps match your policy. In Vite: build.sourcemap = false (or 'hidden' for error tracking without public access). In Next.js: productionBrowserSourceMaps: false is the default.
• .env files absent from build output. Run ls -la dist/ and ls -la build/ — no .env* files should appear there.
• Environment variables embedded in the bundle. React/Vue/Svelte frameworks using VITE_ or REACT_APP_ prefixes embed those values in the JS bundle. Only public-facing values (analytics IDs, public endpoints) should use these prefixes — never private keys or secrets.
• node_modules/ not deployed. Confirm node_modules/ is absent from your web root. This can happen with misconfigured rsync or FTP deployments that copy the entire project directory.

Running ExposureCheck on your staging site

ExposureCheck probes your URL for over 150 high-risk paths across all ten categories above — environment files, version control, database dumps, log files, source maps, admin paths, and more. It's the fastest way to cover the full list without manually curling each path individually.

Two moments to run it:

1. Before DNS cutover — paste your staging URL (e.g., https://staging.client-project.com). Fix any 200-response findings before proceeding to launch.
2. Within 24 hours of launch — run it again on the live domain to verify that production server configuration matches staging. Deploy processes sometimes differ between environments.

Scan my staging URL with ExposureCheck →

For secrets already checked into git history, also paste your source code into LeakCheck to find hardcoded API keys before they reach the server — ExposureCheck finds what's accessible at the URL level; LeakCheck finds what's embedded in the code itself.

Pre-launch workflow

1. Run ExposureCheck on the staging URL. Paste the staging URL and review all findings. Any 200 response on a sensitive path is a launch blocker — fix it before proceeding.
2. Manually curl the five highest-risk paths. /.env, /.git/config, /wp-config.php.bak (if WordPress), /credentials.json, and /backup.sql. Verify each returns 404, not 200 or 403.
3. Check directory listing on upload and media directories. curl https://staging.yoursite.com/uploads/ — look for Index of / in the response. If present, disable with Options -Indexes (Apache) or autoindex off (nginx).
4. Verify build output. Confirm source maps match your policy, .env files are absent from dist/, and no private key files were bundled with the deploy.
5. Switch DNS and re-scan within 24 hours. Run ExposureCheck on the live domain to confirm the production server config matches staging. Production environments sometimes have different web server configurations.
6. Check HTTP security headers. Exposed files and weak security headers are often found together. After confirming no exposures, run HardenCheck on the live URL to verify Content-Security-Policy, HSTS, and X-Frame-Options are correctly set.

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

Pre-launch file exposure is one dimension of a secure launch. These free tools cover the others: