Attack Surface: What's Exposed and Who Counts It

Beyond the homepage

When people think about website security, they picture their main homepage. But a typical small business runs far more internet-facing surface than a single site:

• The marketing site and the app are on different subdomains, sometimes different hosting providers.
• A staging environment sits on a subdomain that was "temporary" eighteen months ago.
• An API serves the mobile app, the web frontend, and two integrations that a former contractor built.
• An admin panel runs on a non-standard port with HTTP basic auth and no rate limiting.
• DNS records point to services you cancelled, creating subdomain takeover risk.
• Third-party scripts (analytics, chat widgets, A/B testing) execute in your visitors' browsers with full DOM access.

Each of these is attack surface. An attacker does not care which one is your "real" product - they probe all of them and enter through whichever is weakest.

The seven layers of attack surface

A useful mental model divides your external surface into layers. Each layer has different tools for mapping and different strategies for shrinking.

1. DNS

Your DNS zone is the public directory of everything you run. Every A, AAAA, CNAME, and MX record is visible to anyone who queries it. Subdomain enumeration tools use certificate transparency logs, brute-force common prefixes, and scrape search engines to build a list of everything you have ever pointed DNS at - including things you forgot.

The fix: export your zone file quarterly. Delete records that point to decommissioned services. A dangling CNAME to a cancelled Heroku or Azure app is a takeover waiting to happen.

2. Web applications

Every HTTP endpoint that responds to a request is surface. This includes your main site, staging, internal tools exposed to the internet, and API endpoints. Each one needs security headers, TLS configuration, and access controls appropriate to what it serves.

3. APIs

APIs are the fastest-growing attack surface for most businesses. Every endpoint that accepts input is a potential injection point. Every endpoint that returns data is a potential information leak. Document every API you expose, including the ones "only the mobile app uses" - those are reachable by anyone with a proxy.

4. Mail

Email authentication (SPF, DKIM, DMARC) is attack surface that most teams treat as someone else's problem. Without it, anyone can send email that appears to come from your domain. That is a phishing vector against your customers, not just a spam issue.

5. Cloud storage

S3 buckets, Azure blobs, GCS buckets, R2 buckets. If the ACL is misconfigured, the contents are public. This has been the root cause of major breaches for a decade, and it still happens because default permissions vary by provider and change over time.

6. Third-party code

Every <script> tag that loads from an external domain runs with the same privileges as your own code. Analytics, chat widgets, payment forms, A/B testing scripts - each one is a supply chain dependency. If the vendor is compromised, your visitors are compromised. Subresource Integrity and a tight Content-Security-Policy limit the blast radius.

7. People

Admin panels, CMS logins, CI/CD dashboards, monitoring tools. Every login page exposed to the internet is surface. Multi-factor authentication, IP allowlisting, and VPN access reduce this layer. The goal is zero internet-facing login pages for internal tools.

Free mapping in one hour

You do not need expensive tools to map your attack surface. One focused hour with free tools gives you a usable inventory:

1. Export your DNS zone from your registrar or DNS provider. List every record. Flag anything you do not immediately recognize.
2. Check certificate transparency logs at crt.sh for your domain. This shows every TLS certificate ever issued for any subdomain - including ones you may have forgotten. Search %.yourdomain.com to see the full list.
3. Run a passive security grade on your primary domains. This covers headers, TLS, DNS, and common exposures in a single check.
4. Search for exposed files - /.env, /.git/config, /wp-admin/, /server-status - on every hostname you found in steps one and two.
5. List your cloud storage buckets and check their public access settings. Every major provider has a CLI command for this.
6. Audit your third-party scripts - open your site in browser devtools, go to the Network tab, and list every external domain your page loads resources from. Each one is a dependency you trust with your visitors' data.

Write it all down. A spreadsheet with columns for hostname, purpose, owner, and last-verified date is enough. The act of listing forces you to confront what you actually expose.

Forgotten surface: where incidents start

The attack surface you know about is manageable. The attack surface you forgot about is where incidents start. Common forgotten assets:

• Staging environments with production database copies and no access controls.
• Legacy API versions still running behind a load balancer because nobody turned them off.
• Marketing microsites from campaigns that ended two years ago, still serving an outdated WordPress with unpatched plugins.
• Demo instances spun up for a sales call and never decommissioned.
• DNS records pointing to IP addresses you no longer control.
• Webhook endpoints that accept unauthenticated POST requests because "only Stripe calls them."

Each of these is real. Each has caused real incidents at real companies. The common thread is not technical sophistication - it is forgetting.

The shrink loop

Attack surface management is not a one-time audit. It is a recurring loop:

1. Map - discover everything that is exposed (the one-hour exercise above).
2. Assess - for each asset, ask: does this need to be public? If not, restrict or remove it.
3. Shrink - delete DNS records for decommissioned services. Put internal tools behind a VPN. Remove unused API endpoints. Drop third-party scripts you no longer use.
4. Monitor - set up alerts for new subdomains, new certificates, and changes to your DNS zone. Catch new surface as it appears, not months later.

Run this loop quarterly at minimum. Monthly is better. The goal is not zero attack surface - that would mean no product. The goal is that every exposed asset is intentional, maintained, and owned.

Ownership

Every public-facing asset needs a named owner - a person who is responsible for its security posture and who will notice if it breaks or gets forgotten. Assets without owners drift. They stop getting patched. Their TLS certificates expire. Their frameworks fall behind. Eventually they become the entry point.

The rule is simple: if an asset does not have an owner, it gets a deletion date. Ownerless assets are how incidents begin with "we did not know that was still live."

For small teams, this means the founder or CTO owns everything by default, and explicitly delegates as the team grows. The delegation does not have to be formal - a line in the spreadsheet is enough. What matters is that someone checks.

What to do this week

1. Run a free security grade on your primary domain. See what a passive scan finds.
2. Export your DNS zone and list every record. Flag anything you do not recognize.
3. Check crt.sh for certificates issued to subdomains you forgot about.
4. Open browser devtools on your main pages and list every third-party domain your site loads from.
5. Pick one forgotten asset and delete it today. A staging server, a dangling DNS record, an unused script tag.
6. Add "attack surface review" to your quarterly calendar. One hour, four times a year.

Your homepage is not the whole product. Your attack surface is.

Run a free security grade on your domain · Pricing