Sensitive File Detection

FortWatch probes 117+ sensitive paths across four categories: configuration files (.env, wp-config.php, application.yml, config.php, appsettings.json), version control artifacts (.git/config, .git/HEAD, .svn/, .hg/), backup archives (.sql, .zip, .tar.gz, .bak, .old, database dumps), and admin or debug endpoints (phpMyAdmin, WordPress admin, phpinfo(), server-status, stack traces). The list is curated from real breach post-mortems and updated as new path patterns emerge in the wild.

FortWatch sends targeted HTTP HEAD and small GET requests to each known path and inspects the response metadata — status code, content-type, content-length, and a short body preview. That's enough to distinguish a real exposed .env from a custom 404 page or a WAF block, without pulling down secrets or large archives. No credentials, payloads, or file contents are stored — only the fact that the path is accessible and what kind of file it appears to be.

A .env file typically holds database credentials, third-party API keys, encryption keys, mail server passwords, and OAuth secrets for an entire application. One accidentally committed or deployed .env has been the initial access vector in dozens of public breaches. Attackers run automated scanners against the whole internet looking specifically for this file — if it's reachable at yoursite.com/.env, assume it was found within hours of being exposed.

An exposed .git directory lets an attacker reconstruct your entire source code history, including deleted commits that still contain credentials, internal hostnames, and business logic. Tools like git-dumper automate the extraction in minutes. FortWatch checks for .git/config, .git/HEAD, and .git/index specifically because those are the files that confirm a full repository is accessible, rather than just a stray file.

Yes. Backup files are one of the highest-value targets for attackers because they often contain a full snapshot of the application and database. FortWatch checks for common backup patterns (database.sql, backup.zip, site.tar.gz, wp-content backups, and filename.ext.bak variants), as well as exposed cloud storage index pages. A single exposed SQL dump can leak every user record in your system.

The scanner's first job is confirming the config file is publicly reachable — that's already a critical finding on its own. FortWatch's response-body inspection also flags file types known to contain secrets (JSON configs, YAML, .env formats) so you can prioritize them over static asset exposure. Credential rotation is part of the remediation guidance attached to every finding.

Treat it as a live incident. Block access at the web server or CDN (nginx location rule, Apache .htaccess, or Cloudflare WAF rule), then rotate every secret the file could have contained — database passwords, API keys, OAuth tokens, encryption keys. Assume the file has already been indexed by attacker scanners. FortWatch attaches a severity-specific remediation playbook with nginx and Apache examples to every finding so you can move in minutes, not hours.

Very low. FortWatch's response analysis looks beyond the HTTP status code — it inspects content-type, body length, and body fingerprints to distinguish a real exposed file from a soft-404 page, a WAF challenge, or a generic catch-all route. Custom 404 pages that return HTTP 200 are the most common source of noise in naive scanners, and FortWatch's content inspection is built specifically to filter them out.