AcmeCorp - Cloudflare Application Services SRA

TL;DR: Configured Cloudflare-proxied A records for all lab hostnames pointing to the requested origin IPs and verified reachability via DNS lookups and Ray IDs.

Cloudflare features used: DNS (proxied A records), CDN reverse proxy, Security Events / Ray ID.

Configuration delivered: Configured Cloudflare DNS with proxied A records for all required hostnames, matching the lab’s IP assignment:

• innovative-trailblazer.sxplab.com – A record to 20.88.188.200, proxied through Cloudflare.
• staging.innovative-trailblazer.sxplab.com – A record to 20.88.188.200, proxied.
• support.innovative-trailblazer.sxplab.com – A record to 20.88.188.200, proxied.
• api.innovative-trailblazer.sxplab.com – A record to 4.157.169.241, proxied.
• origin1.innovative-trailblazer.sxplab.com – A record to 52.191.5.18, proxied and used as the Singapore origin in Load Balancing.
• origin2.innovative-trailblazer.sxplab.com – A record to 52.170.37.97, proxied and used as the Frankfurt origin in Load Balancing.

Outcome & rationale: All required hostnames are consistently routed through Cloudflare, providing a single control plane for performance, security, and advanced traffic steering while matching the IP assignments defined in the lab brief.

Validation performed: Used dig and nslookup to confirm that each hostname resolved to the correct IP address, and accessed https://innovative-trailblazer.sxplab.com via a browser to verify that responses included a Cloudflare Ray ID, confirming end-to-end connectivity through the proxy.

Evidence:

• Cloudflare DNS overview page showing proxied A records for all six lab hostnames with the specified IP addresses and orange-cloud (proxied) status (see Figure 1).

Figure 1: DNS configuration for all lab hostnames.

Configuration delivered: To address inconsistent load times across Southeast Asia, Europe, and the US, we configured Cloudflare’s performance features in layers:

