Cloudflare Security Effectiveness Assessment — usphonebook.com

Scope: Single zone — usphonebook.com (zone ID f02804180f31d916e7e5539c8de6781b, Enterprise Website plan) Evidence window: Last 30 days (2026-06-25 → 2026-07-25)

1. Executive Summary

• Very high traffic, actively contested. The zone served 2.00 billion requests / 25.6 TB over 30 days. Enforcement is heavy and real: 457.9M requests (22.9%) were served a 403 and 23.0M received a 429 (rate-limited). (Confirmed)
• Automation is roughly half of scored traffic. Of the ~1.88B requests that received a bot score, ~46% score as likely-human, ~33% as automated, ~21% grey-zone. Cloudflare flagged 118.0M requests as threats. (Confirmed)
• Cloudflare is mitigating abuse effectively — and across multiple mechanisms. Custom rules generated 994.2M events (117.9M hard blocks + 307.7M challenges); the managed-challenge layer issued 352.2M challenges with a ~96.5% abandonment rate; rate limiting fired 27.0M times and is well-targeted at the API and record-scraping paths. (Confirmed)
• The managed WAF and OWASP ruleset are deployed but fully bypassed. Every one of the 87.9M managed-WAF events was a skip — zero blocks. Signature-based protection (SQLi/XSS/RCE/traversal) is therefore not enforcing; the custom-rule layer is effectively the only enforcing tier. (Confirmed)
• Scraping is the dominant threat and it comes from cloud/datacenter networks. Top block sources are Google Cloud (26.0M), DigitalOcean (25.8M), Linode (12.8M), AWS, Alibaba — concentrated in the Netherlands and Germany — hitting person-record pages and the address-suggestion API. (Confirmed)
• Origin-bypass paths are published in DNS. fastly-origin.usphonebook.com (→ 204.44.57.45) and origin.usphonebook.com (→ Fastly anycast 151.101.2.217) are unproxied, exposing an origin-direct route around the Cloudflare edge. (Confirmed)
• Protection maturity is good on the enforcement axis, weak on defense-in-depth. Rate limiting enforces, challenges deter, bot management is active — but with the managed WAF disabled there is no signature backstop, and the origin is reachable directly. (Confirmed)
• Overall risk: HIGH — a PII people-search property under massive, sophisticated scraping, with no enforcing signature WAF and available origin-bypass paths. This is materially offset by genuinely strong custom-rule + challenge + rate-limit enforcement, which is why it is not CRITICAL. Executive score: 68/100.

2. Traffic Overview

30-day totals (Confirmed — httpRequests1dGroups)

Edge response codes (Confirmed): 200 1.147B (57.3%) · 403 457.9M (22.9%) · 304 222.5M · 204 112.4M · 404 24.7M · 429 23.0M · 499 7.87M · 301 4.2M. The 22.9% 403 rate and 23.0M 429s are the visible footprint of an actively enforcing security layer.

Human vs Bot breakdown

Derived from the adaptive bot-score dataset — estimates with stated assumptions. The adaptive 30-day total (≈3.88B) counts more broadly than the billing rollup; ~2.00B were unscored (predominantly cached edge hits that never reach the bot engine). Percentages are given as a share of scored traffic to avoid that distortion.

Verified good bots (Confirmed — verifiedBotCategory, ~259M total): AI Crawler 113.1M · Advertising & Marketing 58.9M · Search Engine Crawler 39.5M · SEO 25.1M · AI Search 12.6M · Security 8.5M · other <1M each. (AI-crawler traffic is the single largest verified-bot category — a notable and growing load.)

Assumptions: (1) botScore < 30 = automated per Cloudflare guidance; (2) unscored traffic excluded from ratios (cache-dominated, not human sessions); (3) verified good bots reported separately as they legitimately score low. Takeaway: this property skews more human than a pure-scraping target, but a third of scored traffic is still automated, and a large share of "good" bot traffic (ad-tech/AI crawlers) is being actively blocked (see §4).

3. Cloudflare Protection Effectiveness

Observed firewall events over 30 days (firewallEventsAdaptiveGroups). Rule thresholds/bodies were not readable (403); ratings rest on observed action volumes.

3.1 Events by source (Confirmed)

3.2 Events by action (Confirmed, all sources)

managed_challenge_bypassed 508.8M · managed_challenge 352.2M · skip 240.1M · block 117.9M · managed_challenge_non_interactive_solved 7.57M · managed_challenge_interactive_solved 4.81M · allow 57.7K. (No log-mode action appears — the posture is challenge/block, not monitor.)

3.3 Per-protection scorecard

Challenge math (Confirmed): 352.2M challenges issued, 12.4M solved → ~96.5% abandonment, the clearest single indicator that challenge enforcement is working. A further 508.8M "bypassed" events are returning clients with valid clearance tokens (benign).

