Cloudflare Application Services - Lab Guide (Legacy)

Unified Lab Guide & Technical Reference. Courseware Version 4.0 (AcmeCorp Edition), Legacy / Cloudflare-Managed Lab. Prepared for AcmeCorp IT Security & Infrastructure. Scenario: Edge Security Modernization.

Typographical Conventions

This guide uses the following conventions to distinguish between user input, system output, and explanatory notes.

How to Use This Lab Guide & The AcmeCorp Scenario

You are AcmeCorp's new Lead Application Security Engineer. Your mandate is to modernize the edge with Cloudflare Application Services, changing the origin as little as possible, and take AcmeCorp from exposed to defended. Over the next 18 labs you will prove how exposed the origin is, route and encrypt its traffic, make it fast and resilient, build a layered perimeter (WAF, bot management, rate limiting, API Shield, threat intelligence, and client-side protection), then seal the origin so the perimeter cannot be bypassed, and replay the opening attacks to prove nothing gets through.

Each lab solves one concrete part of that story. Reading the lab titles from top to bottom tells it end to end: exposed, onboarded, encrypted, fast, resilient, defended, sealed, and proven. Every lab opens with a "This chapter" box, highlighted in yellow, that states the part of the story you are about to solve.

In this managed lab, your Cloudflare account already contains one pre-onboarded Enterprise zone assigned to you (its name follows the pattern adjective-noun.sxplab.com, for example happy-balancer.sxplab.com). The zone is onboarded (Enterprise plan, Cloudflare nameservers assigned) but starts with no DNS records: you create them as the labs need them. In Lab 2 you onboard the three web hostnames the rest of the guide relies on: the apex (<student-domain>, the AcmeCorp website), ps.<student-domain> (the Page Shield demo page), and public-api.<student-domain> (the public orders API). You add a few more records in the labs that introduce them (ftp in Lab 2, payments.platform in Lab 3, and api in Lab 13). The apex and ps resolve to the shared web origin; public-api (and api) resolve to a separate orders API origin, as the table below shows.

Lab 1 - The Exposed Origin

1.1 Confirm the Origin Is Exposed

From the workstation, request the origin directly by IP and read the response headers:

curl -sI http://20.88.188.200/ | head -n 6

Now look at how the origin serves HTTPS:

echo | openssl s_client -connect 20.88.188.200:443 2>/dev/null | openssl x509 -noout -issuer -subject

1.2 Leak Sensitive Files from the Origin

Developers accidentally left a source-control artifact on the web root. Request it directly:

curl -s http://20.88.188.200/.git/secrets.txt

1.3 Scrape the Product Catalog

Simulate a competitor scraping AcmeCorp's catalog. Hammer a product category page and tally the responses:

for i in $(seq 1 50); do curl -s -o /dev/null -w "%{http_code}\n" http://20.88.188.200/services/luggages/; done | sort | uniq -c

1.4 Push a SQL Injection String Straight Through

The website has a contact form. Submit a classic SQL injection payload to its comment field and watch how the origin responds:

curl -s -o /dev/null -w "%{http_code}\n" "http://20.88.188.200/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20"

1.5 Probe the Locked Admin Panel

Finally, knock on the administrative panel and see how it responds:

curl -s -o /dev/null -w "%{http_code}\n" http://20.88.188.200/admin

1.6 Record the "Before" Scorecard

Write down what you just observed. This is the baseline you replay in Lab 15, after the full perimeter is in place, to prove each gap is closed.

Lab 1 Wrap-up

Lab 1 Troubleshooting

Lab 2 - DNS Onboarding & Proxy Control

2.1 Cloudflare as Authoritative DNS

From the workstation Terminal, confirm the nameservers are Cloudflare's:

dig +short NS <student-domain>

howard.ns.cloudflare.com.
mia.ns.cloudflare.com.

The onboarded zone starts with no DNS records. In the dashboard, open DNS > Records and create an A record for the apex (name @, which represents <student-domain>) pointing to the shared origin 20.88.188.200, with Proxy Status set to Proxied (orange cloud).

Still in DNS > Records, create the other two web hostnames the later labs rely on, each as an A record with Proxy Status Proxied (orange cloud):

• ps pointing to the shared web origin 20.88.188.200: the Page Shield demo host, used in Lab 14.
• public-api pointing to the orders API origin 4.157.169.241: the public orders API, used in Labs 10.4 and 13.

2.2 Controlling Traffic with Proxy Status

In Cloudflare DNS > Records, create a new A record named ftp pointing to 20.88.188.200, and set its Proxy Status to DNS only (grey cloud).

From the workstation, query that record and compare it to a proxied record:

dig +short ftp.<student-domain>
dig +short <student-domain>

2.3 Experience: A Grey Cloud Re-Exposes the Origin

Proxy status is not a cosmetic toggle. To feel what a mistake costs, temporarily break one of your web records and watch the origin IP come back into the open. In DNS > Records, edit the ps record and switch its Proxy Status from Proxied to DNS only (grey cloud), then Save.

From the workstation, resolve the hostname (query a public resolver so no local cache hides the change):

dig +short @1.1.1.1 ps.<student-domain>

Diagnose and fix. A grey cloud means Cloudflare only answers DNS for the name and does not proxy its traffic, so the record must publish the true origin address. The fix is to put the record back behind the proxy: edit ps again and set Proxy Status to Proxied (orange cloud), then Save.

dig +short @1.1.1.1 ps.<student-domain>

Lab 2 Wrap-up

Lab 2 Troubleshooting

Lab 3 - SSL/TLS & Encryption Standards

3.1 Universal SSL, Flexible Mode & Edge Encryption

Go to SSL/TLS > Edge Certificates and confirm the Universal SSL certificate is Active.

For immediate mitigation, go to SSL/TLS > Overview, open Configure encryption mode, select Flexible under Encryption mode, then click Save. (The manual modes appear as radio options beneath "Automatic SSL/TLS (recommended)".)

On the same Edge Certificates page, turn Always Use HTTPS On.

Still on Edge Certificates, set Minimum TLS Version to TLS 1.2.

