Guide · External surface
What your website exposes without meaning to
A public website must reveal information to work. The job is to distinguish what is necessary, what merely helps diagnosis and what actually opens access or discloses data.
Short answer
What information can a website expose publicly?
Its DNS, TLS certificate, HTTP responses, headers, HTML, scripts, stylesheets, public paths and indexed documents are observable without an account. They can reveal providers, technologies, entry points and sometimes versions.
A technical fingerprint is not automatically a vulnerability. Prioritize secrets, personal data, backups, sensitive interfaces and genuinely vulnerable versions that are accessible. Work on a site you control and document the evidence before repairing it.
What the site has to show in order to work
The browser receives an IP address, certificate, headers and files. Client-side code is, by definition, delivered to the visitor. Names of external services often appear in requests for fonts, analytics, payments, video or forms.
This visibility is normal. It becomes a problem when unnecessary information assists an attack, a private file is served or a sensitive interface is exposed without suitable protection.
Worth remembering
Reducing exposure does not mean hiding every technology. It means publishing only what visitors and site operation actually need.
A server name is a clue, not a verdict
A header, path, cookie or file structure can suggest a server, CMS or framework. OWASP describes this reconnaissance as inventory work: it helps form hypotheses and choose the next checks.
Hiding a version banner removes an easy clue but does not fix a vulnerable version. Conversely, recognizing WordPress does not prove that a particular plugin is installed or exploitable.
Technical detail
Treat information disclosure separately from the weakness it might help someone target. The first may deserve cleanup; the second requires its own evidence.
What search engines and archives have already seen
Search engines can reveal subdomains, office documents, old paths, staging environments or error messages. A file removed today may remain known through a cache, archive or external link.
robots.txt tells cooperative crawlers what they should not crawl; it does not protect a secret. Naming a sensitive path there can make it easier to guess. Private data belongs outside the public root and behind real access control.
Map the entry points
Look at
- Authentication sign-in, account recovery, customer areas and administration.
- User input forms, search, uploads, comments and URL parameters.
- Machine interfaces APIs, webhooks, feeds, XML-RPC or integration endpoints.
- Subdomains staging, an old site, portals, mail and internal tools made public.
- Third parties widgets and scripts that receive data or act using your domain.
A visible route is not necessarily vulnerable. The inventory lets you check that every entry is intentional, maintained and protected for what it can do.
Exposures that call for direct action
A downloadable backup, configuration file, key, log containing personal data, source map exposing internal code or publicly listed directory is concrete evidence. Remove access, assess what was exposed and rotate affected secrets.
Error pages deserve review too. They should help the visitor without displaying a stack trace, local path, query or database detail.
Careful
If a secret was served publicly, deleting it is not enough. Treat it as disclosed, revoke or rotate it, then review available logs.
Provide a reporting path with security.txt
RFC 9116 defines a security.txt file at /.well-known/security.txt. It can state a contact, expiry date, policy and other information useful to someone who discovers a problem.
The file does not protect anything by itself. It reduces reporting friction and avoids sending sensitive details at random. The contact has to be monitored and the file renewed before it expires.
Verify without turning a clue into a flaw
-
Observe
HTTP response, DNS, certificate, HTML, assets and paths the site publishes.
-
Attribute
connect each item to an owner and a real need.
-
Confirm
reproduce the access and separate public information from data that should have stayed private.
-
Prioritize
by access gained, data, ease and potential for abuse.
-
Repair and retest
remove, protect, update or reduce the information, then confirm the result.
Worth remembering
A useful finding says what is accessible, how we know and what it enables. It avoids guessing about a compromise.
Common questions
Is exposing the server version a vulnerability?
It is information disclosure and a reconnaissance clue. It matters more when that version is actually vulnerable. Hiding the clue never replaces updating the software.
Can robots.txt protect a private folder?
No. It is guidance for cooperative crawlers, not access control. Remove private content from the public root or protect it with authentication.
Can I run these checks on any website?
Stay with information publicly served and obtain explicit authorization before active, automated or potentially disruptive testing. On your own site, still define scope and rollback.
Want to know your real public surface?
An external audit can separate harmless clues, exposed files and entry points that need remediation.
Request an audit Start with self-checks