Managed WAF finding (Confirmed): within the managed layer, 100% of 87.9M events are skip and there are zero blocks. The Cloudflare Managed Ruleset (v377) and OWASP Core Ruleset (v88) are deployed but their execution is being skipped for traffic — so there is no active signature-based defense against injection, RCE, path-traversal, or known-CVE exploit patterns. Any such attack is stopped only if a custom rule happens to match it.

Rate limiting finding (Confirmed): two active rate-limit rules challenge (not block) on threshold. Coverage is well-chosen — the top-limited path is /api/address/suggestions (397.6K challenges), followed by person-record pages and funnel assets (see §4). This is genuine, targeted enforcement.

4. Attack Analysis

(All Confirmed from 30-day firewall events unless noted.)

Top attacking countries (block events): Netherlands 42.66M · United States 17.30M · Germany 17.08M · France 4.94M · Brazil 3.37M · Vietnam 2.03M · Italy 1.78M · Sweden 1.64M · Bangladesh 1.54M · Argentina 1.40M · Pakistan 1.36M · India 1.21M. (NL/DE dominance reflects datacenter/hosting scraping, not consumer traffic — NL and DE run at ~99.8% threat rates in raw traffic.)

Top attacking ASNs (operator names from public registries, not Cloudflare data — Likely): AS396982 Google Cloud 26.01M · AS14061 DigitalOcean 25.76M · AS19750 (hosting/datacenter) 15.07M · AS63949 Akamai/Linode 12.79M · AS43515 Google 2.21M · AS45899 VNPT (Vietnam) 1.70M · AS16509 Amazon AWS 0.96M · AS15796 0.93M · AS213954 0.70M · AS46475 Limestone (hosting) 0.63M · AS6400 Claro (Dominican Rep.) 0.50M · AS45102 Alibaba Cloud 0.50M. The attack profile is overwhelmingly cloud/hosting-based scraping.

Top targeted paths (block events): / 1.66M · /favicon.ico 574K · /jason-andrew/UIDM0… 35.4K and /evelyn-ford/U4cjM… 32.2K (person-record pages) · a cluster of /usphonebook/build/{css,js,fonts}/… static assets (bots rendering full pages) · /api/v1/adHandler 19.4K.

Top abusive IPs (block events): 35.212.115.150 (Google Cloud) 2.21M · 164.92.217.61 (DigitalOcean) 1.34M · 159.223.225.123 (DO) 1.26M · 209.38.104.65 (DO) 1.21M · 167.99.214.52 (DO) 1.21M · 134.209.94.6 (DO) 1.18M · 165.232.83.183 (DO) 1.09M · 213.55.229.76 0.93M · 167.99.39.255 (DO) 0.84M · 159.223.226.207 (DO) 0.77M. A DigitalOcean droplet fleet plus a heavy GCP source.

Top blocked user-agents (Confirmed): SirdataBot 38.5M · CriteoBot 15.4M · Chrome-142/Win 2.12M · peer39_crawler 1.78M · assorted spoofed Chrome 144/145 UAs ~1.6M each. (The three highest-volume blocked agents are commercial ad-tech/contextual crawlers — see note below.)

Most common "WAF" detections (Confirmed): because the managed WAF is skipped, all blocks come from custom rules. One rule — 2b7a926d8d21483e832067147918a3ec — accounts for 100.56M blocks (~85% of all blocks); rule fb45a11e… blocks 15.07M (a specific network, matching AS19750); rule f604010b… blocks 2.21M (matching the top GCP IP). Rule names/expressions were not readable (403).

Most common rate-limit triggers (Confirmed): /api/address/suggestions (397.6K challenges) is the primary limited endpoint, followed by person-record pages (/janet-t-bird/…, /allan-m-soobert/…, /jaime-garcia/…), a location page (/Nj-Owner/New-Jersey), and funnel image assets — all via managed challenge.

Abuse-indicator summary

Two evidence limits: (1) Cloudflare edge data cannot confirm account-level or authenticated abuse — that needs backend correlation. (2) With the managed WAF skipped, the zone has no telemetry on signature-based attacks — their absence from this report is a visibility gap, not proof they aren't occurring.

Ad-tech blocking note (Likely, needs business confirmation): the two largest blocked user-agents are legitimate commercial crawlers (Sirdata, Criteo) plus peer39. If these partners are supposed to read the site (e.g., for contextual ad targeting), the custom rules may be over-blocking revenue-relevant bots. If the intent is to exclude them, this is working as designed. This should be confirmed with the ad/revenue team.

5. Protection Coverage

✓ Enabled / Confirmed active

