Beyond Security Headers: Mapping Your Attack Surface (Open Ports, CVEs, DNS)

You fixed your Content Security Policy, added HSTS, locked down framing, and HeaderTest now shows an A+. That's a real win: it closes off whole classes of browser-side attacks like XSS, clickjacking and protocol downgrades.

But security headers only govern what the browser is allowed to do. An attacker doesn't start with your response headers. They start by asking a simpler question: what is reachable on the internet, and what is it running?

The layers your header grade doesn't cover

A domain is more than the HTML it serves. Behind example.com there are:

• IP addresses and hosting networks: the servers your DNS points at, and which provider (ASN) they live in.
• Open ports: SSH on 22, a database on 5432 or 3306, an admin panel on 8080, a forgotten Redis on 6379.
• Software versions with known CVEs: the web server, SSH daemon or appliance firmware advertised in service banners.
• DNS records: MX, SPF and TXT records, which decide whether someone can send convincing phishing mail as you.
• Registration data: who your registrar is and when the domain expires. An expired domain is one of the cheapest takeovers there is.

None of these show up in an HTTP response header, and a perfect CSP does nothing about any of them.

Why this matters even with perfect headers

Some patterns we see over and over:

• The staging box. The production site has a strict CSP. The staging server on another IP runs an old Apache build with a public CVE and no headers at all.
• The database that "was only open for a minute". A port opened for debugging and never closed. Internet-wide scanners find it within hours.
• Email spoofing. The domain has MX records but no SPF, so anyone can send mail that appears to come from it.
• Expiry. A renewal fails, the domain lapses, and someone else registers it, along with every password-reset email still pointed at it.

How to check your domain's exposure

You could run your own port scans and CVE lookups, but you only see what's reachable from where you scan, at that moment. A better start is to look at what internet-wide measurement has already observed about you.

OSN (Open Source Networks) is our sister project. It continuously maps the public IPv4 and IPv6 space using only publicly available data, and it's free to search with no signup:

1. Open beta.osn.lt and enter your domain, an IP address, an ASN or a CVE ID.
2. On the domain report, check the addresses your domain resolves to, the network/ASN they belong to, and the open ports seen on each one.
3. Look at the CVE count per host. Anything above zero means a service banner matched a version with known vulnerabilities, so patch it or take it off the internet.
4. Review the DNS records (is there an SPF record if you have MX?) and the WHOIS expiry date.

For automation, the same data is available as JSON without an API key:

curl -s https://beta.osn.lt/api/v1/domain/example.com | jq '{hosts, whois}'

A practical checklist

• Headers: scan with HeaderTest and work through the per-header guides until you're at A or A+.
• Exposure: look up the domain on OSN. Every open port should be one you meant to expose.
• Vulnerabilities: any host with known CVEs needs a patch, a firewall rule, or decommissioning.
• Email: if you receive mail, publish SPF (and DKIM/DMARC).
• Domain hygiene: turn on auto-renew and registrar lock, and keep the expiry date well in the future.
• Repeat: both your headers and your exposure drift over time, so re-check after every infrastructure change.

Headers and exposure together

Whenever you scan a site on HeaderTest, the results page now includes a "Beyond headers" card. It shows the IPs, open ports, CVE count, hosting network, domain expiry and SPF status that OSN has observed for that domain, with a link to the full report. One scan shows you both the browser-side configuration and the infrastructure underneath it.