Tool 06 — Web Security

Directory Exposure Checker

Check 120 sensitive paths: configs, backups, APIs, admin panels, and more. Authorized testing only — only use on systems you own.

Directory Exposure Checker

Check 120 sensitive paths: configs, backups, APIs, admin panels and more.

Only use on sites you own or have permission to test.

What is directory exposure?

Directory exposure (also called directory listing or path traversal risk) refers to web server paths that are publicly accessible but should not be — configuration files, backup archives, development artifacts, admin panels, and version control metadata. These exposures are extremely common and can lead to complete server compromise even without exploiting any code vulnerability.

A study by Rapid7 found exposed /.git/ directories on thousands of production servers, many containing database credentials, API keys, and internal architecture details. These exposures are entirely preventable with correct server configuration.

The most dangerous exposed paths

/.git/config

Exposes repository structure, remote URLs, sometimes credentials embedded in remote URLs

/.env

Exposes environment variables — database passwords, API keys, secret keys

/backup.zip, /backup.sql

Full database dumps or site archives — complete application takeover

/wp-config.php.bak

WordPress config backup — database credentials, secret keys

/phpinfo.php

PHP configuration dump — server paths, loaded modules, environment variables

/admin, /administrator

Admin panels — if exposed, susceptible to brute force and credential stuffing

/server-status, /server-info

Apache status pages — active connections, request details, server version

/.DS_Store

macOS metadata file — reveals directory structure of the server's file system

How do these exposures happen?

Exposed sensitive paths are almost always the result of one of three mistakes:

Deployment accidents — developers deploy the entire project directory to the web root, including .git/, .env, and other files that should never be public. This is especially common with shared hosting and FTP deployments.
Missing deny rules — the web server doesn't have rules blocking access to sensitive paths. A single Deny from all in .htaccess or a location block in Nginx would prevent most of these.
Backup files left in place — developers create backup copies (config.php.bak, database.sql.old) in the web root during maintenance and forget to remove them.

How to fix exposed paths

In Nginx: use location ~* \.(git|env|sql|bak)$ { deny all; }
In Apache: add RedirectMatch 404 /\.git or use FilesMatch directives in .htaccess
Never store .env files in the web root — they belong above it or in environment variable systems
Use a .gitignore that excludes sensitive files, and audit what gets deployed
Configure your deploy pipeline to explicitly exclude .git/, node_modules/, and backup files from what gets pushed to the server
Disable directory listing in your web server config (Options -Indexes in Apache, autoindex off in Nginx)

Responsible use

This tool makes HTTP requests to the paths listed. Only use it on domains you own or have explicit written authorization to test. Scanning third-party websites without permission violates their terms of service and may violate computer crime laws in your jurisdiction. See Terms of Use.

← Back to all tools