• Enterprise plan; Advanced TLS certificate (Google Trust Services, *.usphonebook.com, valid to 2026-10-12) + Universal certs
• Apex, www, and mobileapi proxied through Cloudflare (origin behind AWS Elastic Beanstalk)
• Custom firewall ruleset — the enforcement engine (117.9M blocks + 307.7M challenges), updated recently (v155)
• Rate limiting — enforcing and well-targeted (v31; /api/address/suggestions, person records)
• Bot Management — entitled and scoring live traffic; Managed Challenge in heavy use (96.5% abandon)
• Security-level reputation challenges active (122.3M events → security level is engaged)
• Cloudflare Managed Ruleset (v377), OWASP Core (v88), Exposed Credentials Check, DDoS L7 — deployed
• URL Normalization; 98.5% encrypted traffic
• DNS hygiene relatively clean (51 records, no RFC1918 leakage)

⚠ Missing protections

• Managed WAF / OWASP enforcement — deployed but 100% skip, zero blocks. No signature-based defense (injection/RCE/traversal/CVE) and no WAF-layer attack telemetry.

⚠ Inconsistent configuration

• Origin-bypass records published: fastly-origin.usphonebook.com (→ origin IP 204.44.57.45, unproxied) and origin.usphonebook.com (→ Fastly anycast 151.101.2.217, unproxied) — a direct route around the Cloudflare edge.
• Rate limiting enforces by challenge, while custom rules block — a defensible but mixed enforcement model worth a deliberate policy review.

⚠ Weak / unverifiable configuration

• Unknown (403, verify with a settings-scoped token): SSL/TLS mode, min-TLS version, HSTS, exact security-level value, Page Shield status, Bot Management action config. Page Shield (client-side/Magecart protection) is especially worth confirming on a data-collection property.

6. Operational Risk: HIGH

Why HIGH (not MEDIUM):

1. No enforcing signature WAF on a PII property. The managed WAF and OWASP ruleset are fully skipped (0 blocks). Injection, RCE, traversal, and known-CVE exploit attempts are neither blocked nor recorded at the WAF layer — the site depends entirely on custom rules matching them. (Confirmed)
2. Origin-direct bypass is published. fastly-origin exposes an origin IP and origin exposes the Fastly anycast front, both unproxied — an attacker can attempt to reach the origin behind the edge. (Confirmed)
3. Confirmed, massive, sophisticated scraping from cloud fleets (GCP/DigitalOcean/Linode) against person records and the address-suggestion API. (Confirmed)

Why not CRITICAL: the enforcement that is running is strong and multi-layered — 117.9M blocks, 352.2M challenges at 96.5% abandonment, 27.0M rate-limit challenges, 22.9% of all traffic 403'd, 23.0M 429s. Rate limiting is well-targeted at the exact scraped endpoints. There is no edge evidence of successful mass exfiltration through the proxied path, and bot management is active.

7. Recommendations (evidence-prioritized)

Highest impact

1. Turn on managed-WAF enforcement. Stop skipping the Cloudflare Managed Ruleset + OWASP Core Ruleset; move them to block (or block for high-confidence signatures first, log the rest briefly to tune false positives). This restores the missing signature-defense tier and its telemetry. Evidence: 87.9M managed events, 100% skip, 0 blocks. — Low–Medium effort
2. Close the origin-bypass paths. Re-proxy or remove fastly-origin / origin records where direct reachability isn't required, and restrict the origin (and Fastly) to accept traffic only from Cloudflare (and required upstreams). Evidence: two unproxied origin records (204.44.57.45, 151.101.2.217). — Medium effort

Sustaining / tuning

1. Confirm the ad-tech bot policy. Decide deliberately whether SirdataBot (38.5M blocked), CriteoBot (15.4M), and peer39 (1.8M) should be allowed; if they are revenue partners, add scoped allow rules; if not, keep blocking. Evidence: top-3 blocked UAs are commercial crawlers. — Low effort
2. Extend rate limiting to remaining record/enumeration paths. The current rules are well-aimed at /api/address/suggestions and some records; broaden coverage to all person-record and search endpoints given the confirmed cloud-scraping pressure. Evidence: person-record pages appear in both block and rate-limit data. — Low effort

Verify (blocked by token scope this run)

1. Confirm SSL/TLS mode = Full (strict), min-TLS ≥ 1.2, HSTS enabled, and Page Shield status with a settings-scoped read token. On a data-collection property, verify Page Shield explicitly. — Low effort

None of these require new licensing — all sit within the existing Enterprise entitlement.

8. Executive Score: 68 / 100

Interpretation: Good enforcement, shallow depth. The active defense (custom rules + challenge + rate limiting) is strong and demonstrably effective; the score is held back by a completely non-enforcing signature WAF and published origin-bypass paths.

Bottom line: usphonebook.com runs a strong, multi-mechanism enforcement posture — heavy custom-rule blocking, effective bot challenges, and genuinely targeted rate limiting are keeping a massive cloud-based scraping campaign contained. The two things standing between this zone and a materially higher score are both fixable inside the current plan: enable the managed WAF/OWASP for enforcement, and close the origin-bypass DNS paths. Doing so adds the missing signature-defense layer and removes the direct-to-origin route, without changing the enforcement that is already working well.