Prevention guide

How to prevent exposed files on your website

Sensitive file exposures aren't random — they follow predictable root causes that you can eliminate before deployment. This guide covers the structural changes, server rules, and pipeline hygiene that stop .env files, .git directories, source maps, and database backups from ever reaching a publicly accessible path.

• Root causes
• Webroot separation
• Secrets management
• Server deny rules
• Disable source maps
• Backup hygiene
• Pre-deploy checklist
• FAQ

Why files get exposed: four root causes

Understanding the failure mode is the fastest path to a structural fix. The vast majority of file exposures come from one of four places:

1. Webroot equals project root. The web server serves the entire project directory, including .env, .git/, node_modules/, and config files that should never be public. This is the most common cause on VPS deployments where the developer ran git clone directly into /var/www/.
2. Secrets committed to version control. A .env file checked into git — even once, even briefly — lives in the commit history. If the repo is later cloned to a publicly served path, or if /.git/ becomes accessible, those secrets are recoverable.
3. No server-side path blocking. The server has no deny rules for sensitive paths. If a file does end up in the webroot by accident, there is nothing to catch it.
4. Source maps left enabled in production. The build tool default includes source maps. No one turned them off before the first production deploy.

Each section below addresses one of these causes directly.

Separate your project root from your webroot

The most structurally sound prevention is also the simplest: deploy only your build output, not your entire project.

A typical Node/JS project structure:

myproject/           ← project root (never serve this)
  .env               ← secrets
  .git/              ← git history
  node_modules/      ← dependencies
  src/               ← source code
  dist/              ← build output (serve only this)

On managed platforms like Netlify and Vercel, this separation is enforced by default — you specify a publish directory (dist/, out/, public/) and only that directory is served. Files outside it are never accessible regardless of what they contain.

On a VPS or self-managed server, you must create this separation deliberately:

# Wrong: serving the project root
/var/www/mysite/       ← git clone lands here; webroot is /var/www/mysite/

# Right: serving only the build output
/home/deploy/mysite/   ← git clone and build happens here
/var/www/mysite/       ← Nginx webroot; only dist/ contents are copied here

Your deploy script should copy (or rsync) only the build output to the webroot, not the project root:

npm run build
rsync -av --delete dist/ /var/www/mysite/

Keep secrets out of files and out of git

A .env file should exist only in two places: your local development machine (gitignored), and your hosting platform's native secret store. It should never enter version control.

Local development

Your .gitignore should include these entries from the first commit:

.env
.env.local
.env.*.local
.env.production
.env.backup
.env.old

Use git status --short before every commit to confirm no .env variants are staged. Even better, run LeakCheck on any changed file before committing — it catches secrets that slip past filename checks (hardcoded values, not just standalone .env files).

Platform secret stores (inject at build/runtime, not in files)

Block sensitive paths at the server level

Even with good webroot separation, a misconfiguration or accidental file copy can slip through. Server-level deny rules are your safety net — they block any request to a sensitive path regardless of how the file got there.

The paths worth blocking explicitly

A single rule covering all dot-prefixed paths handles most of them:

# In your server {} block:
location ~ /\. {
  deny all;
  return 404;
}

<FilesMatch "^\.">
  Require all denied
</FilesMatch>

# Also block common backup extensions
<FilesMatch "\.(sql|bak|old|backup)$">
  Require all denied
</FilesMatch>

/.env 404
/.env.* 404
/.git/* 404
/*.sql 404
/*.sql.gz 404

{
  "headers": [],
  "rewrites": [],
  "redirects": [
    {
      "source": "/.env",
      "destination": "/404",
      "statusCode": 404
    },
    {
      "source": "/.git/:path*",
      "destination": "/404",
      "statusCode": 404
    }
  ]
}

# No native redirect rules in _headers;
# use a _redirects file (same syntax as Netlify):
/.env 404
/.git/* 404
/*.sql 404

Disable source maps in production builds

Source maps are generated by default in most build tools to help with debugging. In production, they expose your original source code — including file paths, TypeScript types, comments, and any hardcoded values present during development — to anyone who opens DevTools.

// vite.config.js
export default {
  build: {
    sourcemap: false  // default is false
                      // check you haven't overridden it
  }
}

// webpack.config.js (production)
module.exports = {
  devtool: false,
  // or 'hidden-source-map' to generate
  // maps without referencing them in bundles
}

# .env.production or build command:
GENERATE_SOURCEMAP=false npm run build

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
  // default is false; verify it hasn't been enabled
}

After rebuilding, verify the change: open the site in DevTools → Sources/Debugger. If you see webpack:// or vite:// tree entries with your original filenames, source maps are still active. Also check the Network tab for any *.js.map requests with 200 responses.

Database backup hygiene

A database dump placed in the webroot during maintenance — and never removed — is a complete data breach waiting to be discovered. The fix is a location discipline that is easy to enforce once and never think about again:

• Never write backups to the webroot or any subdirectory of it. On a VPS with a webroot at /var/www/mysite/public/, write backups to /var/backups/mysite/ or an S3/GCS bucket.
• Use your managed database's built-in backup feature. RDS automated backups, Supabase Point-in-Time Recovery, PlanetScale branching — these never touch your server's filesystem.
• If you must take a manual dump, stream it directly to object storage rather than writing to disk first: pg_dump mydb | gzip | aws s3 cp - s3://my-backup-bucket/mydb-$(date +%Y%m%d).sql.gz
• Add backup patterns to your .gitignore as a secondary safety measure: *.sql, *.sql.gz, *.bak, dump.sql.

Pre-deploy verification checklist

Run this before every launch and after every significant infrastructure change:

• Webroot contains only build output. Confirm your CI/CD or deploy script copies only dist/ (or equivalent), not the project root.
• No .env variants are staged or tracked. Run git ls-files | grep '\.env' — the output should be empty.
• Source maps are disabled. Check your build config. Verify after building by inspecting the Network tab for *.js.map requests.
• Server deny rules are in place. Confirm your Nginx/Apache config or platform _redirects / vercel.json blocks hidden paths and SQL files.
• No backup files in the webroot. Confirm your backup destination is outside the served directory tree.
• Run ExposureCheck on the live URL. Automated path probing and bundle scanning after every deploy catches anything the above steps missed.

Run ExposureCheck on your live site →

Frequently asked questions

location ~ /\. {
  deny all;
  return 404;
}

Need to audit a live site for existing exposures? Use the audit guide →

Found something already exposed? Follow the step-by-step remediation guide →

Also in the Copper Bay Labs ship-safety suite

Exposed files are one part of a broader pre-launch security and compliance picture: