Cloudflare Security Effectiveness Assessment — searchpeoplefree.com

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

1. Executive Summary

High traffic under the heaviest attack pressure of the estate. The zone served 772.5M requests / 5.69 TB over 30 days, with 16.3% of all traffic flagged as threats and 267.2M requests (34.6%) served a 403 — plus 15.2M rate-limited (429). (Confirmed)
Automation is the largest share of scored traffic. Of ~753M scored requests, ~45% score as automated, ~28% likely-human, ~27% grey. US traffic is clean; foreign traffic (Netherlands, Vietnam, Brazil, Argentina, France, Germany) runs at 99%+ threat rates. (Confirmed)
Cloudflare is containing a very large scraping campaign effectively. Custom rules generated 557.1M events (125.9M blocks + 152.3M challenges); the managed-challenge layer runs at a ~94.5% abandonment rate. (Confirmed)
Rate limiting is the strongest of any property reviewed — and well-targeted. It fired 17.8M times, challenging on /find/<name> person-record pages and blocking abusive asset access. (Confirmed)
The Managed WAF / OWASP ruleset is effectively inactive. It generated only 550 events in 30 days — no meaningful signature-based defense (SQLi/XSS/RCE) and no WAF-layer telemetry, despite an exposed /api/v3/getslots API and dynamic record endpoints. (Confirmed)
An admin interface bypasses the edge. admin.searchpeoplefree.com is unproxied, resolving directly to adminsearchpeoplefree.azurewebsites.net — so the admin panel receives no Cloudflare WAF, bot management, rate limiting, or challenge protection. dev is likewise unproxied. (Confirmed)
Security-level challenging is off and custom rules are effectively the only enforcing tier (99.7% of blocks come from a single rule). (Confirmed / Likely)
Overall risk: HIGH — a PII people-search property under intense scraping, with an unproxied admin panel and no active signature WAF, dependent on one enforcing tier. Offset by the strongest production-path enforcement and rate limiting in the estate, which is why it is not CRITICAL. Executive score: 62/100.

2. Traffic Overview

30-day totals (Confirmed — httpRequests1dGroups)

Metric	Value
Total requests	772,508,114 (772.5M)
Cached requests	337,402,301 (43.7%)
Uncached requests	435,105,813 (56.3%)
Total bandwidth	5.69 TB
Encrypted (HTTPS) share	98.1%
Requests flagged "threat"	125,915,846 (~16.3%)

Edge response codes (Confirmed): 304 267.6M (34.6%) · 403 267.2M (34.6%) · 200 181.1M (23.4%) · 301 29.2M · 429 15.2M · 499 4.84M · 404 3.77M · 410 2.98M · 302 587K · 500 79K. The 34.6% 403 rate plus 15.2M 429s is the largest security-enforcement footprint of the estate.

Human vs Bot breakdown

Derived from the adaptive bot-score dataset — estimates with stated assumptions. The adaptive total (≈1.43B) counts more broadly than the billing rollup; ~676M were unscored (predominantly cached edge hits). Percentages are given as a share of scored traffic.

Segment	Definition	Volume	% of scored
Automated / bot	botScore 1–29	339.2M	45.1%
Grey / uncertain	botScore 30–79	205.9M	27.4%
Likely human	botScore 80–99	207.5M	27.6%
(Unscored)	botScore 0 — mostly cached	676.5M	—

Verified good bots (Confirmed — verifiedBotCategory, ~60M total): Search Engine Crawler 19.3M · Advertising & Marketing 17.7M · AI Crawler 13.6M · SEO 3.27M · Security 1.77M · AI Assistant 1.66M · AI Search 1.53M · other <1M each.

Assumptions: (1) botScore < 30 = automated per Cloudflare guidance; (2) unscored traffic excluded from ratios (cache-dominated); (3) verified good bots reported separately as they legitimately score low. Takeaway: this is the most heavily automated property reviewed — automated traffic outnumbers likely-human traffic in scored requests, consistent with the 16.3% threat rate.

3. Cloudflare Protection Effectiveness

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

3.1 Events by source (Confirmed)

Source	Events	Role
Custom rules (`firewallCustom`)	557,072,930	Primary — and effectively only — enforcement engine
Rate limiting (`ratelimit`)	17,795,920	Enforcing (challenge + block), well-targeted — strongest of the estate
IP rules (`ip`)	56,160	Minimal
Managed WAF (`firewallManaged`)	550	Effectively inactive
(Security Level)	0 observed	No reputation challenges firing (Likely off)

3.2 Events by action (Confirmed, all sources)

managed_challenge_bypassed 258.8M · managed_challenge 152.3M · block 125.9M · skip 29.5M · managed_challenge_non_interactive_solved 5.62M · managed_challenge_interactive_solved 2.74M · allow 56.2K. (No log-mode action — posture is challenge/block.)

3.3 Per-protection scorecard

Protection	Events	Blocks	Challenges	Allowed/Skip	Est. effectiveness	Rating
Custom Rules	557.1M	125.88M	152.34M issued	29.5M skip	Terminal blocks enforced; carries the whole zone	Excellent
Managed WAF (Cloudflare Managed Ruleset)	550	550	—	—	Present in inventory but not executing	Missing
OWASP Core Ruleset	within 550	~0	—	—	Not contributing	Missing
Rate Limiting	17.8M	~150K	~17.6M (challenge)	—	Enforcing and well-targeted at record pages	Good / Excellent
Bot Management	drives challenges	via rules	152.3M	—	Scoring active; 94.5% challenge-abandon	Good / Excellent
Managed Challenge	152.3M issued	—	152.3M	8.36M solved	~94.5% did not solve → strong deterrence	Excellent
JS Challenge	not observed	—	—	—	Not in use (managed challenge used)	N/A
Security Level	0 observed	—	0	—	No reputation challenges firing	Missing / Off (Likely)

Challenge math (Confirmed): 152.3M challenges issued, 8.36M solved → ~94.5% abandonment. A further 258.8M "bypassed" events are returning clients with valid clearance tokens (benign).

Managed WAF finding (Confirmed): the Cloudflare Managed Ruleset (v377) and OWASP Core Ruleset (v88) appear in the ruleset inventory but generated only 550 firewall events in 30 days — effectively no execution. There is no active signature-based defense and no WAF-layer telemetry, despite an exposed /api/v3/getslots API and dynamic /find/ and /phone-lookup/ endpoints.

Rate limiting finding (Confirmed): this is a genuine strength. Three active rules fired 17.8M times, correctly aimed at /find/<name>/<id> person-record pages (managed challenge) with block actions on abused static assets. This is the most effective rate-limiting deployment in the estate.

Security-level finding (Likely): no securitylevel-sourced events were observed, indicating reputation-based challenging is not active. The exact setting value returned 403 (Unknown), but its behavioral signature is absent.

4. Attack Analysis

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

Top attacking countries (block events): Netherlands 15.59M · Vietnam 14.37M · Brazil 8.76M · Argentina 7.22M · France 6.76M · Germany 6.23M · Bangladesh 4.81M · Pakistan 4.54M · South Africa 4.52M · Colombia 3.04M · Iraq 2.95M · Russia 2.85M. (US does not appear — US traffic is clean.)

Top attacking ASNs (operator names from public registries, not Cloudflare data — Likely): AS45899 VNPT (Vietnam) 12.95M · AS396982 Google Cloud 10.22M · AS14061 DigitalOcean 7.83M · AS63949 Akamai/Linode 6.46M · AS29066 Velia.net (Germany) 4.41M · AS13238 Yandex 2.71M · AS16509 Amazon AWS 2.62M · AS45102 Alibaba Cloud 1.29M · AS14593 SpaceX Starlink 1.26M · AS22927/AS7303 Telecom Argentina 1.2M/1.1M · AS9541 (Pakistan) 0.92M. The attack profile is a large, distributed cloud/hosting + telco scraping campaign.

Top targeted paths (block events): /robots.txt 1.03M · /favicon.ico 515.6K · /phone-lookup/847-372-2084 222.5K (phone-record lookup) · / 124.7K · /find/Joshua-Fishman/p-3 and /find/matthew-j-zwick/… (person-record pages) · static assets (/content/*, /css/*, /js/*) · /api/v3/getslots 17.7K (API) · /phone-lookup 14.9K.

Top abusive IPs (block events): 92.204.248.55 (GoDaddy hosting) 4.28M · 63.32.23.121 (AWS) 879K · 52.215.186.214 (AWS) 612K · 54.194.183.189 (AWS) 553K · 159.223.225.123, 209.38.104.65, 167.99.214.52, 164.92.217.61, 165.232.83.183, 134.209.94.6 (a DigitalOcean droplet fleet) 270–390K each.

Top blocked user-agents (Confirmed): SirdataBot 14.27M (ad-tech crawler) · then a near-uniform cluster of stale Chrome version strings — Chrome 116, 107, 123, 119, 99, 104, 100 — each ~5.88–5.92M. (The uniform distribution across obsolete Chrome versions is a textbook user-agent-rotation scraping signature.)

Most common "WAF" detections (Confirmed): with the managed WAF inactive, all blocks come from custom rules. One rule — 5a11325108024b65b81c1f6a70e59933 — accounts for 125.48M blocks (~99.7% of all blocks); rules 709da2b6… (178.3K) and 2a2fd9ca… (127.0K) are minor. Rule names/expressions were not readable (403).

Most common rate-limit triggers (Confirmed): rule 6ebe5895… (14.85M challenges) and 97fc8aee… (197K), challenging on /find/<name>/<id> person-record pages (seonmi-lim, enis-reyes, evelysse-reyes, amy-w-lee, …), plus block actions (rule 69fe8df7…) on abused assets and /favicon.ico.

Abuse-indicator summary

Indicator	Evidence	Tier
Scraping	Cloud/hosting + telco ASNs (VNPT 13M, GCP 10M, DigitalOcean 8M, Linode 6M) at scale; SirdataBot 14M; rotating stale-Chrome UAs ~5.9M each	Confirmed — very large
Enumeration	`/phone-lookup/<number>` and `/find/<name>/<id>` record pages heavily blocked and rate-limited	Confirmed
API abuse	`/api/v3/getslots` appears in blocks — automated API access	Likely
Credential abuse	No login POST/auth-endpoint signal on the proxied path; note the admin panel is unproxied and therefore invisible to this data (see below)	Unknown
Authenticated abuse	Not observable from edge data — requires backend session/account correlation	Unknown
Injection/exploit attempts	Would be caught by the managed WAF/OWASP — inactive, so attempts against `/api/v3/getslots` and dynamic paths are neither detected nor recorded	Unknown (blind spot)

Three evidence limits: (1) Cloudflare edge data cannot confirm account-level/authenticated abuse — needs backend correlation. (2) With the managed WAF inactive, the zone has no telemetry on signature-based attacks. (3) The unproxied admin and dev hosts do not pass through Cloudflare at all, so any attack against them is entirely absent from this data — a visibility gap as much as a protection gap.

5. Protection Coverage

✓ Enabled / Confirmed active

Enterprise plan; Universal TLS certificates (Google Trust Services active, valid to 2026-10-06; SSL.com backup)
Apex, www, and uat proxied (origin is Azure App Service — *.azurewebsites.net)
Custom firewall ruleset — the enforcement engine (125.88M blocks + 152.34M challenges), v65
Rate limiting — enforcing and well-targeted at person-record pages (v17) — the estate's strongest deployment
Bot Management — entitled and scoring live traffic; Managed Challenge in heavy use (94.5% abandon)
Cloudflare Managed Ruleset (v377), OWASP Core (v88), Exposed Credentials Check, DDoS L7 — present in inventory (but see gaps)
URL Normalization; 98.1% encrypted traffic

⚠ Missing / inactive protections

Managed WAF / OWASP enforcement — present in inventory but generating only 550 events. No signature defense, no WAF telemetry.
Security-level reputation challenge — no securitylevel events observed; appears essentially off.

⚠ Inconsistent configuration

admin.searchpeoplefree.com is unproxied — the admin interface resolves directly to its Azure hostname, bypassing all Cloudflare edge protection.
dev.searchpeoplefree.com is unproxied — development host directly exposed.

⚠ Weak configuration

Single-tier dependence — custom rules are the only enforcing layer; 99.7% of blocks come from one rule; no signature or reputation backstop.
Azure App Service default hostnames are publicly resolvable — the proxied production origin should be access-restricted at Azure to Cloudflare, or the edge can be bypassed by hostname.
Only Universal certificates (no Advanced certificate).

⚠ Unverifiable configuration (Unknown — 403)

SSL/TLS mode, min-TLS version, HSTS, exact security-level value, Page Shield status, Bot Management action config. Verify with a settings-scoped token; Page Shield is worth confirming on a data-collection property.

6. Operational Risk: HIGH

Why HIGH:

An admin interface bypasses the edge. admin.searchpeoplefree.com is unproxied and directly reachable at its Azure hostname, so the admin panel has no WAF, bot management, rate limiting, or challenge protection and is invisible to security telemetry. On a PII property, an internet-exposed admin surface with no edge filtering is a serious, specific exposure. (Confirmed)
No active signature WAF on a dynamic surface. The Managed WAF/OWASP ruleset generated only 550 events, so injection/exploit attempts against /api/v3/getslots and dynamic record endpoints are neither blocked nor recorded. (Confirmed)
Heaviest attack pressure in the estate (16.3% threats) against record and API endpoints, absorbed by a single enforcing tier. (Confirmed)

Why not CRITICAL:

Production-path enforcement is the strongest reviewed — 34.6% of traffic 403'd, 94.5% challenge abandonment, and the estate's most effective rate limiting (17.8M events, correctly targeting record scraping). (Confirmed)
No raw origin IPs or RFC1918 are published — the primary bypass vector is the specific admin/dev hosts, not the whole origin. (Confirmed)
No edge evidence of successful mass exfiltration on the proxied path. (Confirmed)

7. Recommendations (evidence-prioritized)

Highest impact

Proxy the admin panel (or lock it down at Azure). Put admin.searchpeoplefree.com behind Cloudflare (ideally with Cloudflare Access / IP allowlisting) or, at minimum, restrict the Azure App Service to trusted IPs so the admin interface is no longer openly reachable. Do the same for dev. Evidence: both records are proxied: false to Azure hostnames. — Low–Medium effort
Activate the managed WAF / OWASP ruleset. Bring it into active execution (block high-confidence signatures; brief log-then-tune for the rest) to close the signature-defense gap on /api/v3/getslots and dynamic paths, and restore the missing attack telemetry. Evidence: 550 managed events in 30 days. — Low–Medium effort

Sustaining

Restrict the Azure origin to Cloudflare. Ensure the proxied production App Service only accepts traffic from Cloudflare so the edge cannot be bypassed via the public *.azurewebsites.net hostname. Evidence: origin is a publicly-resolvable Azure hostname. — Medium effort
Turn security level on so known-bad IPs are challenged before reaching the custom rules. Evidence: zero securitylevel events. — Low effort

Verify (blocked by token scope this run)

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

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

8. Executive Score: 62 / 100

Interpretation: Strong production-path enforcement with two serious gaps. The estate's best rate limiting and heavy custom-rule + bot-challenge enforcement contain an intense scraping campaign; the score is held back by an unproxied admin interface, an inactive managed WAF, and an off security level.

Dimension	Assessment	Deduction
Cloudflare coverage	Full ruleset stack in inventory + BM entitlement + proxied production	—
Rate limiting	Estate's strongest — 17.8M events, targeted at record pages	−2 (could extend to API)
WAF maturity	Managed WAF + OWASP inactive (550 events) on a dynamic API surface	−15
Bot protection	Scoring active; 94.5% challenge abandonment	small
Configuration consistency	`admin` and `dev` unproxied — admin panel bypasses the edge	−9
Layered defenses	Custom rules the only enforcing tier; 99.7% of blocks from one rule	−5
Security level	No reputation challenges firing (appears off)	−3
Observed attack success	Production path well-contained (34.6% 403, 94.5% abandon) despite heaviest pressure	small
Verification gaps	Page Shield / TLS mode / HSTS unconfirmed; Universal-only certs; unproxied hosts invisible to telemetry	−4
Total		≈ −38 → 62/100

Bottom line: searchpeoplefree.com absorbs the heaviest scraping load in the estate and does so with its strongest production-path controls — the most effective rate limiting reviewed, heavy custom-rule blocking, and a 94.5% challenge-abandonment rate. Two gaps drive the risk: an unproxied admin interface that bypasses every edge control, and a managed WAF that isn't executing on a property with a live API. Both are fixable inside the current plan — proxy/lock down the admin panel and activate the managed WAF — and together they would remove the estate's clearest bypass exposure and restore the missing signature-defense layer.