• Cache Rules for static assets (eligibility & cache key): We defined Cache Rules so that static assets (images, CSS, JS, fonts) under paths such as /assets/*, /static/*, and other immutable file extensions are consistently eligible for edge caching and use a stable cache key. The specific edge and browser TTL values are tuned separately in Answer 3.
• Measurement (RUM & Speed Brain): We enabled Web Analytics using real user measurement (RUM) and Speed Brain so that Cloudflare can collect privacy-preserving performance telemetry and automatically tune delivery based on how real users experience the site.
• Image optimisation: We turned on Polish to safely optimise images (compression and modern formats where appropriate), reducing payload size without requiring any changes on the origin.
• Protocol optimisations: We enabled HTTP/2, HTTP/3, HTTP/2 to origin, Enhanced HTTP/2 Prioritization, 0-RTT Connection Resumption, and TLS 1.3 so that both edge and origin connections use modern, low-latency protocols by default.
• Early Hints: We enabled Early Hints so that Cloudflare can send 103 responses with critical resource hints to the browser, improving first paint and overall page load time for repeat visitors.
• Argo Smart Routing: We enabled Argo Smart Routing to route dynamic and cache-miss traffic over optimised Cloudflare network paths, reducing latency and connection errors between users and the origin.

Outcome & rationale: Static content is now served primarily from Cloudflare’s edge cache, while dynamic and non-cacheable traffic benefits from protocol-level optimisations and Argo Smart Routing. Image payloads are smaller, round-trips are faster (HTTP/2, HTTP/3, TLS 1.3, 0-RTT), and browsers receive Early Hints to start loading key assets sooner. Together, these changes improve page-load times across SEA, EU, and US without requiring any application refactoring.

Validation performed:

• Requested representative static assets twice from different geographic locations and confirmed that the second and subsequent requests returned CF-Cache-Status: HIT.
• Used browser devtools and curl -v to verify negotiated protocols (h2/h3), the presence of TLS 1.3, and 0-RTT resumption where supported.
• Observed reduced image transfer sizes with Polish enabled and confirmed that visual quality remained acceptable on key pages.
• Checked response headers and the Argo dashboard to validate that Smart Routing was active and that traffic was traversing optimised Cloudflare network paths.

Evidence:

• Cache Rule definition for static assets showing which paths and file types are eligible for edge caching (see Figure 2a).
• Speed & Optimisation settings panel showing RUM, Speed Brain, Polish, HTTP/2, HTTP/3, 0-RTT, TLS 1.3, and Early Hints enabled (see Figure 2b).
• Argo Smart Routing configuration view confirming that Argo is enabled for the zone (see Figure 2c).

Figure 2a: Cache Rules for static assets.

Figure 2b: Speed & optimisation feature set.

Figure 2c: Argo Smart Routing enabled for dynamic traffic.

Advanced recommendations (production-ready options):

• Smart Shield with Tiered Cache: Where available, enable Smart Shield together with Tiered Cache. Tiered Cache further reduces origin load by having lower-tier POPs fetch from upper-tier cache nodes instead of the origin, while Smart Shield leverages Cloudflare’s network intelligence to minimise cold cache-misses and improve resilience for long-tail geographies.
• Cloudflare Images for dynamic image delivery: Move image delivery to Cloudflare Images so that the platform can automatically resize, crop, and reformat images per device (different resolutions, DPR variants, WebP/AVIF where supported). This keeps pages fast on mobile and low-bandwidth connections without changing the application code significantly.
• R2 for static asset offload: Store heavy static assets (JS, CSS, large media, downloads) in Cloudflare R2 and serve them directly through Cloudflare. This reduces dependence on the origin infrastructure, avoids traditional cloud egress charges, and pairs naturally with Tiered Cache for global distribution.
• Originless / edge hosting with Workers: For a next phase, the application can be hosted directly on Cloudflare’s edge using Cloudflare Workers (and, where appropriate, Workers + Pages for static/frontend assets). This removes an extra network hop to a centralised origin, bringing HTML generation and routing as close as possible to users in SEA, EU, and the US.

TL;DR: Building on the static-asset Cache Rules defined in Answer 2, we set edge cache TTL to 10 minutes and browser cache TTL to 5 minutes for frequently accessed assets to cut origin bandwidth while keeping content reasonably fresh.

Cloudflare features used: Cache Rules (Edge TTL, Browser TTL), cache-control override, Cache Analytics.

Configuration delivered: To reduce repeated origin data transfer and server load for frequently accessed files, we:

• Applied a Cache Rule to set the Edge TTL for frequently accessed static assets to 10 minutes, ensuring they remain in Cloudflare edge cache during normal traffic patterns.
• Set the Browser Cache TTL for the same asset classes to 5 minutes, so client browsers reuse cached responses for short periods while still being able to pick up updates quickly.
• Confirmed that origin Cache-Control headers did not conflict with the intended behaviour, overriding them at the edge where necessary using Cache Rules.
• Aligned with the SRA description, which originally referenced /static and /assets/, but adapted to the real application layout where images and static content are actually served under paths like /services and /images. To ensure we still targeted all relevant static files, we added an extra condition in the Cache Rule expression:
  (lower(http.request.uri.path) matches r#"\.(css|js|mjs|map|png|jpe?g|gif|webp|avif|svg|ico|woff2?|ttf|eot|otf|pdf|mp4|webm)$"#)
  This captures static assets by file extension regardless of the path prefix, covering both the SRA-specified directories and the actual lab paths.

Outcome & rationale: Frequently accessed files are served from edge cache and revalidated less often at the origin, directly reducing bandwidth usage and connection load on the backend while respecting the 10-minute edge / 5-minute browser requirement. The extension-based condition ensured that all real static content (including assets under /services and /images) was included, not just the theoretical /static and /assets paths from the SRA description.

Validation performed: We:

• Verified the Cache Rule expression and TTL settings in the Cloudflare dashboard.
• Used curl against representative static resources (for example files under /services and /images) and confirmed CF-Cache-Status: HIT on subsequent requests, along with cache-related headers reflecting a 10-minute edge TTL and an effective 5-minute browser cache window.

Evidence:

• Cache Rule configuration showing the combined path + extension-based condition and the configured edge / browser TTL values (see Figure 3a).
• curl output for a static asset under /services or /images demonstrating CF-Cache-Status: HIT on repeat requests and cache headers aligned with the 10-minute edge / 5-minute browser policy (see Figure 3b).

Figure 3a: Cache Rule – edge and browser TTL with regex-based static asset matching.

Figure 3b: curl validation – CF-Cache-Status HIT and cache headers for a static asset.

TL;DR: Enforced HTTPS end-to-end with Full (strict) TLS, short-lived edge certificates from Google Trust Services, and a PCI-aligned cipher profile.

Cloudflare features used: SSL/TLS (Full strict), Edge Certificates (Google Trust Services), Always Use HTTPS, TLS encryption mode / cipher profiles.

Configuration delivered: To ensure all user traffic uses HTTPS with full end-to-end encryption and a compliant TLS posture, we:

• Set SSL/TLS mode to Full (strict) so that Cloudflare validates the certificate presented by the origin before establishing the connection.
• Enabled Always Use HTTPS for the zone so that all HTTP requests are automatically redirected to HTTPS.
• Used Cloudflare’s certificate management to issue edge certificates via the Google Trust Services CA pipeline, with automatic renewal on a ~3-month cadence (short-lived certs) and no manual certificate handling required.
• Configured the TLS cipher profile to a PCI-DSS-aligned level (for example the “PCI DSS” / “TLS 1.2 only (PCI)” style setting in the TLS configuration), disabling legacy and non-compliant ciphers.

Outcome & rationale: Traffic between end users and Cloudflare, and between Cloudflare and the origin, is fully encrypted under a validated TLS posture. The edge certificate lifecycle is automated using the Google Trust Services pipeline with short-lived certificates, and the negotiated cipher suites align with PCI DSS expectations, reducing the risk of weak or deprecated cryptography being used.

Validation performed:

• Executed curl -I http://innovative-trailblazer.sxplab.com and observed an HTTP→HTTPS redirect, confirming that Always Use HTTPS is in effect.
• Used browser devtools / certificate viewer and external TLS inspection to confirm that:
  • The certificate chain presented to clients is issued by a Google Trust Services CA.
  • Certificates are managed and renewed by Cloudflare (short-lived lifecycle).
  • Only strong, PCI-aligned cipher suites are negotiated during TLS handshakes.

Evidence:

• SSL/TLS overview for innovative-trailblazer.sxplab.com showing Full (strict) mode enabled (see Figure 4a).
• Zone setting with Always Use HTTPS toggled on (see Figure 4b).
• curl -I http://innovative-trailblazer.sxplab.com output showing a 301 redirect to HTTPS (see Figure 4c).
• Edge Certificates and SSL/TLS overview confirming issuance via Google Trust Services and automated management by Cloudflare (see Figure 4d).
• TLS settings views showing PCI-aligned cipher suite / TLS profile selection (see Figures 4e and 4f).

Figure 4a: SSL/TLS overview showing Full (strict) mode.

Figure 4b: Always Use HTTPS enabled.

Figure 4c: curl -I http://innovative-trailblazer.sxplab.com confirming HTTP→HTTPS redirect.

Figure 4d: Edge certificates and Google Trust Services CA pipeline.

Figure 4e: PCI-aligned TLS cipher suite configuration.

Figure 4f: PCI-DSS cipher profile selection.

TL;DR: Locked down the staging hostname so only users in Singapore, Germany, and the United States can reach it; all other countries are blocked or must pass a Managed Challenge.

Cloudflare features used: WAF / Rulesets, Geo-IP conditions (ip.src.country), Block / Managed Challenge actions.

Configuration delivered: To restrict access to staging.innovative-trailblazer.sxplab.com so that only users in Singapore, Germany, and the United States can reach it, we:

• Created an application security rule (via WAF or Ruleset) scoped to the staging hostname with a geo-based condition. The core rule expression is:
  (http.host eq "staging.innovative-trailblazer.sxplab.com"
  and not ip.src.country in {"SG" "DE" "US"})
• Configured the rule action to Block or Managed Challenge for requests where ip.src.country is not in {"SG","DE","US"}, while implicitly allowing requests from those three countries.
• Ensured the rule is scoped only to staging.innovative-trailblazer.sxplab.com, so production and other hostnames remain unaffected by this geo restriction.

Outcome & rationale: The staging environment is accessible exclusively from Singapore, Germany, and the United States, reducing exposure to unwanted global traffic while keeping the production environment fully available worldwide. This aligns staging with a “limited collaborator regions only” model without impacting customer-facing sites.

Validation performed:

• Used test endpoints and country simulation / overrides to generate traffic from both allowed and disallowed regions.
• Confirmed that non-SG/DE/US traffic to https://staging.innovative-trailblazer.sxplab.com triggered the geo rule and was blocked or challenged as configured.
• Verified that traffic from Singapore, Germany, and the United States reached the staging application without being blocked by the geo control.

Evidence:

• WAF / Ruleset configuration showing the geo-based rule for staging.innovative-trailblazer.sxplab.com using not ip.src.country in {"SG" "DE" "US"} with Block / Managed Challenge as the action.
• Security Events view demonstrating blocked or challenged requests from non-allowed countries attempting to access the staging hostname, and allowed events from SG/DE/US.

(see Figure 5).

Figure 5: Geo-restricted access to staging.innovative-trailblazer.sxplab.com.

TL;DR: Enabled OWASP-aligned managed rules globally for all lab hostnames and layered stricter, dedicated managed rules on /services/safes and /services/business-sales to harden those flows against zero-day exploits.

Cloudflare features used: WAF managed rules (OWASP), additional managed rules scoped to paths, Security Events.

Configuration delivered: To protect against OWASP-class threats (SQL Injection, XSS, etc.) and add extra protection for /services/safes and /services/business-sales, we:

• Enabled Cloudflare WAF managed rules (including OWASP-aligned rulesets) for innovative-trailblazer.sxplab.com and all related lab hostnames as a global baseline, so that every request is evaluated against core application-layer protections.
• Added dedicated managed rules scoped only to the critical paths /services/safes and /services/business-sales, using stricter actions and sensitivity on these URLs to provide an extra shield for high-value flows. These rules evaluate traffic on top of the global OWASP baseline, focusing specifically on these two services.
• Ensured all enforcement is logged in Security Events so that potential zero-day attack activity on these endpoints is visible and traceable, even when triggered by novel payloads.

Outcome & rationale: The application benefits from broad, OWASP-aligned protection across all hostnames, while /services/safes and /services/business-sales receive an additional layer of managed-rule enforcement. This combination provides stronger zero-day and high-value endpoint protection without over-constraining less critical parts of the site.

Validation performed: Sent controlled test requests with benign but rule-matching payloads at /services/safes and /services/business-sales and verified that the requests were blocked or challenged by the dedicated managed rules, and that the associated events appeared with the expected rule IDs in Security Events.

Evidence:

• Global WAF managed ruleset configuration showing OWASP-aligned protections enabled for the lab zone (see Figure 6a).
• Additional managed rules scoped specifically to /services/safes and /services/business-sales, with stricter actions/sensitivity on these paths (see Figure 6b).
• Security Events entries demonstrating blocked requests on /services/safes and /services/business-sales triggered by the scoped managed rules (see Figure 6c).

Figure 6a: Global WAF managed rules baseline (OWASP).

Figure 6b: Dedicated managed rules on critical services paths.

Figure 6c: Security Events – blocked requests from managed rules on critical endpoints.

TL;DR: Restricted /contact so that traffic from Singapore is allowed normally, while all other countries are gated behind a Managed Challenge.

Cloudflare features used: WAF / Rulesets, Geo-IP conditions (ip.src.country), Managed Challenge.

Configuration delivered: To restrict access to /contact to IPs from Singapore while challenging all other traffic, we:

• Created a WAF / ruleset rule with the following match expression:
  (starts_with(http.request.uri.path, "/contact")
  and ip.src.country ne "SG")
  This targets requests to the /contact path where the source country is anything other than Singapore.
• Set the rule action to Managed Challenge so that:
  • Requests from ip.src.country = "SG" are not matched by this rule and therefore proceed without challenge.
  • Requests from all non-SG countries match the rule and receive an interactive Managed Challenge (JavaScript challenge) before access.
• Ensured the rule’s position in the WAF / ruleset order is ahead of more generic controls, so the /contact-specific geo policy is applied consistently.

Outcome & rationale: The /contact endpoint is effectively prioritised for Singapore-based users while still allowing the business to receive legitimate traffic from that region without friction. Access from all other countries is not blocked outright but is challenged, adding friction for unwanted traffic and scripted abuse originating outside Singapore.

Validation performed: Using country simulation / geo-testing and test traffic from different regions, we verified that:

• Requests to /contact from IPs geolocated to Singapore passed without any Managed Challenge.
• Requests to /contact from non-SG locations matched the rule, triggered a Managed Challenge, and produced corresponding entries in Security Events with the expected rule name and action.

Evidence: Geo-based WAF rule for /contact using ip.src.country ne "SG" and Managed Challenge, plus Security Events entries showing challenges for non-SG traffic (see Figure 7).

Figure 7: Geo-restricted and challenged access to /contact.

TL;DR: Enabled JavaScript detections in Security settings and added a WAF rule that challenges requests to /services/checkboxes when JS detection does not pass, filtering out non-JS bots while keeping the flow usable for humans.

Cloudflare features used: Bot Management JS detections, WAF rulesets, Security Events.

Configuration delivered: To identify and mitigate bot traffic targeting the /services/checkboxes area, we:

• Enabled JavaScript detections in the Bot / Security settings so Cloudflare can distinguish between real browsers executing JS and headless / non-JS clients.
• Created a dedicated WAF rule scoped to requests where the path starts with /services/checkboxes and JS detection has not passed, using the expression:
  (starts_with(http.request.uri.path, "/services/checkboxes") and not cf.bot_management.js_detection.passed)
  This rule applies a challenge or block action to clients that fail JS detection on this path.
• Kept the rest of the site on the broader bot posture, tuning exclusions only where needed, so that the strict JS-based enforcement is focused on the /services/checkboxes flow.

Outcome & rationale: Requests to /services/checkboxes that do not successfully complete JS detection are intercepted by the WAF rule and challenged or blocked. This reduces scripted and headless abuse on this specific flow while real browsers (where cf.bot_management.js_detection.passed is true) proceed normally.

Validation performed: Simulated traffic without JS execution (for example, simple curl/headless clients) against /services/checkboxes and confirmed that:

• The WAF rule matching starts_with(http.request.uri.path, "/services/checkboxes") and not cf.bot_management.js_detection.passed was triggered.
• Requests were challenged or blocked as configured, and corresponding events appeared in Security Events with the expected rule ID and action.

Evidence: Bot / Security configuration showing JS detections enabled and the WAF rule expression for /services/checkboxes, plus curl-based validation showing blocked/challenged responses when JS detection did not pass (see Figures 8a and 8b).

Figure 8a: JS detections and WAF rule configuration for /services/checkboxes.

Figure 8b: curl validation – JS-detection-based enforcement on /services/checkboxes.

TL;DR: Enabled leaked-credentials detection and implemented three ATO-focused controls on /contact: a WAF rule that challenges leaked credentials, a second WAF rule that combines Cloudflare ATO detection IDs with leaked-credential similarity, and a rate-limiting rule that throttles repeated failed “login-like” attempts. In addition, we deployed a Cloudflare Worker that logs leaked-credential events, enriches them with Bot Management signals, and sends throttled alerts to Discord.

Cloudflare features used: Leaked credentials / ATO signal, Bot Management detection IDs, WAF custom rules, Advanced Rate Limiting, Cloudflare Workers + KV, Security Events.

Configuration delivered: To detect and mitigate account takeover activity on the /contact endpoint, we:

• Turned on leaked credentials detection so Cloudflare can signal when submitted username/password pairs are known to be compromised.
• Created a WAF custom rule named ATO – leaked credentials on /contact that challenges requests sending leaked credentials to this endpoint. The rule expression is:
  (starts_with(http.request.uri.path, "/contact")
  and cf.waf.credential_check.username_and_password_leaked)
  This directly targets credential-stuffing attempts that reuse breached username/password pairs.
• Added a second WAF rule named ATO detection IDs + leaked credential signal that combines Cloudflare ATO detection IDs with a similarity-based credential signal. The rule expression is:
  (starts_with(http.request.uri.path, "/contact")
  and any(cf.bot_management.detection_ids[*] in {201326593})
  and cf.waf.credential_check.username_password_similar)
  Here, 201326593 is Cloudflare’s documented example detection ID that “observes all login traffic to the zone”. Combined with cf.waf.credential_check.username_password_similar, this rule focuses on suspicious login-like traffic that looks similar to known breached credentials, even if not an exact match.
• Configured a dedicated Rate Limiting rule named ATO – failed attempts throttle on /contact, treating /contact as a login-like POST flow:
  • Matching filter:
    starts_with(http.request.uri.path, "/contact")
and http.request.method eq "POST"
  • Counting expression (only failures):
    starts_with(http.request.uri.path, "/contact")
and http.request.method eq "POST"
and (http.response.code in {400 401 403 409 422})
    This uses http.response.code inside the counting expression so only failed “login-like” responses increment the rate-limit counter.
  • When the defined threshold is exceeded within the window, subsequent requests are challenged or blocked, throttling bursts of failed attempts.
• Deployed a Cloudflare Worker in the high-level logging path named log-leaked-creds-and-bot-info (throttled), with the following behaviour:
  • Reads Cloudflare’s leaked-credential signal (cf.exposedCredentialCheck / exposed-credential-check header) and, if present, enriches the event with Bot Management fields: verdict, score, and detection IDs.
  • Extracts the login-username field from the POST body (e.g. WordPress-style log field) and identifies the client IP and user agent.
  • Stores a per-IP history of the last 10 leaked-credential attempts in a KV namespace LOGIN_LOG (keyed by client IP).
  • Implements a per-IP throttling window using KV key ALERT_TS:<clientIP> so that each IP can trigger at most one Discord alert every 5 minutes.
  • Sends a structured Discord embed (via DISCORD_WEBHOOK_URL) with: leaked-credential flag description, Bot verdict/score/IDs, username, client IP, URL, user agent, and a “Recent Attempts for this IP” section built from KV history.
  • Always forwards the request to the origin after logging/alerting, so security telemetry does not interfere with the application flow.
• Ensured all three ATO rules and the Worker-based alerts log clearly into Security Events / Rate Limiting analytics and Discord, providing a consolidated view of leaked-credential and ATO activity.

Outcome & rationale: /contact is now protected by: (1) direct leaked-credential enforcement, (2) an ATO heuristic rule that combines Cloudflare’s login-traffic detection ID 201326593 with credential similarity, (3) a failure-aware rate limit that reacts to spikes in 4xx responses, and (4) a high-level Worker that logs and correlates leaked-credential events with Bot Management telemetry, keeps per-IP history in KV, and sends throttled alerts to Discord. Together, these controls significantly reduce the likelihood of successful credential stuffing or account takeover on this endpoint while providing rich, noise-controlled alerting for security operations.

Validation performed:

• Sent test requests with leaked credentials to /contact and confirmed that the ATO – leaked credentials on /contact rule triggered and enforced the configured action.
• Simulated login-like traffic matching detection ID 201326593 with username_password_similar and verified that the ATO detection IDs + leaked credential signal rule was evaluated and logged.
• Generated bursts of failing POST requests to /contact (with 4xx responses) and observed the ATO – failed attempts throttle on /contact rule activating and throttling further attempts.
• Triggered leaked-credential scenarios and checked that the Worker: updated KV history in LOGIN_LOG, respected the 5-minute per-IP throttle, and produced Discord alerts containing Bot Management and per-IP history fields.
• Confirmed that all rules and the Worker-produced alerts appear clearly in Security Events, Rate Limiting analytics, and Discord, including rule names and actions taken.

Evidence: Configuration and proof for all ATO controls on /contact plus runtime evidence:

• WAF rule ATO – leaked credentials on /contact using cf.waf.credential_check.username_and_password_leaked.
• WAF rule ATO detection IDs + leaked credential signal using detection ID 201326593 and cf.waf.credential_check.username_password_similar.
• Rate Limiting rule ATO – failed attempts throttle on /contact using http.response.code in the counting expression for failed attempts.
• Cloudflare Worker log-leaked-creds-and-bot-info (throttled) configuration, showing KV bindings (LOGIN_LOG) and DISCORD_WEBHOOK_URL secret.
• Example Discord alert generated by the Worker, including leaked-credential flag, Bot verdict/score/IDs, username, client IP, URL, user agent, and recent attempts list.
• Security Events / rate-limiting analytics showing the ATO rules triggering on test traffic to /contact.

Figure 9a: WAF leaked-credentials rule for /contact.

Figure 9b: Advanced ATO rule using detection IDs and credential similarity.

Figure 9c: Rate Limiting – failed attempts throttle on /contact.

Figure 9d: Runtime evidence of ATO rules on /contact.

Figure 9e: Worker configuration for leaked-credential logging and Discord alerts.

Figure 9f: Discord alert generated by the ATO Worker.

TL;DR: Required every API request to include X-Security-Token, blocking calls that omit it before they reach the origin.

Cloudflare features used: WAF / Rulesets, header presence checks, Security Events.

Configuration delivered: To ensure that all traffic to the API hostname includes the custom header X-Security-Token, we:

• Scoped a WAF / ruleset rule to requests where the hostname is api.innovative-trailblazer.sxplab.com.
• Implemented the rule expression:
  (http.host eq "api.innovative-trailblazer.sxplab.com" and not len(http.request.headers["x-security-token"]) > 0)
  This condition matches requests to the API host where the X-Security-Token header is missing or empty, and the rule action is set to Block.
• Left allowed logic for requests that include a non-empty X-Security-Token, so the origin can enforce the token semantics while Cloudflare enforces structural presence at the edge.

Outcome & rationale: All calls to api.innovative-trailblazer.sxplab.com must carry the required security header, providing a simple but effective way to prevent unauthenticated or misconfigured clients from reaching the API origin.

Validation performed: Sent test requests to the API host both with and without the X-Security-Token header:

• Requests without X-Security-Token (or with an empty value) matched the rule expression and were blocked at Cloudflare, with corresponding entries in Security Events.
• Requests including a non-empty X-Security-Token were allowed through to the origin, confirming that enforcement is strictly tied to the header’s presence.

Evidence: Header-enforcement rule configuration and example blocked/allowed requests based on the presence of X-Security-Token (see Figure 10a and Figure 10b).

Figure 10a: X-Security-Token header enforcement rule on the API hostname.

Figure 10b: Evidence of blocked vs allowed API requests based on X-Security-Token.

TL;DR: Implemented a Single Redirect that sends requests for /help on the main site to the dedicated support hostname with a permanent redirect.

Cloudflare features used: Redirect Rules (Single Redirect), HTTP 301 responses.

Configuration delivered: To ensure that requests to /help are served from the dedicated support hostname, we:

• Created a Single Redirect rule on the zone innovative-trailblazer.sxplab.com with the matching expression:
  (starts_with(http.request.uri.path, "/help"))
• Configured the redirect target as the static URL https://support.innovative-trailblazer.sxplab.com/ with HTTP status 301 – Permanent Redirect.
• Kept the redirect scoped to the main hostname so that support traffic lands on support.innovative-trailblazer.sxplab.com and remains there.

Outcome & rationale: Users who navigate to /help on the main site are seamlessly redirected to the dedicated support subdomain, keeping the support experience centralised while preserving a simple, memorable entry point on the primary site.

Validation performed: Used curl -I https://innovative-trailblazer.sxplab.com/help and confirmed that the response returned an HTTP 301 with a Location header pointing to https://support.innovative-trailblazer.sxplab.com/. Verified that the browser follows the same redirect path.

Evidence: Single Redirect rule definition for /help and curl -I output showing the 301 redirect to the support hostname (see Figure 11a and Figure 11b).

Figure 11a: Single Redirect rule for /help → support.innovative-trailblazer.sxplab.com/.

Figure 11b: curl validation of the 301 redirect from /help to the support hostname.

TL;DR: Configured /status to bypass cache and protected it with Cloudflare Access, so only trusted IPs, service tokens, or authenticated users can see internal health data.

Cloudflare features used: Cache Rules (Bypass cache), Cloudflare Access (ZTNA app), Access policies (Bypass / Service Auth / Allow).

Configuration delivered: For the /status endpoint specifically, we implemented:

• Cache bypass for /status
  Created a Cache Rule that matches exactly:
  http.request.uri.path eq "/status"
  (and, if needed, also http.request.uri.path eq "/status/" depending on origin behaviour).
  Action: Bypass cache.
  Result: /status is never cached at Cloudflare edge.
• Cloudflare Access protection for /status
  Created a Cloudflare Access application with:
  • Host: innovative-trailblazer.sxplab.com
  • Path: /status (exact path)
  Implemented the following Access policies (top to bottom):
  • Bypass for trusted IP ranges (VPN / office allowlist) → trusted internal sources reach /status without a login prompt.
  • Service Auth for monitoring / automation using a Service Token → requests are allowed when they include:
    CF-Access-Client-Id: …
CF-Access-Client-Secret: …
  • Allow for approved users / groups → everyone else is redirected to the Cloudflare Access login page and must authenticate before reaching /status.

Outcome & rationale: The internal status endpoint is never cached (CF-Cache-Status does not return HIT) and is only reachable via Cloudflare Access controls. Trusted IPs can see it transparently, monitoring systems use a service token, and all other users must authenticate with their identity provider. This gives us a clean “internal URL handling” pattern, scoped strictly to /status, without exposing health data publicly.

Validation performed:

• Requested /status and confirmed that cache headers show bypass (no edge caching).
• Browsed to https://innovative-trailblazer.sxplab.com/status from a non-allowlisted client with no service token and observed a redirect to the Cloudflare Access login prompt.
• Sent curl requests including valid CF-Access-Client-Id and CF-Access-Client-Secret headers and confirmed that the request was allowed and the origin’s /status response was returned.
• Verified that requests from allowlisted IP ranges were allowed straight through without an authentication challenge.

Evidence:

• Cache Rule configuration showing Bypass cache for http.request.uri.path eq "/status" (see Figure 12a).
• Cloudflare Access application and policies scoped to innovative-trailblazer.sxplab.com, path /status (see Figure 12b).
• Cloudflare Access authentication page when accessing /status without being allowlisted or providing a service token (see Figure 12c).
• curl output demonstrating that including valid CF-Access-Client-Id and CF-Access-Client-Secret headers successfully returns the /status response (see Figure 12d).

Figure 12a: Cache Rule – Bypass cache for /status.

Figure 12b: Cloudflare Access application and policies for /status.

Figure 12c: Access authentication page when reaching /status without authorization.

Figure 12d: curl validation of /status using an Access service token.

TL;DR: Configured Cloudflare Load Balancing with Proximity steering between Singapore (origin1) and Frankfurt (origin2), using 10-minute health checks and automatic failover. Implemented a custom load balancer rule to pin the compliance path /.git to Singapore only.

Cloudflare features used: Load Balancing (pools, monitors, load balancer for innovative-trailblazer.sxplab.com), Proximity steering, Custom Load Balancing Rules (path-based override), Failover across pools, and health monitor TLS option “Don’t verify SSL/TLS certificates (insecure)” to accommodate non-CA-signed origin certificates.

Configuration delivered:

• 1) Pools
  Two pools were created:
  • Singapore pool
    Endpoint: origin1.innovative-trailblazer.sxplab.com (52.191.5.18)
    Proximity steering: enabled.
  • Frankfurt pool
    Endpoint: origin2.innovative-trailblazer.sxplab.com (52.170.37.97)
    Proximity steering: enabled.
• 2) Health checks (10-minute interval)
  A single HTTPS monitor was configured and attached to both pools:
  • Monitor path: GET /health
  • Interval: 600 seconds (10 minutes)
  • Health monitor TLS option set to “Don’t verify SSL/TLS certificates (insecure)” because the origin certificates are self-signed / not CA-signed.
  After enabling this setting, both pool health checks turned Healthy (green).
• 3) Load balancer settings
  Load Balancer for innovative-trailblazer.sxplab.com:
  • Hostname: innovative-trailblazer.sxplab.com
  • Traffic steering: Proximity steering
  • Failover across pools: ON
  • Session affinity: OFF
  • Fallback pool: Singapore
• 4) Compliance requirement – pin /.git to Singapore only
  Implemented a custom Load Balancing rule to route all /.git requests to Singapore:
  • Rule name: Compliance requirement
  • Match expression: http.request.uri.path eq "/.git"
  • Action: Override → Pools → Singapore (only)
  This guarantees all requests to /.git are routed to the Singapore data center regardless of user location.

Outcome & rationale:

• Users are routed to the nearest data center (Singapore vs Frankfurt) using Proximity steering, improving latency and regional user experience.
• If a region becomes unavailable, Failover across pools supports automatic continuity by shifting traffic to a healthy pool.
• Regulatory / compliance requirements are satisfied by forcing /.git to Singapore only via a load balancer custom rule.
• Health monitoring is operational at the required 10-minute interval, and pools correctly show as Healthy after adjusting monitor TLS verification to accommodate the origin certificates.

Validation performed:

• Observed that health checks were initially failing due to TLS certificate validation on the origin endpoints.
• After enabling “Don’t verify SSL/TLS certificates (insecure)” on the monitor, confirmed that both pools transitioned to Healthy (green).

Evidence:

• Load balancer overview showing Proximity steering, Failover across pools ON, Session affinity OFF, Fallback pool set to Singapore, and both Singapore/Frankfurt pools with their endpoints and HTTPS monitor attached (see Figure 13a).
• Custom Load Balancing rule matching http.request.uri.path eq "/.git" and overriding traffic to the Singapore pool (see Figure 13b).

Figure 13a: Regional Load Balancer with Singapore/Frankfurt pools and 10-minute health checks.

Figure 13b: Custom load balancer rule pinning /.git to the Singapore pool.

TL;DR: Requests to /services were being blocked by the Cloudflare OWASP Core Ruleset due to specific OWASP CRS rule IDs contributing to the anomaly score. Per the lab scenario this traffic was treated as a false positive (hypothetical legitimate traffic), so we implemented a narrowly scoped OWASP exclusion on /services that skips only the offending rule IDs while keeping the rest of OWASP CRS protection enabled. In parallel, we deployed a scheduled “WAF watcher” Worker that monitors the managed ruleset and per-zone overrides for configuration drift, storing snapshots in KV and alerting via Discord / PagerDuty, and enabled Cloudflare Advanced Security Notifications to raise additional alerts on spikes in security events.

Cloudflare features used: Cloudflare OWASP Core Ruleset, managed rule exclusions, path-based match conditions, Security Events, Advanced Security Notifications, Cloudflare Rulesets API, Workers, Workers KV, Discord webhooks, PagerDuty Events API.

Configuration delivered:

• 1) Steps taken to identify the source of OWASP blocks on /services
  • Triaged the block in Security Events: In Security → Events, we located a representative blocked request and confirmed:
    • Service: Managed rules
    • Action: Block
    • Ruleset: Cloudflare OWASP Core Ruleset
    • OWASP score: 61
    • Host: innovative-trailblazer.sxplab.com
    • Path: /services
    • Ray ID: 9c9b50953cb643a2
    • Method / query string: GET /services?q=%27%20UNION%20SELECT%201,2,3%20FROM%20information_schema.tables--
  • Identified which OWASP CRS rules drove the score: From the event details / exported JSON, we confirmed the following OWASP CRS rule IDs were triggered and contributed to the anomaly score:
    920273, 942100, 942110, 942140, 942190, 942200, 942260, 942270, 942330, 942360, 942361, 942432, 942480
  • Lab classification: In line with the lab assumptions, this pattern was treated as a false positive for the exercise (hypothetical legitimate traffic that must be allowed), not a real production attack.
• 2) Fine-tuned, minimal-scope OWASP exclusion for /services
  • Created an OWASP rule exclusion scoped to the exact path:
    Match condition:
    http.request.uri.path eq "/services"
  • Skipped only the specific rule IDs observed in Security Events:
    Instead of excluding the entire OWASP ruleset or a whole ruleset group, the exclusion is restricted to the exact rule IDs that caused the false positive on /services:
    920273, 942100, 942110, 942140, 942190, 942200, 942260, 942270, 942330, 942360, 942361, 942432, 942480
  • Kept OWASP CRS enabled for everything else: All other OWASP CRS protections remain active globally and also still apply to /services; only the listed rule IDs are skipped for that specific URI. This preserves strong coverage while removing the false-positive behaviour for this path.
  • Re-validated: Re-ran the same request pattern and confirmed that:
    • /services is no longer blocked by OWASP CRS after the targeted exclusion is applied.
    • Other attack-style test payloads still trigger OWASP rules and are blocked or challenged as expected.
• 3) Continuous monitoring – WAF watcher Worker and Advanced Security Notifications
  • Deployed a scheduled Worker that:
    • Uses CF_API_TOKEN, MANAGED_RULESET_ID, and ZONE_IDS to call the Rulesets API and fetch the full managed ruleset via /zones/{zoneId}/rulesets/{managedId} for a reference zone.
    • Builds a snapshot with the managed ruleset version, per-rule action/enable state and version, and per-zone overrides (configured managed version, ruleset-level action, and per-rule overrides).
    • Stores that snapshot in a KV namespace RULESET_KV under managed-ruleset-zones:<MANAGED_RULESET_ID>.
    • On each run, loads the previous snapshot from KV, computes a granular diff (managed version changes, rule additions/removals, action/enable/version changes, per-zone override drift), and only sends alerts when differences are detected.
  • Alerts to Discord and PagerDuty: When changes are detected, the Worker:
    • Sends a PagerDuty event (if PD_ROUTING_KEY is configured) summarising the number and type of WAF changes.
    • Sends a Discord message (if DISCORD_WEBHOOK_URL is set) with a diff-style list of changes (truncated to respect the 2,000-character limit).
  • Uses ZONE_LABELS_JSON to render human-readable zone labels (for example, “Prod – APAC”) instead of raw zone IDs in alert text, simplifying operational review.
  • Enabled Cloudflare Advanced Security Notifications: Configured Advanced Security Notifications on the zone so that spikes in WAF, Bot Management, or Rate Limiting events automatically generate control-plane alerts (email / dashboard notifications), complementing the custom Worker-based monitoring.

Outcome & rationale: The OWASP CRS configuration now allows the lab-classified “legitimate” traffic to /services by excluding only the exact rule IDs that caused the false positive on that path, while all other OWASP protections remain in place. At the same time, the managed ruleset and its per-zone overrides are continuously monitored by the WAF watcher Worker; any change to managed rule versions, actions, or overrides is captured in KV and surfaced via Discord / PagerDuty. Cloudflare Advanced Security Notifications provide an additional safety net by alerting on raised security event volumes. This gives AcmeCorp both a stable, tuned WAF posture for /services and ongoing governance against configuration drift and emerging spikes in security events.

Validation performed:

• Verified that the original /services request (Ray ID 9c9b50953cb643a2) was blocked by OWASP CRS with an anomaly score of 61 and the listed rule IDs before the exclusion was configured.
• After applying the path-scoped OWASP exclusion for http.request.uri.path eq "/services" with the specified rule IDs, re-ran the same pattern and confirmed that it no longer triggered a block while other attack-style tests still did.
• Executed the WAF watcher Worker manually (POST /scan) to create an initial baseline in RULESET_KV, then introduced a small, controlled change to a managed rule override and confirmed that the next run reported the change and generated a Discord / PagerDuty notification.
• Reverted the test override and confirmed that subsequent scans reported “no changes detected”.
• Confirmed that Advanced Security Notifications are enabled and scoped to relevant security event types so that spikes in WAF / Rate Limiting / Bot events would generate additional alerts to operators.

Evidence:

• Security Events entry showing /services blocked by the Cloudflare OWASP Core Ruleset before tuning, including the anomaly score and triggered rule IDs (see Figure 14a).
• Managed ruleset exclusion configuration scoped to http.request.uri.path eq "/services" with the specific OWASP CRS rule IDs 920273, 942100, 942110, 942140, 942190, 942200, 942260, 942270, 942330, 942360, 942361, 942432, 942480 excluded for that path (see Figure 14b).
• Security Events view after applying the exclusion, showing the same /services request pattern passing without an OWASP block while other malicious payloads are still mitigated (see Figure 14c).
• Cloudflare dashboard view of the WAF watcher Worker configuration, including the RULESET_KV binding and key environment variables such as ZONE_IDS, MANAGED_RULESET_ID, and ZONE_LABELS_JSON (see Figure 14d).
• Example Discord (or PagerDuty) alert summarising detected managed ruleset and override changes across the monitored zones (see Figure 14e).

Figure 14a: Original OWASP CRS block on /services before tuning.

Figure 14b: Path-scoped OWASP rule exclusion for /services.

Figure 14c: /services traffic passing after OWASP tuning.

Figure 14d: WAF watcher Worker and KV configuration.

Figure 14e: Alert generated by the WAF watcher Worker.

TL;DR: Enabled Page Shield on innovative-trailblazer.sxplab.com and focused monitoring on the /contact flow (including /contact/received). Deployed a Log-mode Page Shield policy that treats sxplab.com as trusted and generates policy violations for any scripts from other origins. Configured Page Shield Notifications to alert the security team on new resources, new domains, and JavaScript code changes during the monitoring rollout.

Cloudflare features used (implemented): Page Shield (script monitoring & inventory, policy violations, client-side supply chain visibility); Page Shield Notifications (new resources, new domains, code change detection alerts).

Configuration delivered:

• 1) Monitor & catalog third-party JavaScript on /contact and /contact/received
  • Enabled Page Shield for the zone so scripts loaded by real visitors are recorded.
  • In Client-side resources → Scripts, filtered by Seen on page for:
    • /contact
    • /contact/received
  • Exported the scripts inventory as a baseline for what is currently running on the contact flow.
• 2) Policy: allow sxplab.com, alert on everything else (monitoring first)
  • Created a Page Shield policy with:
    • Action: log (monitoring mode – no blocking during rollout).
    • Expression (scope):
      (http.host eq "innovative-trailblazer.sxplab.com" and starts_with(http.request.uri.path, "/contact"))
    • Policy value (script sources):
      script-src 'self' https://*.sxplab.com;
  • Resulting behaviour:
    • Scripts from sxplab.com (including first-party assets and internal CDNs) are treated as trusted for the monitored contact flow.
    • Scripts from any other origin generate Page Shield policy violations, providing observability without impacting users while the policy is in Log mode.
• 3) Notifications: alert the security team on new/unknown/changed scripts
  • Configured Page Shield Notifications to send alerts to the security team’s email/webhook destination for:
    • Page Shield New Resources Alert – when a new resource is first seen.
    • Page Shield New Domain Alert – when a new script domain appears.
    • Page Shield New Code Change Detection Alert – when existing JavaScript code changes, indicating a potential supply-chain modification.
  • (Optional, for later hardening) Additional alerts such as New Malicious Script/Domain/URL can be enabled once the baseline has stabilised.

Outcome & rationale: AcmeCorp gains visibility into all JavaScript loaded during the /contact journey (including /contact/received) and a clear trust boundary: sxplab.com is allowed, everything else is highlighted via policy violations. The security team receives actionable alerts when:

• New third-party resources or domains are introduced on the contact flow.
• Existing JavaScript code changes, indicating a possible supply-chain change.

Policies remain in Log mode during this lab, avoiding user-facing breakage while proving that enforcement (Allow/Block) would be viable in a later phase.

Validation performed:

• Visited /contact and /contact/received and confirmed that Page Shield Scripts inventory shows resources with Seen on page matching these URLs.
• Verified that the Page Shield policy is in Log mode and that scripts loaded from domains outside *.sxplab.com appear as policy violations without impacting end users.
• Confirmed that Page Shield Notifications are active for New Resources, New Domain, and Code Change Detection, and that alerts are delivered to the configured email/webhook destination.

Evidence:

• Figure 15a: Page Shield enabled for the zone (Security → Page Shield overview).
• Figure 15b: Client-side resources → Scripts filtered by Seen on page = /contact and /contact/received.
• Figure 15c: Page Shield policy in Log mode showing: starts_with(http.request.uri.path, "/contact") and script-src 'self' https://*.sxplab.com;.
• Figure 15d: Policy violations view where non-sxplab.com scripts appear as violations.
• Figure 15e: Page Shield Notifications configuration showing: New Resources, New Domain, and New Code Change Detection alerts with the security team’s destination.

Figure 15a: Page Shield enabled for the zone.

Figure 15b: Scripts inventory filtered for /contact and /contact/received.

Figure 15c: Log-mode Page Shield policy for the contact flow.

Figure 15d: Policy violations for non-sxplab.com scripts.

Figure 15e: Page Shield notification configuration for the security team.

Advanced improvement (recommended, not implemented in this lab):

• Enable Logpush for page_shield_events to stream Page Shield events to external storage/SIEM for long-term investigations and compliance reporting.
• After the baseline stabilises, switch the policy from Log to Enforce/Allow and tighten the allowlist from *.sxplab.com down to specific hostnames or exact script URLs.

TL;DR: Produced a customer handoff pack as custom HTML reports that summarize the current security posture, performance configuration, and enabled alerting for innovative-trailblazer.sxplab.com, including exportable tables (CSV/Excel) for investigation and audit workflows.

Cloudflare features used: Security analytics (WAF posture), bot/client IP attributes, Notifications, Health Checks, and Performance Analytics (traffic, cache hit, TTFB).

Configuration delivered:

• Security visibility (threats & bot attributes)
  • Captured a Top Client IPs – Attributes view showing request volume, ASN, bot classification, detection tags, and error concentration (4xx/5xx) with built-in CSV/Excel export for investigation handoff.
  • Captured the zone’s WAF posture summary (Managed WAF enabled, OWASP enabled, enforcement mode) and the prioritized remediation list visible in the same report view.
• Performance visibility (settings + KPIs)
  • Captured a consolidated Speed & Performance Settings view listing feature-level state (current vs recommended) to document exactly what was enabled during the lab.
  • Captured Performance Analytics summary metrics (requests/bytes, cache hit %, and median TTFB p50) for the lab range.
• Operational readiness (alerts & health)
  • Captured the Notifications (Enabled) list, including Page Shield script-monitoring alerts (New Resources, New Code Change Detection, and malicious script/domain/URL alerts), plus platform-level alerts (DDoS, origin error rate, incidents, and health check status).
  • Included the Health Checks status view to show that monitors are healthy at handoff time.

Outcome & rationale: AcmeCorp receives a practical handoff artifact that documents (1) what controls are enabled, (2) what the platform is observing (top client IPs and bot attributes), (3) what the security team will be alerted on, and (4) baseline performance indicators. This enables faster operations, troubleshooting, and audit readiness without relying on screenshots scattered across multiple dashboard pages.

Validation performed: Verified that the generated reports align with the live dashboard views for the same zone and time range, including: WAF posture shown as enabled/enforcing, notifications listed as enabled, health checks reporting healthy, and the performance analytics summary rendering correctly.

Evidence (selected pages from the HTML handoff report):

Advanced improvement (recommended, not implemented in this lab): For long-term audit retention beyond the dashboard UI, enable Logpush for relevant datasets (for example, security and Page Shield event streams) to an external storage/SIEM destination with appropriate write access.

Advanced handoff (separate audit pack): To avoid overwhelming this submission with raw exports, AcmeCorp will receive a separate full audit pack alongside the main document. This audit pack will include the complete Analytics, Performance, and Security reports as standalone HTML exports (and/or CSV/Excel where applicable), preserving the detailed drill-down views required for operations and audit review while keeping the primary handoff concise and reviewer-friendly.

TL;DR: This pack includes the SRA document itself, a structured figure set (Figures 1, 2A–16E), and a final checklist that maps each lab requirement to its implemented configuration and evidence. Together with the HTML handoff reports from Answer 16, it forms a customer-ready documentation bundle for innovative-trailblazer.sxplab.com.

Cloudflare features used: N/A – this answer covers documentation, validation, and handoff rather than additional product configuration.

Configuration delivered:

• A structured SRA document that:
  • Follows the Basic Setup → Sections 1–5 lab structure.
  • Provides a “Configuration delivered / Outcome & rationale / Validation performed / Evidence” pattern per answer.
  • Cross-references Figures 1, 2A–16E so readers can jump directly from the narrative to the visual proof in the appendix.
  rences Figures 1–17 so readers can jump directly from the narrative to the visual proof in the appendix.
• A consolidated figure set (Figures 1–17) sourced from the Cloudflare dashboard and HTML reports, including:
  • DNS, SSL/TLS, performance, cache, WAF, Bot/ATO, Access, Load Balancing, Page Shield, and analytics views.
  • Per-feature captions that explain what each figure demonstrates (for example, “Figure 4A: SSL/TLS overview showing Full (strict) mode”).
• Alignment with the HTML handoff reports produced in Answer 16, which provide:
  • Exportable tables (CSV/Excel) for client IP attributes, WAF posture, notifications, health checks, and performance analytics.
  • A consistent view between the HTML reports and the figures embedded in this SRA.
• A short set of assumptions and substitutions, including:
  • Where lab-tier limitations required using Workers/Rules in place of Enterprise-only features.
  • Which advanced recommendations are design-ready but not enabled in the lab (for example, Smart Shield with Tiered Cache, Cloudflare Images, R2 offload, originless Workers hosting).

Outcome & rationale:

AcmeCorp receives a clear, self-contained description of what was delivered, how it was validated, and where to look in the Cloudflare dashboard or HTML reports to review or extend the configuration. Each lab requirement is traceable from:

• Question → Answer text → Figures → (where applicable) HTML handoff report page.

Validation performed:

• Cross-checked each lab requirement against the corresponding answer, configuration, and figure(s) to ensure there is at least one concrete visual evidence point per control.
• Verified that the HTML reports generated in Answer 16 present the same posture (WAF, notifications, health checks, performance metrics) as the Cloudflare dashboard views captured in Figures 16A–16E.
• Confirmed that the final checklist below references the correct figure ranges for every control area.

Final checklist: