What does reducing the attack surface mean?

Reducing the attack surface means shrinking the number of ways an attacker can interact with your systems: fewer reachable hosts, fewer open ports, fewer login pages on the public internet, fewer third-party scripts, fewer domains that can be spoofed, and fewer files a web server will hand out. It is distinct from patching, which fixes weaknesses in things that stay; reduction removes or closes the thing entirely so it never needs patching again. For a website-centric organisation the highest-value reductions are retiring unused hostnames, fixing dangling DNS records, moving admin interfaces behind a VPN or IP allow-list, enforcing HTTPS and email authentication, and removing exposed files. Monitoring then covers the part of the surface — lookalike domains and clones — that you can't reduce yourself.

What is the fastest way to reduce a website's attack surface?

Delete and close before you configure. First, list every hostname under your domain using Certificate Transparency logs and your DNS zone, and retire the ones nobody uses — that removes whole servers' worth of exposure in an afternoon. Second, remove DNS records pointing at services you no longer run, which closes subdomain-takeover risk. Third, take any admin interface (CMS admin, database consoles, remote desktop) off the open internet or at least behind MFA and rate limiting. Only then move to hardening what remains: HTTPS with HSTS, the security headers, cookie flags and DMARC enforcement, each of which a free passive checker can verify in seconds. The whole first pass typically takes a day and needs no new software.

Are Microsoft attack surface reduction rules the same thing?

No. Microsoft Defender for Endpoint's attack surface reduction (ASR) rules are policies applied to Windows devices — for example blocking Office applications from creating child processes, preventing credential theft from the Windows security subsystem, or blocking untrusted USB executables. They shrink the internal, per-device surface and are a good idea on any managed Windows fleet. Reducing your external attack surface, the subject of this guide, is about what the internet can reach: hostnames, services, web applications, email posture and lookalike domains. The two share a name and a philosophy — remove avenues of attack rather than only detecting attacks — but they are configured in different places by different people.

How to Reduce Your Attack Surface — 12-Point Checklist

To reduce your attack surface, remove what doesn't need to exist, close what doesn't need to be reachable, harden what remains, and monitor for what appears without permission. The order matters: deletion beats patching, because a host that's gone never needs a fix again.

Why reduce before you patch or scan?

Every asset on your surface carries recurring cost — updates, certificates, monitoring, the chance it's the one that gets you. Vulnerability scanning tells you which of your hundred hosts need work this month; reduction asks why there are a hundred. In the small-business and agency world the answer is usually sprawl: staging sites that shipped and stayed, microsites from old campaigns, a client's previous developer's test box, an admin panel opened “for the weekend”. None of it is malicious; all of it is reachable. The cheapest security work you will ever do is deleting things.

CISA's hardening guidance this year said it plainly for SharePoint: patch, yes — but first ask whether the server needs to face the internet at all (CISA alert, July 2026). The same logic applies to every admin interface you run.

The 12-point checklist

#	Action	Why it matters	Check it free
1	Retire hostnames you no longer use	Every deleted host is one you never patch, monitor or explain in an incident. Old staging, campaign microsites, dev boxes.	Map your hostnames
2	Remove dangling DNS records	A CNAME to a cancelled SaaS or a deleted cloud resource can be claimed by anyone — subdomain takeover with your name on it.	Subdomain Finder
3	Take admin interfaces off the public internet	wp-admin, phpMyAdmin, SharePoint, PaperCut, database consoles: the exploitation waves of 2026 hit the ones that were reachable, not the ones that were unpatched.	Login rate limit check
4	Close ports that aren't a website or mail	RDP, SSH with passwords, Redis, Mongo, Elasticsearch on the open internet are scanned within minutes of appearing.	—
5	Enforce HTTPS and HSTS everywhere	Plain HTTP that still serves content is an SSL-strip and cookie-theft condition.	HSTS check
6	Set the browser-side headers	CSP, X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy — each removes a class of attack for one config line.	Security headers checker
7	Harden cookies	Secure + HttpOnly on session cookies stops the two easiest ways to steal a login.	Cookie checker
8	Enforce email authentication	SPF, DKIM and DMARC p=reject on sending domains; null MX + v=spf1 -all on domains that never send. Otherwise anyone can email as you.	Email / DMARC checker
9	Remove exposed files and panels	.git, .env, backups, phpinfo, debug endpoints — leaked by deploys more often than by attackers.	Exposed .env / .git guide
10	Cut third-party scripts to the ones you use	Each script is code you run on your users' browsers from a host you don't control; fewer means a shorter CSP and less supply-chain exposure.	CSP checker
11	Register the obvious lookalikes of your brand	The five most likely typosquats cost less than one incident response call.	Domain Monitor
12	Turn on monitoring for what you can't delete	New certificates, new subdomains, clones and lookalikes appear without asking; monitoring is the only reduction that works on other people's actions.	Attack surface monitoring

What if the site runs on Shopify, Webflow or another managed platform?

Then most of items 3–7 are the platform's job, and their edge configuration is usually better than what a small team would set by hand. Your surface shrinks to what you still control: the DNS and email records (items 2 and 8), the apps and scripts you install (item 10), your account security, and the lookalike/clone problem (11–12), which no platform solves for you. Our checkers down-rank platform-managed findings for exactly this reason — a Shopify store is not responsible for Shopify's TLS.

Is this the same as Microsoft's “attack surface reduction rules”?

No. Microsoft Defender's attack surface reduction rules are endpoint policies for Windows devices — blocking Office macros from spawning processes, stopping credential theft from LSASS, and so on (Microsoft docs). They reduce the internal, per-device surface and are worth turning on if you manage Windows fleets. This guide is about the external surface: what the internet can reach. Both are called attack surface reduction; they are different jobs.

Common gotcha: “we'll clean up staging after launch.” Put the decommission date in the launch checklist itself, with an owner. Surfaces don't grow because of decisions; they grow because nobody scheduled the deletion.

For the site owner and for the developer

For the site owner (plain English)

Ask three questions of whoever runs your web presence: What websites and subdomains do we have, and which ones could we switch off today? Is any admin login reachable from the open internet? Can a stranger send email that looks like it comes from us? The honest answers to those three usually cut the risk more than any product purchase — and the follow-up is to switch on monitoring for the things that appear without your permission.

Items 11 and 12 are the ones you can't do by deleting things: lookalike domains and cloned sites are other people's actions. The Domain Monitor watches for them on your verified domain — free during the beta.

Monitor your domain →

For the developer / IT (commands for the deletion pass)

# Which of our hostnames still resolve, and to what? (retire the rest; fix dangling CNAMEs)
for h in $(cat hosts.txt); do
  a=$(dig +short "$h" | tail -1); c=$(dig +short CNAME "$h" | head -1)
  printf "%-40s A=%-16s CNAME=%s\n" "$h" "$a" "$c"
done

# Which live hosts answer on ports other than 80/443? (your own hosts only)
nmap -Pn -p 22,25,110,143,3306,3389,5432,6379,9200,27017 --open -iL live.txt

# Does any host still serve content over plain HTTP instead of redirecting?
for h in $(cat live.txt); do printf "%s %s\n" "$h" "$(curl -s -o /dev/null -w '%{http_code}' http://$h/)"; done

# Email: no-send domains should be unspoofable
# TXT "v=spf1 -all"   ·   MX "0 ."   ·   _dmarc TXT "v=DMARC1; p=reject"

Re-run the pass after each launch and migration; the diff is your reduction report. Pair it with the passive Website Security Score on every host that survives the cut.

How to Reduce Your Attack Surface: A 12-Point Checklist for Websites and Small Networks