DDoS Exposure Self-Assessment Quiz
Evaluate your hosting architecture, edge caching, WAF defenses, and rate limiting rules to identify where your website may be exposed to traffic floods.
1. Cloud Proxy & Web Application Firewall (WAF)
How is incoming HTTP/HTTPS traffic routed to your website?
2. Dynamic HTML Caching & Origin Offload
How are anonymous page views served to non-logged-in visitors?
3. Login & Sensitive Endpoint Rate Limiting
Are high-cost endpoints (/wp-login.php, xmlrpc.php, WooCommerce checkout) throttled?
4. Origin IP Address Obfuscation
Is your real hosting server IP address hidden from public DNS history and outbound emails?
Low Exposure
Here is where your setup may be exposed:
Technical Deep-Dive: DDoS Resilience for WordPress
📌 On this page
1. The four exposure areas this assessment evaluates
This tool scores four independent architectural dimensions: whether a CDN/WAF proxy sits in front of your origin (absorbing volumetric attacks before they reach your server), whether anonymous page views are served from edge cache (removing PHP/database load from the attack surface entirely), whether high-cost endpoints like login and checkout are rate-limited (preventing brute-force and credential-stuffing floods), and whether your real origin server IP is hidden from public discovery (preventing attackers from bypassing your WAF by targeting the server directly). Each area compounds with the others — strong protection in three areas can be undermined by a single exposed weak point, particularly origin IP exposure.
2. Volumetric vs application-layer attacks
Layer 3/4 (network-layer) attacks like SYN floods and UDP amplification attempt to overwhelm raw network bandwidth and connection-handling capacity — these are typically mitigated by the sheer scale of a major CDN's network, which can absorb traffic volumes far beyond what a single origin server's connection could handle. Layer 7 (application-layer) attacks like HTTP floods and Slowloris are more insidious because they look like legitimate traffic at the network level — each individual request is valid HTTP, but the volume or pattern is designed to exhaust PHP workers, database connections, or memory, requiring behavioral analysis (rate limiting, bot detection, CAPTCHA challenges) rather than raw bandwidth to mitigate.
3. Why WordPress-specific endpoints are common targets
wp-login.php and xmlrpc.php are disproportionately targeted because they are PHP-execution-heavy, publicly known by exact URL on virtually every WordPress install, and (for xmlrpc.php specifically) can be abused for pingback-based amplification attacks where a single malicious request causes your server to make outbound requests to a third-party target, implicating your site as an unwitting participant in an attack against someone else. Disabling XML-RPC entirely (when your site doesn't use it for legitimate purposes like the WordPress mobile app or Jetpack) and rate-limiting wp-login.php are two of the highest-leverage, lowest-effort hardening steps available.
4. Origin IP protection in depth
A CDN/WAF only protects you if attackers are forced to go through it — if your real server IP is discoverable (via historical DNS records, exposed email headers, SSL certificate transparency logs, or a misconfigured subdomain that bypasses the proxy), an attacker can simply target that IP directly, completely bypassing your WAF and rate limiting. Cloudflare Authenticated Origin Pulls (and equivalent features on other providers) close this gap by configuring your origin server to only accept connections carrying a valid TLS client certificate issued by the CDN, rejecting any direct traffic even if the IP is known.
5. Full-page caching as a defense mechanism
Full-page edge caching is often thought of purely as a speed optimization, but it is equally significant as a DDoS defense: when anonymous page views are served as static HTML directly from edge PoPs, a flood of requests for cached pages never reaches your origin's PHP/database layer at all — the CDN simply serves the same cached response repeatedly, at a scale a single origin server could never match. This is why a well-cached site can often absorb traffic spikes that would flatten an uncached equivalent, even without any dedicated anti-DDoS service active.
6. A prioritized hardening roadmap
If starting from an unprotected baseline, the highest-leverage sequence is generally: first, put a CDN/WAF proxy in front of the site (even a free-tier Cloudflare account provides meaningful baseline protection); second, enable full-page edge caching for anonymous traffic; third, enable Authenticated Origin Pulls or an equivalent origin firewall rule restricting inbound traffic to only the CDN's IP ranges; and fourth, add rate limiting to login and checkout endpoints with XML-RPC disabled if unused. Each step meaningfully reduces exposure on its own, but the combination closes the gaps any single layer leaves open.
Frequently Asked Questions
What is the difference between Layer 3/4 and Layer 7 DDoS attacks?
Layer 3/4 attacks (SYN floods, UDP amplification) target network bandwidth and port infrastructure. Layer 7 attacks (HTTP GET/POST floods, slowloris) target application resources (PHP execution, database queries), exhausting server CPU and memory with fewer requests.
How does Cloudflare or edge reverse proxying protect an origin server?
By acting as an intermediary proxy, a reverse proxy absorbs volumetric traffic across its multi-terabit edge network, challenges suspicious automated bot signatures, and only forwards legitimate, sanitized requests to your origin server.
What are Cloudflare Authenticated Origin Pulls (AOP)?
AOP uses TLS client certificates to ensure your origin web server only responds to requests coming directly from Cloudflare's IP addresses, preventing attackers from bypassing the WAF by hitting your server IP directly.
Is this self-assessment tool an absolute security guarantee?
No. This self-assessment tool is an educational diagnostic designed to help you identify common architectural exposure areas. Advanced threat actors utilize diverse attack vectors that require multi-layered defensive security operations.
Does this tool scan my actual website or infrastructure?
No. This is a self-reported questionnaire — every score is based entirely on the answers you select about your own architecture, not a live scan, port check, or origin-IP lookup performed by Nimbica. It requires honest self-knowledge of your own hosting setup (whether you use a CDN, whether rate limiting is configured, whether your origin IP is exposed) to produce a meaningful result.
Why does an uncached, direct-to-origin WordPress site get flagged as high exposure even without a real attack?
Because the same architectural weakness that makes a site vulnerable to a malicious DDoS attack also makes it fragile against entirely legitimate traffic spikes — a viral social media post, a product launch, or a Black Friday sale can generate the same PHP-worker exhaustion and 504 Gateway Timeouts as a deliberate attack. The hardening this tool recommends (edge caching, a CDN/WAF proxy, rate limiting) improves resilience against both scenarios simultaneously, which is part of why it is worth doing even for sites that consider themselves unlikely attack targets.