What can go wrong
The path to
your site
Before anyone sees your homepage, their request crosses five gates. Each one can be left standing open. Here is what happens at each, and what it costs when nobody is posted there.
Request trace — visitor to origin
Idle. Press Send a request to trace a visitor's path.
Turn the warden off to see where an unattended site breaks.
The whole route, end to end
From the name you lease to the server that answers
Every visit to your website crosses six pieces of infrastructure, run by six different parties, each one trusting what the step before it said. That trust is the whole design of the internet — and every protection below exists because one of those steps takes somebody's word for something. Walk the route, then flip the shields on.
-
01
Registrar & registry
The name is leased
You lease your domain through a registrar, which records you as the holder in the global registry for your ending — .com, .net, and so on. Every other step hangs off this one database entry, and it stays yours only as long as someone renews it and nobody moves it.
- Transfer, update & delete locks at the registrar
- Auto-renew with monitored contact addresses
- DNSSEC keys signed into the registry itself
-
02
DNS resolution
The name becomes an address
A visitor's resolver asks your authoritative DNS servers what IP address the name points to. The answer travels back across networks that could, without protection, alter it in transit — and the visitor's browser would believe whatever arrived.
- DNSSEC — forged answers fail validation instead of resolving
- Anycast authoritative DNS that survives regional outages
- Proxied records — the origin's real IP is never published
- TTLs chosen deliberately, short enough to move in an incident
-
03
BGP routing
The internet finds that address
An IP address is only useful if traffic can reach it. Networks announce to each other which addresses they can deliver — that's BGP — and every router along the way believes those announcements. When another network claims your address space, by mistake or on purpose, traffic simply goes there instead, and nothing on your end sees it leave.
- RPKI — signed authorizations state which AS may originate each prefix
- Route-origin validation — participating networks can reject RPKI-invalid announcements
- Hijack monitoring — alerting when your space appears where it shouldn't
This is the step almost nobody watches — and for organizations with their own IP space, the one WolfWarden consults on directly.
-
04
TLS handshake
The server proves itself
Before a single byte of the page moves, the browser and server agree on encryption and the server proves it is who it claims to be, using a certificate a trusted authority issued. Fail this and the visitor doesn't see an error — they see a full-page warning telling them to leave.
- Certificates issued and renewed automatically, monitored before expiry
- Modern protocol floor — TLS 1.2 minimum, 1.3 preferred
- HSTS — the browser refuses plaintext before ever asking
-
05
The edge
The traffic is judged
Every request — the customer, the scraper, the credential-stuffing bot, the forty-gigabit flood — arrives at the network edge, and this is the only place anyone decides who gets through. A site without a controlled edge accepts everything and sorts out the damage later.
- DDoS absorption across a network sized for far worse
- Web application firewall, updated as vulnerabilities are disclosed
- Bot filtering and rate limits on the paths that matter
-
06
The origin
The site finally answers
Only now does your actual website respond — the code, the content, whatever platform it runs on. Everything before this step existed to make sure the request arriving here is real, encrypted, and welcome.
- Origin locked to accept connections from the edge alone
- Versioned deploys — any change rolls back in minutes
- Security headers enforced on every response
- Backups that have actually been restore-tested
Six parties, six handoffs, and a visitor who sees none of it — a page simply loads. The five gates below walk the steps WolfWarden guards on every site, in the same order the route runs them.
Three proofs hold the route together
DNSSEC · RPKI · TLS — verifiable claims at three layers
The route above runs on trust — resolvers believe answers, routers believe announcements, and browsers believe servers. DNSSEC and TLS sign the data or identity being verified; RPKI publishes signed origin authorizations that route validators compare with BGP announcements. Different objects, same goal: replace an unsupported claim with something independently verifiable.
Step 02 · The lookup
DNSSEC
signs your DNS answers
Your records are published with signatures that chain all the way up to the registry. A validating resolver can prove the answer it received is the one you actually published — not one swapped in somewhere along the way.
Step 03 · The route
RPKI
publishes signed origin authorizations
The holder of an address block publishes a signed Route Origin Authorization naming the AS permitted to originate a prefix. Networks performing route-origin validation compare BGP announcements with validated ROA data before applying routing policy.
Step 04 · The handshake
TLS
signs your server's identity
A certificate authority the browser already trusts vouches, cryptographically, that this server is entitled to answer for your name. The browser checks that signature before a single byte of the page moves.
Three layers, one principle: don't ask the internet to be honest — make forgeries fail. WolfWarden configures all three, and the checks run on every single visit without anyone noticing. Which is the point.
The name
Domain registration & DNSSEC
Your domain is a lease, not a purchase. A registrar holds it on your behalf and renews it as long as someone is paying and paying attention. It is the single most valuable thing you own online, and it is usually the least defended — because it only needs attention twice: when you set it up, and the day something goes wrong.
Left open
- The lapse. Renewal notices go to a mailbox that belonged to someone who left. The domain expires. The site and the email both stop, together, without warning.
- The transfer. Without a registrar lock, an attacker who reaches your account can move the domain out. Recovery is measured in weeks.
- The forgery. No DNSSEC means DNS answers for your domain can be tampered with in transit, and a resolver has no way to tell.
Warded
- Locks on. Registrar and transfer locks set, so no move happens without deliberate unlocking.
- Contacts that answer. Renewal and admin contacts on a monitored shared mailbox, never a personal one. Auto-renew with a card that has an expiry alert.
- Signed delegation. DNSSEC enabled, so forged answers fail validation instead of resolving.
$ whois yourdomain.com Domain Status: clientTransferProhibited Domain Status: clientDeleteProhibited Domain Status: clientUpdateProhibited DNSSEC: signedDelegation Registry Expiry Date: 2029-03-14 (auto-renew on) $ whois unattended.example Domain Status: ok ← no locks. anyone with account access can transfer. DNSSEC: unsigned Registry Expiry Date: 2026-08-02 ← 8 days out, contact bounces
The direction
DNS resolution
A domain name is not an address. DNS is the lookup that turns one into the other, and it runs before every single connection to your site — web, mail, everything. When DNS is wrong or slow, nothing downstream matters, because nobody ever arrives to find out.
Left open
- The undocumented record. Nobody knows what half the entries do, so nobody dares remove any of them, so they stay forever.
- The dangling CNAME. A subdomain still points at a service you cancelled. Someone else claims that service name and now serves content on your domain.
- The long TTL. You need to move fast during an incident, but resolvers worldwide cached the old answer for 24 hours.
- The exposed origin. Your A record publishes your server's real IP, so an attacker skips every protection you paid for and hits it directly.
Warded
- An inventory. Every record documented with what owns it and why, reviewed when services change.
- Proxied by default. Web records resolve to the edge, not to your origin. The real address is never published.
- TTLs chosen on purpose. Short enough to move during an incident, long enough not to punish normal traffic.
- Anycast authoritative DNS so a regional outage does not take your name off the internet.
$ dig +short unattended.example A 203.0.113.47 ← the actual server. attackers connect here and bypass everything. $ dig +short yourdomain.com A 104.21.x.x 172.67.x.x ← edge addresses. origin never appears in public DNS.
The handshake
TLS & certificates
Before a single byte of your page moves, the browser and the server agree on an encrypted channel and the server proves it is who it claims to be. That proof is the certificate. When it fails, the visitor does not see a small warning — they see a full-page red interstitial telling them your site is dangerous, and most of them leave.
Left open
- The expiry. Certificates are short-lived by design. A manual renewal that gets missed takes the whole site down at a specific hour on a specific day, usually a weekend.
- Old protocol versions. TLS 1.0 and 1.1 still enabled because nobody turned them off, failing audits and weakening every connection.
- The first visit. Without HSTS, a visitor typing your name plainly can be downgraded to HTTP before the redirect ever runs.
- Mixed content. One image loaded over HTTP breaks the padlock on an otherwise secure page.
Warded
- Automated issuance and renewal, with monitoring that alerts on the certificate rather than on the outage it causes.
- TLS 1.2 floor, 1.3 enabled, with weak ciphers disabled.
- HSTS with a long max-age, so the browser refuses plaintext before it ever sends the request.
- Always Use HTTPS at the edge, so no plaintext path exists to begin with.
$ curl -sI https://yourdomain.com HTTP/2 200 strict-transport-security: max-age=31536000; includeSubDomains; preload content-security-policy: default-src 'self'; frame-ancestors 'none' x-content-type-options: nosniff referrer-policy: strict-origin-when-cross-origin permissions-policy: geolocation=(), camera=(), microphone=()
The gate
DDoS mitigation, WAF, bot filtering
This is the only place where you get to decide who reaches your site at all. Everything before it is addressing; everything after it is your actual application, with all its plugins and its unpatched corners. A gate you do not control is a gate that is open.
Left open
- The flood. Volumetric traffic saturates your host. The site is down, and because most hosts bill for bandwidth, the attack also arrives as an invoice.
- Credential stuffing. No rate limiting on the login form, so lists of leaked passwords get tried against your admin panel around the clock.
- Scrapers and probes. Automated traffic looking for known plugin vulnerabilities, hitting every path on your site, all day, unmetered.
- The bypass. Protection sits in front of a server whose real address is public, so it is skipped entirely.
Warded
- Absorbed at the edge, across a network sized for attacks far larger than anything aimed at a typical business site.
- Managed WAF rules updated as new vulnerabilities are disclosed, not when someone remembers to check.
- Rate limits on the paths that matter — login, search, forms, checkout.
- Origin locked so it only accepts connections from the edge, closing the bypass.
Legitimate visitors 1,214 Automated requests 18,663 — vuln scanners 9,401 — login attempts 6,882 against /wp-login.php — content scrapers 2,380 Blocked at the edge: 18,663 — none of it reached the server. Illustrative volumes for a site with no public profile.
The post
Where the site actually lives
The final gate is the site itself. Most business sites run software with a large surface area — a CMS, a theme, a stack of plugins from different authors on different update schedules. Every one of those is a door, and the ones you did not install are the ones you will forget to lock.
Left open
- The plugin nobody uses. Installed once for a campaign in 2021, never removed, no longer maintained, publicly known to be vulnerable.
- Backups that were never restored. An untested backup is a belief, not a recovery plan.
- The shared neighbour. On cheap shared hosting, a compromise next door can become a compromise on your site.
- No way back. Changes made directly on the live server, with no record of what the working state used to be.
Warded
- A smaller surface. Static assets served from the edge, with dynamic behaviour narrowed to only what the site genuinely needs.
- Versioned deploys, so rolling back is a command, not an excavation.
- Security headers enforced on every response, not just the pages someone remembered to check.
- Restores tested, on a schedule, before you need them.
Mail takes a different road
SPF, DKIM, DMARC & deliverability
Email does not travel the path above. It uses different records, arrives at different servers, and fails in a way the other gates never do: quietly, at someone else's end. Your site being up tells you nothing about whether your invoices are reaching customers, or whether someone is sending mail as you right now.
Left open
- Anyone can be you. With no DMARC policy, a stranger can send mail with your domain in the From line, to your customers, and it will land in their inbox.
- The lookup ceiling. SPF permits ten DNS lookups. Workspace plus a mail platform plus a CRM plus a helpdesk exceeds it easily, and once you cross it SPF does not degrade — it fails permanently.
- Stuck at monitor. A DMARC record published at
p=noneand never advanced. It watches. It does not stop anything. - Mixed reputation. Marketing blasts and your invoices sending from the same domain, so one spam complaint run damages both.
Warded
- A full authentication set — SPF within budget, DKIM signing on every sending service, DMARC aligned.
- Walked to enforcement. Monitor, then quarantine, then reject, moving only when the reports show nothing legitimate will break.
- Streams separated by subdomain, so bulk sending reputation cannot contaminate the mail your business depends on.
- Reports actually read, monthly, catching the new tool a department signed up for without telling anyone.
Counts the lookup-generating mechanisms in the record you paste. Nested lookups inside each include: add to the real total, so a record that looks close to the limit here is often already over it.
Three questions
Your certificate expires at 3am Saturday and nobody renews it. What does a visitor see on Saturday morning?
Your SPF record needs twelve DNS lookups to evaluate. What happens?
You have a WAF in front of your site, but your DNS A record still publishes your server's real IP address. How much protection do you have?
One page per protection, in plain English
What each one is, how it fails, and how it gets fixed
Where this leaves you
Most of these gaps are
invisible until they aren't
Nothing on this page shows up in a site that looks fine. If you would like someone to walk your five gates and tell you plainly which ones are standing open, that is the work.
Run the free scanSee website security service