Verify the redirect and the negotiated protocol from the workstation:

curl -sI http://<student-domain>/ | head -n 4
curl -sI https://<student-domain>/ | head -n 1

Flexible restored the browser padlock, but it quietly broke something. From the workstation, compare the website against the orders API, both proxied through Cloudflare since Lab 2:

curl -s -o /dev/null -w "website:    %{http_code}\n" https://<student-domain>/
curl -s -o /dev/null -w "orders API: %{http_code}\n" https://public-api.<student-domain>/v1/orders

3.2 Full (Strict) + Origin Certificate

Go to SSL/TLS > Origin Server and click Create Certificate.

Leave the defaults selected: Generate private key and CSR with Cloudflare, RSA (2048) key type, the pre-filled hostnames (*.<student-domain> and <student-domain>), and 15 years validity. Click Create.

Copy the generated Origin Certificate and Private Key, save each to a file (for example cert.pem and key.pem), then click OK.

Now encrypt the Cloudflare-to-origin hop. Go to SSL/TLS > Overview, open Configure encryption mode, select Full, and click Save.

Re-run the comparison from the workstation:

curl -s -o /dev/null -w "website:    %{http_code}\n" https://<student-domain>/
curl -s -o /dev/null -w "orders API: %{http_code}\n" https://public-api.<student-domain>/v1/orders

3.3 Advanced Certificates for Subdomains

First, in Cloudflare DNS > Records, create an A record named payments.platform pointing to 20.88.188.200 with Proxy Status set to Proxied (orange cloud).

Go to SSL/TLS > Edge Certificates and click Order an advanced certificate. In Certificate Hostnames, type payments.platform and select the autocompleted full hostname payments.platform.<student-domain>. The form pre-fills the apex (<student-domain>) and wildcard (*.<student-domain>); remove both with their Remove buttons so the certificate covers only the payments hostname.

Set Certificate Authority to Google Trust Services, leave Certificate validation method on TXT Validation, keep the default Certificate Validity Period, then click Save.

Wait for the certificate to activate, then confirm from the workstation that it has taken precedence over Universal SSL for that specific subdomain by inspecting the presented certificate:

echo | openssl s_client -connect payments.platform.<student-domain>:443 -servername payments.platform.<student-domain> 2>/dev/null | openssl x509 -noout -issuer -ext subjectAltName

Lab 3 Wrap-up

Lab 3 Troubleshooting

Lab 4 - Caching Foundations

curl -sSI https://<student-domain>/services/luggages/ | grep -iE "cf-cache-status|age|cache-control"

4.1 Establishing Caching Baselines

From the workstation, inspect the cache status of a product category page:

curl -sSI https://<student-domain>/services/luggages/ | grep -i cf-cache-status

4.2 Control caching with a Cache Rule

Go to Caching > Cache Rules and click Create rule. Name it "Cache luggages category". Under When incoming requests match, set Field = URI Path, Operator = equals, Value = /services/luggages/.

Under Then, set Cache eligibility to Eligible for cache. Then set Edge TTL to Ignore cache-control header and use this TTL, and enter 30 seconds. Click Deploy.

From the workstation, request the path twice and watch the status change:

curl -sSI https://<student-domain>/services/luggages/ | grep -i cf-cache-status
curl -sSI https://<student-domain>/services/luggages/ | grep -i cf-cache-status

4.3 Leverage cache-control directives

Go to Caching > Configuration and set Browser Cache TTL to Respect Existing Headers. On a newly onboarded zone this dropdown often defaults to a fixed time such as 4 hours, so change it if needed.

Disable the Cache Rule you created in 4.2 (toggle it off on Caching > Cache Rules).

Purge the path, then reload it a couple of times and inspect the headers:

curl -sSI https://<student-domain>/services/luggages/ | grep -iE "cf-cache-status|age|cache-control"

4.4 Troubleshooting a Cached 404

Diagnose a reported problem: a page that was briefly missing is now returning a stale 404 even after the origin was fixed. The fix is a targeted purge.

