Security check
Check for exposed files and server misconfiguration
Files that should never be public, like a .git folder, an .env file with database passwords or a debug log, sometimes end up in the web root after a deployment. SecurityScan checks a fixed list of such paths and a few server settings that are easy to get wrong.
What the check looks at
Sensitive files
Paths such as .git/config, .env, .htaccess, web.config, composer.json, package.json, Dockerfile, docker-compose.yml, debug.log, error.log and .aws/credentials. Only paths that actually answer are reported.
Version-revealing headers
Server or X-Powered-By headers that include software versions.
Risky HTTP methods
Whether the server accepts methods such as PUT, DELETE or TRACE.
CORS and cookie flags
A permissive Access-Control-Allow-Origin, and cookies set without Secure, HttpOnly or SameSite.
Is the scan intrusive?
No attack payloads, no password guessing, no port scans. It sends ordinary requests for well-known paths and reads the answers. Only scan sites you are authorised to scan. The free scanner asks you to confirm that.
Fixing findings
Point the web server’s document root at the public folder only, block the reported paths in the server configuration, remove versions from server headers and disable HTTP methods the site doesn’t use. Then re-scan to confirm.
Questions
- Why is an exposed .env file so serious?
- It often contains database passwords and API keys. Anyone who finds it can use them, so rotate those secrets as well as blocking the file.
- Does the scan download my files?
- It checks whether each path answers and does not keep the file contents.
- Is this a penetration test?
- No. It is an external check for common exposures, a baseline you can monitor, not a replacement for a pentest.
Technical checks, not legal advice. SecurityScan does not replace a consultation with a lawyer.