What Your Website Reveals to Attackers: Information Leakage and How to Fix It
Before attacking a website, an attacker does homework — and most websites help them. Version numbers in headers, error pages that print file paths, forgotten backup files, staging sites, public code repositories and old subdomains all quietly tell outsiders what you run and where it is weak. Security professionals call this information leakage, and it is one of the most common findings on small business websites.
This guide shows what your website may be revealing without you knowing, how attackers use it, and how to find and fix the leaks.
Why small leaks matter
Information leakage is rarely the attack itself. It is reconnaissance that makes the attack cheap. If your server announces that it runs a specific outdated version of PHP or a plugin with a known flaw, an attacker — usually an automated bot — does not need to guess. They go straight for the exploit that matches. Remove the clues and you drop out of the easy-target list.
What your website may be exposing
1. Software versions in headers and page source
Response headers like Server: Apache/2.4.41 (Ubuntu) or X-Powered-By: PHP/7.4.3, CMS generator meta tags, and version numbers on script and style file names tell attackers exactly what to look up. Fix: ask your host to hide server and PHP versions, remove generator tags, and keep the software updated anyway.
2. Detailed error messages
When something breaks, debug-mode error pages can show file paths, database names, framework details or even fragments of source code. Fix: disable debug mode in production and show a generic error page; log the details privately instead.
3. Backup, configuration and log files
Files such as backup.zip, site-old.tar.gz, database.sql, .env, config.php.bak or error_log left in the public web folder can hand over database passwords, API keys or a complete copy of your data. Bots scan for these names constantly. Fix: store backups outside the web root and block access to sensitive file types at server level.
4. Exposed version-control folders
If a site was deployed by copying a project folder, a hidden .git directory may be publicly reachable, allowing an attacker to download the entire source code and its history — often including old passwords. Fix: block access to .git and similar folders, and deploy without them.
5. Directory listings
When a folder has no index page and listing is enabled, the server shows every file inside — uploads, documents, sometimes invoices or CVs submitted through forms. Fix: disable directory listing; on Apache this is the single line Options -Indexes.
6. Forgotten subdomains and staging sites
Test sites such as dev., staging. or old.yourdomain.com often run outdated copies with weaker passwords and real data. Certificate transparency logs make subdomains easy to discover for anyone. Fix: keep an inventory, password-protect or remove staging environments, and delete DNS records for retired services.
7. Admin panels and tools left open
Login pages for the CMS, hosting control panel, database tools or monitoring dashboards that anyone can reach invite password guessing. Fix: restrict them by IP or VPN where possible, and always require strong passwords plus two-factor authentication.
8. Documents and metadata
PDFs and office documents on your site may contain author names, usernames, internal file paths or software versions in their metadata, and sometimes internal documents get indexed by search engines by mistake. Fix: strip metadata before publishing and review what search engines show for site:yourdomain.com.
9. Robots.txt and sitemap hints
Listing /admin-backup/ or /internal/ in robots.txt to hide it from search engines actually advertises it to attackers. Fix: protect sensitive paths with authentication instead of relying on robots.txt.
10. Leaked credentials and code elsewhere
API keys and passwords sometimes end up in public code repositories, paste sites or in JavaScript files delivered to every visitor. Fix: never put secrets in front-end code, rotate any key that has been exposed, and search public repositories for your domain name.
“Attackers rarely need to break in. They read what you have already published — then pick the door you forgot to lock.”
NyorsoftExternal Security Review
How to check your own exposure
- Inspect your response headers with
curl -I https://yourdomain.comor your browser’s developer tools and look for version numbers. - Search Google for
site:yourdomain.comand review anything that looks internal. - Try common file names such as
/backup.zip,/.envand/.git/on your own site; you should get a 403 or 404. - Look up your domain in a certificate transparency search to see every subdomain that has had a certificate.
- Visit a few folders such as
/uploads/or/images/to check that directory listing is off.
Only test sites you own or are authorised to test.
Reduce your exposure
Most of these fixes are configuration changes that take minutes once you know where to look. Finding them is the hard part, which is why exposure mapping is at the heart of our Website & Data Exposure Assessment, including subdomain discovery and data-leakage indicators. For a single site, the Public Website Security Check covers the essentials. Also see our website security checklist and security headers guide.
Frequently asked questions
What is information leakage on a website?
It is any unintended disclosure of details that help an attacker: software versions, error messages, file paths, backup files, source code, subdomains or credentials. It is usually used for reconnaissance before an attack.
Is showing my server version really a risk?
On its own it is low risk, but it lets automated tools match your site to known vulnerabilities instantly. Hiding versions and keeping software updated removes that shortcut.
How do attackers find my subdomains?
Through public certificate transparency logs, DNS records, search engines and brute-force guessing of common names like dev, staging or test. Assume every subdomain is discoverable.
How can I find exposed files on my website?
Check for common backup and configuration file names, make sure directory listing is disabled, review search engine results for your domain, or have an external security review performed.
Does robots.txt hide pages from attackers?
No. Robots.txt is a public file that only asks search engines not to crawl certain paths. Listing sensitive paths there can actually draw attention to them.
Sources and further reading
- OWASP Top 10:2025 – A02 Security Misconfiguration – exposed files, default settings and verbose errors as a top web risk.
- OWASP Web Security Testing Guide – includes the information-gathering steps attackers and testers use.
- OWASP HTTP Headers Cheat Sheet – which headers reveal server details and how to remove them.
Not sure what your website exposes?
Our Public Website Security Check looks at your site the way an attacker does — TLS, security headers, email authentication and exposed services — and gives you a short, ranked list of what to fix.
Pavol brings IT analysis experience from banking and financial-sector projects to Nyorsoft’s external security reviews for small businesses. About our team