What Can an Attacker See on Your Website Right Now?

TL;DR: Far more than most teams expect: DNS records, TLS configuration, HTTP headers, technology stack and versions, exposed services, email authentication, and every third-party tracker are all visible from outside without a single credential. Attackers map this surface before trying anything else. Running the same reconnaissance against your own site first is the fastest way to find the doors you did not know were open.

Every serious attack begins the same way: quietly, from the outside, with reconnaissance. Before anyone sends a malicious payload, they map what your website exposes to the public internet, and none of it requires breaking into anything. It all sits in public records, protocol handshakes, and the responses your own servers send to anyone who asks.

This post walks through that external view layer by layer: what is visible, how attackers read it, and why the gap between the inside picture and the outside one is where incidents begin.

Why does the attacker's view matter?

Defenders see their systems from the inside out: repositories, dashboards, diagrams, tickets. Attackers see them from the outside in: whatever actually answers on the wire. Those two pictures rarely match. No diagram shows the staging subdomain that never got decommissioned, the debug endpoint a framework enabled by default, or the TLS configuration nobody has touched since launch.

Reconnaissance is also cheap and quiet. Passive techniques such as DNS lookups, certificate transparency logs, and WHOIS queries never touch your servers at all, and light active probing blends into normal traffic. By the time an attacker sends a first real exploit attempt, they usually know your hosting provider, web framework, mail setup, and a shortlist of software versions worth attacking.

What does your DNS already give away?

DNS is the public map of your infrastructure, and anyone can read it:

• A and AAAA records show where traffic actually lands, revealing hosting providers and the IP space around you.
• NS records identify your DNS provider, itself a target for hijacking and account takeover.
• MX records reveal your mail infrastructure.
• TXT records carry your SPF policy plus verification strings from every SaaS product you have connected, quietly documenting your vendor stack.
• CNAME records map subdomains to third-party services; one pointing at a deprovisioned service is the classic setup for subdomain takeover.
• A missing CAA record means any certificate authority in the world may issue certificates for your domain.

Reverse DNS on your IPs often names your hosting platform outright, and WHOIS reveals your registrar, expiration date, and DNSSEC status. A domain close to expiry, or without transfer locks, is an open invitation.

What does your TLS configuration say about you?

Anyone can complete a TLS handshake with your server and inventory exactly what it accepts: which protocol versions (SSL 3.0, TLS 1.0, and TLS 1.1 are formally deprecated by RFC 8996), which cipher suites, and which certificate it presents. Legacy protocols and broken ciphers enable downgrade and interception attacks; an expired, self-signed, or mismatched certificate breaks trust outright; a missing Strict-Transport-Security header leaves room for SSL stripping. TLS posture is also a proxy signal: a server still offering deprecated protocols suggests patching is not a priority elsewhere either.

What do your HTTP responses and tech stack reveal?

Every response your site sends is a fingerprinting opportunity. Server banners and headers like X-Powered-By name software directly. Beyond that, script paths, cookie names, HTML patterns, error pages, and even the hash of your favicon combine into a high-confidence identification of your CMS, framework, web server, and CDN, often down to the version. Internet-wide search engines even index favicon hashes, linking related deployments together.

Missing security headers are equally visible. Whether you send Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy is public record on every response, and each absence maps to a concrete client-side attack class.

Then there are the well-known paths attackers routinely probe: /.env, /.git/config, /server-status, /phpinfo.php, debug and profiler endpoints, API health and OpenAPI routes. Any of these answering successfully is an information-disclosure finding, and sometimes a full credential leak.

How does a version number become an exploit?

Once a product and version are identified, they can be expressed as a standard CPE identifier and matched against public vulnerability databases such as NVD. Each match arrives with context: CVSS for severity, EPSS for the probability of exploitation in the wild in the near term, and a flag when the CVE appears in CISA's Known Exploited Vulnerabilities catalog of confirmed real-world exploitation.

Attackers automate exactly this pipeline: fingerprint the version, look up the CVEs, sort by exploitability, and check whether a web application firewall is in the way. WAF presence, and even the vendor, is fingerprintable from outside, and published bypasses are vendor-specific. An exposed service running a KEV-listed CVE with no WAF in front is about as inviting as a surface gets.

Can attackers tell whether your email can be spoofed?

Yes, in seconds, because email authentication lives in public DNS. SPF declares who may send mail as your domain, DKIM publishes signing keys, and DMARC tells receivers what to do when those checks fail. A DMARC policy of p=none, or no DMARC record at all, means mail claiming to come from your domain faces little resistance, which is exactly what phishing crews check before impersonating a brand to its own customers and staff. Even STARTTLS support on your mail server is observable with a single SMTP handshake.

What do your trackers and third-party scripts expose?

Every visitor's browser receives the full list of analytics tags, ad pixels, session-recording tools, and fingerprinting scripts your pages load; that list is not private. It matters twice over. First, privacy: regulators, researchers, and users can see which third parties receive data and whether anything fires before consent. Second, supply chain: every external script is code you execute but do not control, and scripts without Subresource Integrity hashes can be silently replaced if the third party or its CDN is compromised.

The external surface at a glance

How do you see what they see?

Run the same reconnaissance against yourself. An unauthenticated external scan uses no credentials and no agents, only what the public internet can observe: a faithful reproduction of an attacker's opening move.

This is exactly the view OnScanner was built around. It fingerprints DNS, TLS, and WAF posture, identifies your technology stack, matches versions against CVE data with EPSS and CISA KEV context, checks SPF, DKIM, and DMARC, and analyzes trackers across 40+ categories, live on every scan and never from a cache. The full detection approach is documented in our methodology, and the feature overview lists each engine.

Two closing notes. First, only scan domains you own or are explicitly authorized to test; active scanning without permission is off-limits legally and ethically. Second, the external view is a starting point: the structured process for scanning, triage, and remediation comes next, and we cover it in How to Scan a Website for Vulnerabilities.

Frequently asked questions

Can attackers really see all of this without logging in?

Yes. Everything described here comes from public DNS queries, WHOIS records, TLS handshakes, and ordinary HTTP requests that any browser could make. No authentication, exploitation, or malware is involved, which is why this stage of an attack generates almost no defensive signal. The only reliable countermeasure is knowing your own external surface at least as well as an attacker can learn it.

How often does the external view of a website change?

Continuously. Every deployment can change headers and fingerprints, certificates renew or lapse, DNS records move during migrations, marketing teams add new tags, and fresh CVEs are published against software you have not touched. A snapshot from last quarter describes a website that no longer exists. Scheduled, live rescanning matters more than any single assessment.

Does an unauthenticated scan cover the whole attack surface?

No. It covers exactly what an anonymous outsider can reach, which is the right starting point but excludes everything behind a login: user dashboards, account settings, and authenticated APIs. Testing that deeper surface requires an authenticated scan using dedicated test credentials. We compare the two vantage points in Authenticated vs Unauthenticated Scanning.