Go to Caching > Configuration, use Custom Purge, choose Purge by URL, and enter the affected URL (for example https://<student-domain>/services/luggages/). Then reload and confirm the fresh response is served.

Now make the negative-caching behavior explicit and controlled with a Status Code TTL. By default Cloudflare does not cache 404 responses, so a burst of requests to a missing URL (a broken link, or an attacker fuzzing paths) reaches the origin every time. Create a Cache Rule (Caching > Cache Rules > Create rule) that matches a path known to 404, for example the custom filter expression starts_with(http.request.uri.path, "/missing/"):

• Set Cache eligibility to Eligible for cache.
• Under Edge TTL, select a mode: choose Use cache-control header if present, bypass cache if not. The Edge TTL card requires a mode before it will deploy; this option leaves normal edge caching to the origin's headers while the Status Code TTL below governs the 404.
• Still under Edge TTL, in the Status code TTL subsection click Add status code setting.
• Set Scope to Single code, the Status code to 404, and the Duration to 10 seconds, then Deploy.

curl -sSI https://<student-domain>/missing/nope | grep -iE 'HTTP|cf-cache-status'
curl -sSI https://<student-domain>/missing/nope | grep -iE 'HTTP|cf-cache-status'

Lab 4 Wrap-up

Lab 4 Troubleshooting

Lab 5 - Advanced Caching

5.1 Cache an entire HTML page (Cache Everything)

The /services/safes/ category page is plain HTML that changes rarely, yet every hit currently goes to the origin (cf-cache-status: DYNAMIC). During a promotion, thousands of shoppers loading that page can overwhelm AcmeCorp. You will cache the HTML itself at the edge.

In the dashboard, go to Caching > Cache Rules and click Create rule, then choose Cache Rules from the dropdown. Configure:

• Rule name: Lab 5 - Cache Everything safes
• When incoming requests match: set the field to URI Path, operator equals, value /services/safes/.
• Then / Cache eligibility: select Eligible for cache (this is what caches the HTML, not just static file types).
• Leave Place at on its default (Last) and click Deploy.

From the Workstation Terminal, prime and confirm the cache. The first request is a MISS (fetched from origin and stored), the second is a HIT (served from the edge):

curl -sSI https://<student-domain>/services/safes/ | grep -i cf-cache-status
curl -sSI https://<student-domain>/services/safes/ | grep -i cf-cache-status

5.2 Make it safe for logins, then fix the ordering trap

Caching HTML is dangerous the moment users can log in: a cached personalized page could be handed to the wrong visitor. The fix is a second rule that bypasses cache whenever a session cookie is present, so anonymous shoppers get the fast cached page while logged-in users always reach the origin.

Create a second cache rule (Caching > Cache Rules > Create rule > Cache Rules):

• Rule name: Lab 5 - Bypass on session cookie
• When incoming requests match: click Edit expression and enter (http.cookie contains "session_id").
• Then / Cache eligibility: select Bypass cache.
• Here is the trap. A common instinct is "the bypass should be checked first, so put it on top." Set Place at to First (or, if you left it Last, use the rule's kebab menu > Move up so the Bypass rule sits above Cache Everything). Deploy.

Break it and watch. Send an anonymous request and a request that carries a session cookie:

curl -sSI https://<student-domain>/services/safes/ | grep -i cf-cache-status
curl -sSI -H "Cookie: session_id=abc123" https://<student-domain>/services/safes/ | grep -i cf-cache-status

Diagnose. Cache Rules are last matching rule wins: rules run top to bottom, and the last rule that sets a given behavior overrides earlier ones. Your cookied request matches both rules, but because Cache Everything sits below the Bypass rule, its "Eligible for cache" wins and cancels the bypass. Putting the bypass "first" is backwards.

Fix. In Caching > Cache Rules, use the Bypass rule's kebab menu > Move down (or edit it and set Place at > Last) so the order is Cache Everything, then Bypass. Deploy, then re-run the same two commands:

curl -sSI https://<student-domain>/services/safes/ | grep -i cf-cache-status
curl -sSI -H "Cookie: session_id=abc123" https://<student-domain>/services/safes/ | grep -i cf-cache-status

5.3 Collapse marketing URLs with a custom cache key

Marketing appends tracking tags (?v=aaa, ?utm_source=email) to links. By default each unique query string is a separate cache object, so every tagged variant misses the cache and hits the origin, wrecking the Cache Hit Ratio. You will cache the /services/luggages/ page with a custom cache key that ignores the query string, collapsing every variant into one object.

Create a cache rule (Caching > Cache Rules > Create rule > Cache Rules):

• Rule name: Lab 5 - Custom cache key luggages
• When incoming requests match: URI Path equals /services/luggages/.
• Then / Cache eligibility: Eligible for cache.
• Expand Cache key and enable Ignore query string.
• Place this rule above the Bypass rule (so Bypass stays last). Deploy.

curl -sSI "https://<student-domain>/services/luggages/?v=aaa" | grep -i cf-cache-status
curl -sSI "https://<student-domain>/services/luggages/?v=bbb" | grep -i cf-cache-status

5.4 Shield the origin with Tiered Cache

Even with HTML cached, every one of Cloudflare's global data centers can independently miss and reach back to the single AcmeCorp origin on a cold cache. Tiered Cache arranges data centers into lower and upper tiers so lower-tier PoPs ask an upper-tier PoP before ever touching the origin.

Go to Caching > Tiered Cache, select Smart Tiered Cache (Recommended), and click Apply.

Lab 5 Wrap-up

Lab 5 Troubleshooting

Lab 6 - Traffic Management & Rules Engine

6.1 Geo-Redirects (Portugal Localization)

Create a Redirect Rule so visitors from Portugal are sent to the localized landing page. Go to Rules > Overview, and in the Redirect Rules section click Create rule.

• Rule name: Lab 6.1 - Portugal localization
• When incoming requests match: set Field = Country, Operator = equals, Value = Portugal (the expression reads ip.src.country eq "PT").
• Then: under URL redirect choose Dynamic, set the Expression to concat("https://", http.host, "/pt"), Status code 302, and enable Preserve query string. Click Deploy.

curl -s -o /dev/null -w "%{http_code}\n" https://<student-domain>/

6.2 Campaign Redirects

Marketing is running a campaign whose short link (/promo) must bounce visitors to AcmeCorp's LinkedIn page. Create a second Redirect Rule that matches the campaign path and sends it to an external URL.

• Rule name: Lab 6.2 - Campaign redirect
• When incoming requests match: Field = URI Path, Operator = equals, Value = /promo.
• Then: URL redirect > Static, URL = your LinkedIn profile URL (for example https://www.linkedin.com/company/cloudflare), Status code 301. Click Deploy.

curl -sSI https://<student-domain>/promo | grep -iE 'HTTP|location'

6.3 Response Header Transform

First, observe a security win Cloudflare gives you for free. The origin advertises its exact software in the Server response header, which attackers use to fingerprint the backend. Inspect the header on your proxied site:

curl -sSI https://<student-domain>/ | grep -i "^server:"

Now go to Rules > Overview, click Create rule and choose Response Header Transform Rule. Name it "Add X-Frame-Options". Apply it to All incoming requests, choose Set static, header name X-Frame-Options, value SAMEORIGIN, then Deploy.

curl -sSI https://<student-domain>/ | grep -iE "^server:|^x-frame-options:"

6.4 Managed Transforms (Security Headers)

You just added one header by hand. Cloudflare can also apply a curated set of best-practice header changes with a single click, using Managed Transforms. Go to Rules > Settings > Managed Transforms (or, from Rules > Overview, click Go to Managed Transforms). Under HTTP response headers, enable Remove "X-Powered-By" headers and Add security headers.

curl -sSI https://<student-domain>/ | grep -iE "x-content-type-options|x-frame-options|x-xss-protection|referrer-policy|x-powered-by"

6.5 URL Rewrites

AcmeCorp discontinued the "arrows" product line and wants requests for it served the "luggages" content instead, invisibly, without a public redirect. Go to Rules > Overview, and in the URL Rewrite Rules section click Create rule. Name it "Retire arrows path". Choose Custom filter expression and match URI Path equals /services/arrows/. Under Then rewrite the path and/or query, in the Path group choose Rewrite to with type Static. The value field already shows a leading /, so type services/luggages/ without a leading slash (the final path becomes /services/luggages/). Typing /services/luggages/ here would produce a broken //services/luggages/. Leave the Query untouched, then Deploy.

curl -s -o /dev/null -w "%{http_code}\n" https://<student-domain>/services/arrows/

Lab 6 Wrap-up

Lab 6 Troubleshooting

Lab 7 - WAF Managed Rulesets

7.1 Prove the Lab 1 attacks still land through Cloudflare

The origin is proxied now, but proxying alone does not inspect traffic. From the workstation, replay two of the Lab 1 attacks against the proxied hostname (not the raw IP) and confirm they still succeed:

curl -s -o /dev/null -w "secrets.txt: %{http_code}\n" https://<student-domain>/.git/secrets.txt
curl -s -o /dev/null -w "contact SQLi: %{http_code}\n" "https://<student-domain>/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20"

7.2 Deploy the Managed Ruleset the safe way: Log, observe, then Block

A managed WAF can block legitimate traffic the instant you enable it, so professionals roll it out in Log first, watch what it would do, and only then switch to Block. Go to Security > Security rules. In the Managed rules section, click Deploy managed ruleset and deploy the Cloudflare Managed Ruleset. On its configuration, set the ruleset action override to Log and deploy.

Re-run the secrets-file attack, then look at what the WAF recorded:

curl -s -o /dev/null -w "secrets.txt: %{http_code}\n" https://<student-domain>/.git/secrets.txt

Now enforce. Edit the Cloudflare Managed Ruleset and change the action override from Log to Block, then deploy. Wait 15 to 30 seconds for the change to reach the edge and re-run the attack:

curl -s -o /dev/null -w "secrets.txt: %{http_code}\n" https://<student-domain>/.git/secrets.txt

7.3 Add OWASP Core as defense in depth (Log)

Back in Security > Security rules > Managed rules, click Deploy managed ruleset again and deploy the Cloudflare OWASP Core Ruleset. On its configuration page, leave Anomaly Score Threshold at Medium (40) and Paranoia Level at PL1, set the action to Log, and deploy.

7.4 The fix breaks a customer: reproduce, then repair with a surgical exception

The contact form at /contact/ accepts free text that can look like an injection payload, so a real customer message can trip the WAF. Reproduce the false positive from the workstation:

curl -s -o /dev/null -w "contact: %{http_code}\n" "https://<student-domain>/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20"

Now the experience: break it, watch it fail, then fix it. The instinct is to add a skip exception. Go to Security > Security rules, click Create rule > Managed rules (the New managed rules exception page). Name it "Contact form exclusion". Under When incoming requests match set Field = URI Path, Operator = wildcard, Value = /contact/*. Keep Skip all remaining rules. Leave Place at on its default of Last and Deploy. Wait 15 to 30 seconds and re-test with a fresh marker:

curl -s -o /dev/null -w "contact: %{http_code}\n" "https://<student-domain>/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20&n=1"

Fix. Edit the "Contact form exclusion" exception and change Place at from Last to First, then Deploy. Wait 15 to 30 seconds, then send the contact request a few times with unique markers and one control request to the still-protected secrets path:

for n in 1 2 3; do curl -s -o /dev/null -w "contact n=$n: %{http_code}\n" "https://<student-domain>/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20&n=$n"; done
curl -s -o /dev/null -w "control secrets.txt: %{http_code}\n" https://<student-domain>/.git/secrets.txt

7.5 Triage the incident in Security Analytics

You have now generated blocks, a skip, and log events. Use Security > Analytics the way an analyst does during an incident. The Events tab groups firewall events by Action and by Service (for example, Managed rules) and lists the top source IPs, paths, user agents, and countries. The Traffic tab shows sampled request logs with Cloudflare's threat classifications.

With Group view by: Action, read the summary cards, then drill in to answer three questions: which service and which rules fired most, which paths were targeted, and whether a single source is responsible. Expand one Block event to view its Ray ID, User Agent, ASN, and matched rule.

Lab 7 Wrap-up

Lab 7 Troubleshooting

Lab 8 - WAF Custom Rules

8.1 The threat brief and campaign baseline

Security hands you a brief: a single actor is probing AcmeCorp. They scrape the catalog, push SQL injection at the contact form, knock on /admin, and abuse the partner API. Managed rules from Lab 7 catch known-bad signatures, but they do not enforce AcmeCorp policy: geography, least-privilege admin access, and an API contract. You author that policy in this lab.

First, replay the Lab 1 campaign through Cloudflare and record what your current posture does. Run all four and note each code:

curl -s -o /dev/null -w "scrape:       %{http_code}\n" https://<student-domain>/services/luggages/
curl -s -o /dev/null -w "contact SQLi: %{http_code}\n" "https://<student-domain>/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20"
curl -s -o /dev/null -w "admin probe:  %{http_code}\n" https://<student-domain>/admin
curl -s -o /dev/null -w "secrets file: %{http_code}\n" https://<student-domain>/.git/secrets.txt

8.2 Geofence sanctioned countries, quietly watch a competitor

Goal: refuse traffic from a set of sanctioned countries (regulatory compliance), and separately log, not block, a competitor's region for intelligence.

Go to Security > Security rules. In the Custom rules card click Create rule, name it "Geo Block - Sanctioned", and click Edit expression (top-right of the "When incoming requests match" box). Type this expression, which matches when the source country is in a set of sanctioned ISO codes. Set the action to Block and Deploy:

ip.src.country in {"KP" "IR" "SY" "CU"}

Your turn (build it yourself): you just built one set-based geo rule step by step. Now author a similar one on your own. Create a rule named "Competitor Monitoring" that matches AcmeCorp's two competitor regions, China and Russia, but sets the action to Log instead of Block, so the match is recorded for intelligence without mitigating. Use the same ip.src.country in {..} pattern you just learned: click Edit expression, type your expression, set the action to Log, and Deploy.

Prove the block from one location. Your workstation has a single source country, so you cannot originate traffic from a sanctioned country. Find your country, then confirm normal traffic is allowed:

curl -s https://<student-domain>/cdn-cgi/trace | grep '^loc='
curl -s -o /dev/null -w "control /: %{http_code}\n" https://<student-domain>/

To prove the Block action fires, edit "Geo Block - Sanctioned", temporarily add your own country to the set (for example ip.src.country in {"KP" "IR" "SY" "CU" "<your-cc>"}), Save, wait about a minute, and re-run the control:

curl -s -o /dev/null -w "control /: %{http_code}\n" https://<student-domain>/

Finally, review the results at Security > Analytics > Events.

8.3 Re-close the contact form your own exception reopened

In 8.1 you saw the uncomfortable result: the contact-form SQLi returned 200, not 403. Your Lab 7 exception (the /contact/* skip, placed first) told the managed ruleset to leave that path alone, and the injection walked straight through. You will not remove that exception, the contact form still needs it for legitimate submissions, so instead you add a custom rule in a different phase that closes the gap.

Go to Security > Security rules. In the Custom rules card click Create rule. Name it "Challenge Contact Form", click Edit expression, and type this expression, which matches the contact path exactly. Under Then take action choose Managed Challenge, and Deploy:

http.request.uri.path eq "/contact/"

curl -s -o /dev/null -w "contact SQLi: %{http_code}\n" "https://<student-domain>/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20"
curl -s -D - -o /dev/null "https://<student-domain>/contact/" | grep -i "cf-mitigated"

8.4 Lock down the admin panel, the wrong way then the right way

The attacker reached /admin in Lab 1. It is protected by origin Basic auth (that is the 401 you keep seeing), but AcmeCorp policy says only corporate egress IPs should even reach it. You will build that lockdown, and on the way you will fall into the single most common custom-rule mistake and climb back out.

First, find the workstation's public IP by running this on the workstation:

curl -s https://api.ipify.org; echo

Lists are defined at the account level. Go to Manage account > Configurations > Lists, click Create IP list, set the Identifier to corporate_ips (lowercase letters, numbers, and underscores only; it cannot be changed later), and Create. On the next screen add the workstation's public IP and click Add to list.

Build it the wrong way first, on purpose. The intuitive design is "Allow the corporate list into /admin". Return to Security > Security rules, create a custom rule named "Admin Allow Corp (broken)", click Edit expression, type the expression below, set the action to Allow, and Deploy:

(http.request.uri.path eq "/admin") and (ip.src in $corporate_ips)

Observe the trap. Simulate an outsider by removing your IP from corporate_ips (Manage account > Configurations > Lists > corporate_ips, delete your entry), wait about 15 seconds, then probe /admin from the workstation:

curl -s -o /dev/null -w "admin (off-list): %{http_code}\n" https://<student-domain>/admin

Fix it. Edit the rule (rename it "Allow Corp Admin Only" if you like), click Edit expression, and invert the logic to block /admin for anyone not on the list. Change the action to Block and Deploy:

(http.request.uri.path eq "/admin") and not (ip.src in $corporate_ips)

Confirm both sides. With your IP still off the list:

curl -s -o /dev/null -w "admin (off-list): %{http_code}\n" https://<student-domain>/admin

8.5 A least-privilege perimeter on the partner API

The partner API accepts orders, but the Lab 1 recon showed the origin answering more HTTP methods than the contract needs. AcmeCorp policy: the public API surface should accept only the methods it actually uses, and a trusted partner should be exempt from the managed ruleset but never from the method contract. You will build two rules and then prove how they interact.

Rule 1, the method allowlist (build this one step by step). Go to Security > Security rules, create a custom rule named "API Method Allowlist", click Edit expression, and type the expression below. It matches partner-API requests whose method is not one of the two the contract allows. Set the action to Block and Deploy:

(http.host eq "public-api.<student-domain>") and not (http.request.method in {"GET" "POST"})

Prove it from the workstation:

D=<student-domain>
curl -s -o /dev/null -w "GET orders:    %{http_code}\n" "https://public-api.$D/v1/orders"
curl -s -o /dev/null -w "DELETE orders: %{http_code}\n" -X DELETE "https://public-api.$D/v1/orders"

Rule 2, the trusted-partner bypass (your turn, build it yourself). You just built one scoped custom rule end to end. Now author a similar one on your own to a new objective. A trusted B2B partner's automated calls trip the managed ruleset and generate false positives, so you want to Skip the managed rules for them, but only when you are confident it really is the partner. Require two factors: the request must carry the header x-partner-api: true and originate from an IP on the corporate_ips list you built in 8.4. Create a rule named "Skip Managed for Partner API", scope it to the partner host, action Skip with All managed rules ticked, and place it above the method allowlist. Remember: header names are lowercased in expressions, and http.request.headers[...] returns an array, so wrap the header test in any(...[*] eq "true").

(http.host eq "public-api.<student-domain>") and any(http.request.headers["x-partner-api"][*] eq "true") and (ip.src in $corporate_ips)

Now prove how Rule 1 and Rule 2 interact. This is the teaching point of the lab. Send the partner's credentials three ways from the workstation (your workstation IP is on corporate_ips, so it satisfies the second factor):

D=<student-domain>
P="q=admin%27%20OR%20%271%27%3D%271%27%20--%20"
curl -s -o /dev/null -w "partner GET (SQLi):   %{http_code}\n" -H "x-partner-api: true" "https://public-api.$D/v1/orders?$P"
curl -s -o /dev/null -w "partner DELETE:       %{http_code}\n" -H "x-partner-api: true" -X DELETE "https://public-api.$D/v1/orders"
curl -s -o /dev/null -w "no-header GET (SQLi): %{http_code}\n" "https://public-api.$D/v1/orders?$P"

8.6 Re-run the campaign and triage in Analytics

Your custom policy is live. Replay the Lab 1 and 8.1 campaign one more time to see how the posture changed, then read the story in Analytics.

D=<student-domain>
curl -s -o /dev/null -w "scrape:       %{http_code}\n" "https://$D/services/luggages/"
curl -s -o /dev/null -w "contact SQLi: %{http_code}\n" "https://$D/contact/?comment=admin%27%20OR%20%271%27%3D%271%27%20--%20"
curl -s -o /dev/null -w "admin probe:  %{http_code}\n" "https://$D/admin"
curl -s -o /dev/null -w "secrets file: %{http_code}\n" "https://$D/.git/secrets.txt"
curl -s -o /dev/null -w "API DELETE:   %{http_code}\n" -X DELETE "https://public-api.$D/v1/orders"

Read the whole policy at once in Security > Analytics > Events. Set Group view by: Action to see Block, Managed Challenge, and Skip side by side, then switch Group view by to Rule to attribute each mitigation to the custom rule that produced it.

Lab 8 Wrap-up

Lab 8 Troubleshooting

Lab 9 - Bot Management

9.1 Bot analytics and the baseline challenge rule

First confirm Bot Management is on. Go to Security > Settings and find the Bot traffic section: Bot management should read Always active on this Enterprise zone.

Review live bot traffic in Security > Analytics: click Add filter, choose Bot score, and inspect the low-score band plus the Source user agents and Source ASNs lists.

Create the rule: Security > Security rules > Custom rules > Create rule. Name it "Bot Management - Baseline", click Edit expression, and paste the expression below. It fires on low-scoring, non-verified traffic to the bot-demo path only. Start the action on Log, then Deploy. (A ready-made Templates option, "Mitigate definite bot traffic", is also available under Security rules if you prefer a guided starting point.)

(cf.bot_management.score lt 30) and not cf.bot_management.verified_bot and http.request.uri.path contains "/hellobots"

Predict before you flip it. Once the Log events look right, edit the rule, change the action to Managed Challenge, and Deploy. Before running anything, predict: a scripted curl from a single egress IP scores low and is not a verified bot, so when it requests /hellobots, what status code and what mitigation header should it get? Note your answer, then test:

curl -s -o /dev/null -w "%{http_code}\n" "https://<student-domain>/hellobots"
curl -s -D - -o /dev/null "https://<student-domain>/hellobots" | grep -i "cf-mitigated"

9.2 Tune out trusted automation (your turn)

The baseline rule now challenges everything low-scoring on /hellobots, and that includes traffic you trust. Two legitimate low-scoring clients must keep working: a nightly internal BI tool that identifies itself with the user agent B1-Bot/1.11, and a trusted catalog-sync job that hits /services/luggages/. Both currently score low and would be challenged.

Your turn (build it yourself): you saw the baseline expression built step by step. Now extend it on your own. Edit "Bot Management - Baseline", click Edit expression, and add two and not (...) clauses so the rule still catches low-scoring bots but carves out the two trusted clients: exclude the exact path /services/luggages/ and the exact user agent B1-Bot/1.11. Keep the score and verified-bot logic. Leave the action on Managed Challenge and Deploy.

(cf.bot_management.score lt 30) and not cf.bot_management.verified_bot and not (http.request.uri.path eq "/services/luggages/") and not (http.user_agent eq "B1-Bot/1.11")

With the action on Managed Challenge, test all three cases from the workstation:

D=<student-domain>
curl -s -L -o /dev/null -w "hellobots: %{http_code}\n" "https://$D/hellobots"
curl -s -L -o /dev/null -w "luggages:  %{http_code}\n" "https://$D/services/luggages/"
curl -s -L -o /dev/null -w "B1-Bot UA: %{http_code}\n" -A "B1-Bot/1.11" "https://$D/hellobots"

9.3 The over-broad rule: predict the blast radius, then fix it

Look closely at the expression you just wrote. In carving out the two trusted clients, the path scope http.request.uri.path contains "/hellobots" is gone. The rule no longer targets the bot-demo path; it now evaluates every request on the zone.

Predict first. Your workstation curl scores as automated and is not a verified bot, and the homepage / is neither /services/luggages/ nor the B1-Bot agent. Predict what the homepage returns now, then check it:

curl -s -D - -o /dev/null "https://$D/" | grep -iE "HTTP/|cf-mitigated"

Fix it. Edit the "Bot Management - Baseline" rule, change the action from Managed Challenge to Log, and Deploy. Re-run the homepage check:

curl -s -D - -o /dev/null "https://$D/" | grep -iE "HTTP/|cf-mitigated"

Lab 9 Wrap-up

Lab 9 Troubleshooting

Lab 10 - Threat Intel with Managed Lists

10.1 Block open proxies and anonymizers

Go to Security > Security rules > Custom rules and click Create rule. Name it "Block Malicious IPs by Managed List". Build the match with the visual expression builder:

• Field = IP Source Address, Operator = is in list, Value = Open Proxies (a Cloudflare-managed list).
• Click Or to add a second condition: Field = IP Source Address, Operator = is in list, Value = Anonymizers.

The Expression Preview should read exactly. Set the action to Block, set Status = Active, and click Deploy:

(ip.src in $cf.open_proxies) or (ip.src in $cf.anonymizer)

Confirm the rule is live and that it does not touch your own traffic. From the workstation:

curl -s -o /dev/null -w "control /: %{http_code}\n" https://<student-domain>/

10.2 Add a high-confidence block tier (your turn)

Two more managed lists describe networks that are outright malicious rather than merely anonymizing: Botnets / Command and Control Servers and Malware. Traffic from these should be blocked with even higher confidence than a proxy.

Your turn (build it yourself): you just built one managed-list Block rule with the visual builder. Now author a second one on your own, named "Block C2 and Malware Networks". Use the same builder steps: Field = IP Source Address, Operator = is in list, choose the Botnets / Command and Control Servers list, click Or, then add a second is in list condition for the Malware list. Set the action to Block, Status = Active, and Deploy.

10.3 Predict how this interacts with your partner bypass

In Lab 8 you built a partner rule with the Skip -> All managed rules action for trusted B2B traffic. Suppose one of that partner's calls arrives from an IP that happens to be on the Open Proxies list.

Predict: does the partner Skip let that request through, or does your 10.1 managed-list rule still block it? Decide before reading on.

Lab 10 Wrap-up

Lab 10 Troubleshooting

Lab 11 - Rate Limiting

11.1 Rate Limit By IP (Brute Force Protection)

Go to Security > Security rules, scroll to Advanced rate limiting rules, and click Create rule. Name it "Safes Page Rate Limit", click Edit expression, and match the target path:

http.request.uri.path contains "/services/safes/"

Under With the same characteristics leave IP selected. Under When rate exceeds set Requests = 5 and Period = 1 minute. Under Then take action choose Block, and set the duration to 1 minute. Click Deploy.

Predict, then burst. The threshold is 5 requests per minute per IP, so predict: in a rapid loop of 8 requests from one IP, roughly which request number should first return 429? Note your answer, then run the burst from the workstation:

D=<student-domain>
for i in $(seq 1 8); do curl -s -o /dev/null -w "req $i -> %{http_code}\n" "https://$D/services/safes/"; done

11.2 Rate limit by origin response code (your turn)

Attackers fuzz search endpoints with junk queries to find hidden parameters. Those probes overwhelmingly generate 404 responses. A plain per-IP limit is crude here: you only want to throttle clients that keep generating errors, not real users who search successfully. Cloudflare can count the origin's response code instead of raw requests.

In the same Advanced rate limiting rules section, click Create rule and name it "Search Fuzzing Protection". Click Edit expression and match the search path:

http.request.uri.path eq "/services/search"

Your turn (configure it yourself): you built a per-IP limit in 11.1. This one is similar but adds one twist you now configure on your own. Tick Use custom counting expression, and in the Increment counter when box author the condition so the counter advances only when the origin responds with a not-found. Set the threshold to 10 requests per 1 minute, action Block with a 1 minute duration, and Deploy.

Test from the workstation. The nonexistent path returns 404, so every request feeds the counter:

D=<student-domain>
for i in $(seq 1 25); do curl -s -o /dev/null -w "req $i -> %{http_code}\n" "https://$D/services/search?q=$i"; done

Lab 11 Wrap-up

Lab 11 Troubleshooting

Lab 12 - API Discovery & Endpoint Management

12.1 Session identifier and attributed traffic

Add the session identifier. Go to Security > Settings, open the API abuse category, and click into Session identifiers. This zone starts with no identifier configured, so click Add identifiers, set Type = Header and Name = session-id, and Save. The page then shows 1 / 10 identifiers added with the status "Identifier not seen in requests" until the traffic you generate below starts carrying the header.

Predict, then confirm the surface is reachable. Before generating bulk traffic, predict what an authorized list call should return, then check one request carrying your header:

H=public-api.<student-domain>
curl -s -o /dev/null -w "GET /v1/orders: %{http_code}\n" -H "session-id: user-1" "https://$H/v1/orders"

Now generate representative API traffic from the workstation. Send a distinct session-id per simulated user across the API's real endpoints (list orders, read one order, create an order):

H=public-api.<student-domain>
for u in $(seq 1 20); do
  S="session-id: user-$u"
  curl -s -o /dev/null -H "$S" "https://$H/v1/orders"
  curl -s -o /dev/null -H "$S" "https://$H/v1/orders/0"
  curl -s -o /dev/null -H "$S" -X POST -H "Content-Type: application/json" -d "{\"createdBy\":\"user$u\",\"items\":[\"sku-$u\"]}" "https://$H/v1/orders"
done

12.2 Bring the first operation under management

Discovered endpoints appear under Security > Web assets > Operations (Endpoint Management) via Add operations > Select from Discovery. Until Discovery populates, you add operations manually. Do the first one together, step by step. On Add operations, choose Add custom operations, and enter:

• Method: POST
• Hostname: public-api.<student-domain>
• Path: /v1/orders

Click Save operations.

12.3 Add the remaining operations (your turn)

The orders API has two more real operations you just generated traffic for: listing orders and reading a single order by id. Bring them under management too.

Your turn (build it yourself): using the same Add operations > Add custom operations flow you just used, add these two operations on the public-api.<student-domain> host: a GET on /v1/orders, and a GET on the single-order path /v1/orders/{id} (use the {id} path-variable placeholder so it matches any order id). Save.

Lab 12 Wrap-up

Lab 12 Troubleshooting

Lab 13 - API Schema Validation

13.1 Enforce the OpenAPI contract

First, onboard the orders API. In Cloudflare DNS > Records, create an A record named api (the name must be exactly api) pointing to 4.157.169.241, with Proxy Status set to Proxied (orange cloud).

Obtain the OpenAPI schema for the orders API. Use the lab schema generator at schema-generator.labs.cfdata.org to produce an OpenAPI document whose servers URL points at https://api.<student-domain>.

Go to Security > Web assets > Schema validation, click Upload schema, select the file, review that the endpoints map to api.<student-domain>, and click Add schema and endpoints. Then tick the POST /v1/orders row, click Change action, choose Block, and Set action.

Predict, then test. You will send one compliant request and two violations. Before running, predict each result and the reason: which one reaches the origin, which are stopped at the edge, and whether a stopped request shows Cloudflare's 403 or the origin's own 400. The schema requires each entry in items to be a UUID, so a ready-to-use UUID is provided below (no need to find your own):

H=api.<student-domain>
CT="Content-Type: application/json"
UUID=5bd195af-f22a-4cf7-ae9b-116d47104fbc
curl -s -o /dev/null -w "compliant:      %{http_code}\n" -X POST -H "$CT" -d "{\"createdBy\":\"alice\",\"items\":[\"$UUID\"]}" "https://$H/v1/orders"
curl -s -o /dev/null -w "bad item type:  %{http_code}\n" -X POST -H "$CT" -d "{\"createdBy\":\"alice\",\"items\":[\"sku1\"]}" "https://$H/v1/orders"
curl -s -o /dev/null -w "missing items:  %{http_code}\n" -X POST -H "$CT" -d "{\"createdBy\":\"alice\"}" "https://$H/v1/orders"

13.2 Close the undefined-operation gap (your turn)

Body validation only checks operations the schema defines. An attacker can still probe operations that are not in the schema at all: an undefined path, or an unexpected method on a known path. A fallthrough block rejects any request to the API host that does not match a known operation.

Your turn (do it yourself): in Schema validation, use the Fallthrough template / setting to Block requests to the API host that do not match any known operation. Then prove it yourself. Predict what a request to an operation the schema does not define should return, then probe one undefined operation from the workstation:

H=api.<student-domain>
curl -s -o /dev/null -w "undefined op: %{http_code}\n" "https://$H/v1/refunds"

Lab 13 Wrap-up

Lab 13 Troubleshooting

Lab 14 - Page Shield: Client-Side Protection

14.1 Client-side Resource Monitoring

Enable monitoring. Go to Security > Settings, open the Client side abuse category, and turn on Continuous script monitoring.

Generate traffic by loading the demo page in the workstation browser: https://ps.<student-domain>/contact/received/. This page deliberately loads several third-party scripts and opens several outbound connections, including a malicious sample. Then review the inventory under Security > Web assets > Client-side resources, across its Scripts, Connections, and Cookies tabs.

14.2 Content Security Rules (CSP)

Monitoring tells you what is running; a Content security rule enforces what is allowed to run. Go to Security > Security rules, find Content security rules, and click Create rule. Name it "Page Shield - Script Allowlist".

Scope the rule to your site host, and build the allowlist from the legitimate resources you saw in 14.1 (leaving the malicious ones off, so they become violations):

• Script sources: self, useinsider.com, *.useinsider.com, www.rtb123.com, and jsdelivr.at.
• Connection sources: self.

Set Action = Log to start in report-only mode, then Deploy. Report-only lets browsers report violations without blocking, so you can confirm the allowlist does not catch anything legitimate before you enforce it.

Predict, then confirm. Predict which CSP header a report-only policy emits, then check the response from the workstation:

curl -s -D - -o /dev/null https://ps.<student-domain>/contact/received/ | grep -i content-security

14.3 Enforce the allowlist (your turn)

Report-only has shown the allowlist is correct. Now enforce it so off-list resources are actually blocked in the browser, not just reported.

Your turn (do it yourself): edit "Page Shield - Script Allowlist" and change the action from Log to Allow, which switches the policy from report-only to enforcing, then Deploy. Predict how the response header should change, then re-run the same check:

curl -s -D - -o /dev/null https://ps.<student-domain>/contact/received/ | grep -i content-security

Lab 14 Wrap-up

Lab 14 Troubleshooting

Final lab: seal the perimeter, then replay the opening attacks to prove it holds.

Lab 15 - Seal & Validate the Perimeter

15.1 Seal the Origin (Simulated)

Proxying through Cloudflare hides the origin IP, but it does not by itself stop someone who already knows the IP (as you did in Lab 1) from connecting directly and skipping every edge control. Closing that gap requires the origin to reject any request that did not come from Cloudflare. On a real origin there are two standard ways:

• Authenticated Origin Pulls (mTLS): Cloudflare presents a client certificate on every origin request, and the origin's web server is configured to require and verify it (for example nginx ssl_client_certificate + ssl_verify_client on). Direct-to-IP requests, which lack the certificate, are refused at the TLS layer. You enable this in the zone's SSL/TLS settings and configure the web server to enforce it.
• Network IP allowlist: restrict the origin's firewall or cloud security group so only Cloudflare's published IP ranges may reach ports 80 and 443. Everything else is dropped before it reaches the web server.

You cannot run either method against the shared lab origin, so simulate the seal from the workstation by dropping traffic to the origin IPs at your local firewall. This makes the origin unreachable from where you launch attacks, exactly as a real seal would. Start with the web origin, step by step:

sudo iptables -A OUTPUT -d 20.88.188.200 -j REJECT

curl -s -o /dev/null -w "%{http_code}\n" --max-time 6 http://20.88.188.200/ || echo "blocked (curl exit $?)"

Your turn (do it yourself): the orders API runs on a second origin IP, 4.157.169.241, that is just as reachable directly and would let an attacker bypass every API Shield control you built. Seal it too, using the exact same technique you just used for the web origin, then prove it is refused.

curl -s -o /dev/null -w "%{http_code}\n" --max-time 6 https://4.157.169.241/ || echo "blocked (curl exit $?)"

15.2 Replay the Lab 1 Attacks

With both origin IPs sealed (simulated), rerun the opening attacks. The direct-to-IP path is gone, and the Cloudflare path is now defended by everything you built in Labs 7 to 14. Predict first: for each probe below, predict the new result and which layer produces it, then run them. Confirm the Cloudflare path still works and the sensitive file is virtually patched:

curl -s -o /dev/null -w "website via CF: %{http_code}\n" https://<student-domain>/
curl -s -o /dev/null -w "/.git via CF:   %{http_code}\n" https://<student-domain>/.git/secrets.txt

Compared to your Lab 1 baseline:

• Sensitive file, now virtually patched. /.git/secrets.txt through Cloudflare returns 403 (Lab 7), where Lab 1 returned the secrets.
• Volumetric abuse, now throttled. The Lab 11 rate limits cap repeated hits with 429, where Lab 1 let every request through.
• Direct-to-IP, now refused. http://20.88.188.200/ fails from your workstation, where Lab 1 returned 200.

Remove the simulated seal to restore the workstation to its normal state:

sudo iptables -D OUTPUT -d 20.88.188.200 -j REJECT
sudo iptables -D OUTPUT -d 4.157.169.241 -j REJECT

curl -s -o /dev/null -w "%{http_code}\n" --max-time 6 http://20.88.188.200/

15.3 Architecture Recap

You took AcmeCorp from wide open to a defended edge. Here is the perimeter you built, layer by layer, and the Lab 1 problem each layer answers.

Lab 15 Troubleshooting

End of Unified Lab Guide (Legacy Edition).