At a glance
- The question
- What can somebody learn about our systems without touching them
- Where it comes from
- Certificate logs, DNS, response headers, published files and the scripts you embed
- Why it matters
- It is the list an attacker builds first, and it is usually longer than the one you have
- What to fix
- The hosts you forgot, the versions you announce and the files nobody meant to publish
- What not to bother with
- Hiding things that are public by design. Spend the effort on the ones that are not
Looking from the outside
Every assessment starts the same way, and so does every attack: with what can be learned before anything is touched. Public logs, DNS, one page load. No scanning, nothing that would appear in an alert, nothing that needs permission.
The reason to do this yourself is that the list an attacker builds is usually longer than the list you have. Not because your inventory is bad, but because the outside view includes everything that ever had a certificate, everything a DNS record points at, and everything a developer published without telling anyone.
This is not scanning. Everything in this guide is either published deliberately, published as a side effect of how the web works, or served to anyone who asks for the front page. Our domain checker does exactly this much and no more: one page load and public records.
Certificate logs: your internal names are public
Since browsers began requiring it, every certificate issued by a public authority is published to append-only logs. The logs are searchable by anyone, and they carry every name on every certificate.
That means the following are public, permanently, from the moment the certificate was issued:
vpn.yourcompany.com,jenkins.yourcompany.com,backup-admin.yourcompany.com.- The staging environment somebody gave a certificate to for convenience.
- The name of a product you have not announced, if someone issued a certificate for it early.
You cannot unpublish them. What you can do is know what is there, decide which of those hosts should be reachable from the internet at all, and stop treating a name as a secret. A wildcard certificate publishes less detail, and in exchange one key covers everything under it, which is its own trade.
DNS: the shape of the estate
DNS is a public database about your organisation, and it is chattier than most people expect.
| Record | What it tells a stranger |
|---|---|
| MX | Who handles your mail, and therefore which phishing lures look plausible |
| TXT | Which services you use: the verification strings for a dozen platforms sit here for years after the trial ended |
| SPF | A list of every service allowed to send as you, which is a map of your suppliers |
| CNAME | Where a host actually lives, including the cloud provider and sometimes the tenant name |
| NS and SOA | Who runs your DNS, and whether a subdomain was delegated to someone else and never taken back |
The one that matters most is a CNAME pointing at a service that no longer exists. If the target can be claimed by anyone, the subdomain belongs to whoever claims it, along with the trust of your brand and, depending on how your cookies are scoped, rather more than that.
What a single response says
One page load tells a stranger which software you run, often to the patch version, and which protections you have not turned on.
- Server and X-Powered-By. An exact version is a shortlist of published vulnerabilities to try, handed over for free. Removing it is configuration, not work.
- Framework fingerprints. Cookie names, asset paths and error pages identify a stack even when the banner is gone. This is not worth chasing; the banner is.
- Missing headers. No policy, no HSTS, cookies without flags. Each one says something about how much attention this application gets, which is itself a signal to somebody deciding where to spend their time.
Our header checker grades a pasted response and writes out the lines you are missing, and the certificate reader will tell you what else is on the certificate you are serving.
The files nobody meant to publish
A handful of paths are worth knowing about because they are published by accident often enough that checking them is the first thing anyone does.
- A
.gitdirectory. Deploying by pulling a repository, without excluding the metadata, publishes the entire history including the credentials somebody committed once and removed in the next commit. - Environment and backup files.
.env,config.php.bak,database.sql, an editor's swap file. These are static files, so no application logic protects them. - Source maps. Useful in development, and they publish your original source to anyone who opens the developer tools.
- Directory listings. An index of a directory nobody meant to be browsable, usually holding exactly the file you would not choose to share.
One file worth publishing. /.well-known/security.txt tells someone who finds a problem how to tell you, which is the difference between a report and a disclosure you read about later. It is a short text file with a contact address and an expiry date.
Everything you embed becomes yours
A third-party script does not run in a box. It runs as your page, with your cookies, in front of your users, and it can be changed by whoever controls that host without telling you.
So the outside view includes every script tag you serve, and three questions about each:
- Does that domain still belong to the vendor you chose, or did it lapse? An unregistered script host is a takeover waiting for someone who checks.
- Is the script pinned, either by version or by subresource integrity, or does the page take whatever is served today?
- Does it need to be on the page that takes payments, or was it added for an experiment in 2023?
The same question applies to the libraries you bundle. A version that shipped three years ago with a known problem is visible from the outside as soon as the file is fetched.
What to actually do
Most of what the outside view finds is not a vulnerability, and treating it all as one is how the exercise loses its audience. In order of what is worth the time:
- Hosts you did not know were reachable. Decide whether each one should be, and turn off the ones that should not.
- A DNS record pointing at something that no longer exists. Remove it before somebody claims the other end.
- Files that should not be published. Stop serving them, then work out whether anything in them needs rotating, because you do not know who read them first.
- Mail records that let anyone send as you. Covered in the DMARC guide; this is the highest value item on most domains.
- Version banners and missing headers. A morning of configuration, and they stay fixed.
- Names in certificate logs. Not a fix, an inventory. Read it once a quarter and see what appeared.
The short version. Everything on a certificate is public forever, DNS describes your suppliers and your estate, one response announces your software version, a few paths are published by accident often enough to be worth checking, and every embedded script runs as you. None of it requires touching a system to find, which is exactly why it is where an attacker starts and where your own review should too.
References & further reading
- B. Laurie, A. Langley, E. Kasper, RFC 6962: Certificate Transparency. The append-only logs that make every publicly issued certificate, and every name on it, a matter of public record.
- Certificate Transparency project, certificate.transparency.dev. How the logs work and how to search them.
- E. Foudil, Y. Shafranovich, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. The security.txt file, including the expiry field people forget.
- M. Nottingham, RFC 8615: Well-Known Uniform Resource Identifiers. Why anything under /.well-known/ is a published interface rather than a hidden path.
- W3C, Subresource Integrity. Pinning a third-party file to its exact contents, so a changed script fails to load rather than running as you.