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. You create the apex record (<student-domain>) in Lab 2 to publish the AcmeCorp website, then add public-api.<student-domain> (the orders API used in the API Shield labs) and ps.<student-domain> (the Page Shield demo page) in the labs that use them. All of these resolve to the shared origin that Cloudflare operates for the class.

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 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

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).

2.2 Partial (CNAME) Setup for a Stubborn Partner (Concept)

Prerequisites you would confirm first. The domain must be on a Business or Enterprise plan, it must keep its current authoritative DNS provider, and it must not be a domain where Cloudflare is already authoritative. Only proxyable record types (A, AAAA, CNAME) can be onboarded this way, and the root/apex cannot be proxied in a partial setup, only subdomains.

Convert the zone to CNAME setup. On the domain's Overview page, in the DNS card on the right, you would select Convert to CNAME DNS Setup, then Convert to confirm. This switches the zone type from Full to Partial.

Prove ownership with the verification TXT record. Cloudflare then generates a Verification TXT Record (also found on DNS > Records). You add that exact record at the partner's authoritative DNS provider; Cloudflare polls for it, marks the zone active, and emails a confirmation. The TXT record proves you control the domain and must stay in place for as long as the zone remains partial.

Onboard the hostname. In Cloudflare you create a proxied (orange-cloud) record for the hostname, for example portal. Then at the partner's provider you create a CNAME for that hostname pointing to Cloudflare's target, for example portal.example.com.cdn.cloudflare.net, and remove any old A/AAAA/CNAME for that hostname. That CNAME is what reroutes visitor traffic into Cloudflare's edge while every other record on the domain keeps resolving straight from the partner's DNS.

2.3 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>

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

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.

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 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 confirm Browser Cache TTL is set to Respect Existing Headers.

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 5 - Advanced Caching (Concept)

5.1 Cache Everything & Cookie Bypass (Concept)

You would create a Cache Rule for a marketing landing path with Cache eligibility = Eligible for cache so Cloudflare caches the HTML itself, not just static file types. This lets the page survive a massive traffic spike because most requests are answered from the edge.

Caching HTML is dangerous if users can log in, because a cached personalized page could be served to the wrong user. To make it safe, you would add a second rule that bypasses cache when a session cookie is present (for example Cookie contains session_id). Anonymous visitors get the fast cached page; logged-in users always bypass to the origin.

5.2 Custom Cache Key (Concept)

Marketing tracking tags (?utm_source=twitter, ?utm_source=email) create unique URLs that each miss the cache and hit the origin. You would define a Custom Cache Key that ignores query strings, so every variant of a URL collapses into one cached object.

5.3 Tiered Caching (Concept)

You would enable Tiered Cache (Caching > Tiered Cache) and select Smart Tiered Cache Topology. Instead of every global PoP fetching from the origin, lower-tier PoPs ask an upper-tier PoP first.

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/

6.6 Host Header Overrides (Concept)

You would create an Origin Rule (Rules > Origin Rules) that matches the API path (for example starts_with(http.request.uri.path, "/api/")) and, under Host Header, selects Rewrite to and enters public-api.<student-domain>, leaving SNI, DNS Record, and Destination Port set to Preserve. The origin would then route /api/* to the API virtual host, without changing the public URL or touching origin code.

Lab 7 - Load Balancing & Failover (Concept)

7.1 Origin Pools & Health Checks (Concept)

All Load Balancing objects live under Traffic > Load Balancing, and you build bottom-up: monitor first, then pools, then the load balancer. You would create an HTTP monitor (for example Path /, Port 80, expecting 200) that Cloudflare uses to probe each origin from its edge.

You would then create two Origin Pools, each with one endpoint (the primary origin in one pool, the backup origin in the other) and attach the monitor to both.

7.2 Implementing Failover (Concept)

You would create a load balancer, add the primary pool first and the backup pool second (order is the failover order), set the fallback pool to the backup, and choose Off (Failover) steering so 100% of traffic goes to the first healthy pool.

To prove it, you would take the primary origin's web server offline. Within a health-check cycle the primary pool goes Unhealthy and traffic shifts entirely to the backup pool, then returns to the primary once it recovers.

Lab 8 - Advanced Health Checks & Steering (Concept)

8.1 Advanced Health Checks (Concept)

A basic HTTP monitor only proves the web server answered 200. You would create a monitor that also inspects the response body, setting Response Body to a required substring such as "status":"healthy" under the monitor's advanced settings, then attach it to the primary pool.

If an origin still returns 200 but its /status body no longer contains that substring (a "zombie"), the content-aware monitor marks the pool unhealthy and traffic fails over, even though a basic check would have kept sending users to the broken app.

8.2 Weighted Steering (Concept)

You would change the load balancer's steering policy from Off (Failover) to Random and set pool weights (for example primary 0.6, secondary 0.4) so traffic is split roughly 60/40 across pools.

8.3 Session Affinity (Concept)

Weighted Random steering picks a pool per request, so the same visitor can bounce between origins on consecutive clicks, which breaks a stateful flow (a login session or a shopping cart held on one origin). You would fix this with Session Affinity: on the load balancer's Hostname step (below the load balancer description), tick the Session Affinity checkbox. Cloudflare then issues an affinity cookie that pins each client to one endpoint for as long as that endpoint stays healthy.

Lab 9 - WAF Managed Rulesets

9.1 Deploy the WAF and understand OWASP

First, from the workstation, confirm the exposure is still live through Cloudflare (not just on the raw IP):

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

Go to Security > Security rules. In the Managed rules section, click Deploy managed ruleset and deploy the Cloudflare Managed Ruleset.

Deploy the Cloudflare OWASP Core Ruleset as well. On its configuration page, leave Anomaly Score Threshold at Medium (40) and Paranoia Level at PL1, and deploy it in Log action to start.

Now retest the exposed file through Cloudflare:

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

9.2 Dealing with False Positives

The contact form at /contact/ accepts free-text that can look like an injection payload, so legitimate submissions can trip the WAF's SQL-injection rules. First reproduce the false positive from the workstation:

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

Create a surgical 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. Change Place at from Last to First, then Deploy.

9.3 Reading Analytics & Identifying Threats

Go to Security > Analytics. The Events tab groups firewall events by Action and by Service (for example, Managed rules) and lists the top source IPs, paths, and countries. The Traffic tab shows sampled request logs with Cloudflare's threat classifications.

Use the filters to answer: which rules or services triggered most, and is a single source responsible? Drill into an event to view the Ray ID, User Agent, ASN, and matched rule.

Lab 10 - WAF Custom Rules

10.1 Geo Blocking + Different Actions

Go to Security > Security rules. In the Custom rules card click Create rule (or use the Create rule menu at the top right and choose Custom rules). Name it "Geo Block".

Click Edit expression (top-right of the "When incoming requests match" box) to switch to the raw expression editor, then paste an expression that matches everything outside the United States and Canada. Under "Then take action" choose Block, leave the response as the default Cloudflare WAF block page (403), and click Deploy:

not (ip.src.country in {"US" "CA"})

Create a second, separate custom rule named "Competitor Monitoring". Set the action to Log and use an expression that matches a single country you want to watch, such as China:

ip.src.country eq "CN"

First, from the workstation, confirm that normal traffic is allowed by your Geo Block rule:

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

Now open Security > Security rules > Custom rules, edit Geo Block, temporarily change its expression to match your own country (for example ip.src.country eq "US"), click Save, wait about 15 seconds for the edge to update, then re-run the same curl:

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

10.2 Challenge the Contact Form

Go to Security > Security rules. In the Custom rules card click Create rule. Name it "Challenge Contact Form", click Edit expression, and match the contact path:

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

Under Then take action choose Managed Challenge, and Deploy.

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

10.3 Lock Down the Admin Panel with an IP List

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.

Return to Security > Security rules, create a custom rule named "Allow Corp Admin Only", click Edit expression, and block /admin for anyone not on the corporate list. Set the action to Block and Deploy:

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

From the workstation (whose IP is on the list), confirm you are allowed through:

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

10.4 Skip Security for a Partner API

Go to Security > Security rules, create a custom rule named "Skip Partner API Security", and click Edit expression. Match requests to the partner API host that carry a trusted-partner header:

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

Under Then take action choose Skip. In "WAF components to skip" tick All managed rules, leave Log matching requests enabled, and Deploy.

P="q=admin%27%20OR%20%271%27%3D%271%27%20--%20"
curl -s -o /dev/null -H "x-partner-api: true" "https://public-api.<student-domain>/v1/orders?$P"
curl -s -o /dev/null "https://public-api.<student-domain>/v1/orders?$P"

Lab 11 - Bot Management

11.1 Bot Analytics & Baseline 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. Scope it to the bot-demo path and 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"

Once the Log events look right, edit the rule, change the action to Managed Challenge, and Deploy. Test from the workstation (a single-egress curl client scores as automated, so it is your stand-in scraper):

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"

11.2 Refine BM Rule to Exclude APIs

Legitimate automation also scores low: a nightly internal BI tool identifies itself with the user agent B1-Bot/1.11, and a trusted catalog-sync job hits /services/luggages/. Both would be challenged by the baseline rule. Edit "Bot Management - Baseline", click Edit expression, and replace the expression with:

(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 -o /dev/null -w "hellobots:       %{http_code}\n" "https://$D/hellobots"
curl -s -o /dev/null -w "luggages:        %{http_code}\n" "https://$D/services/luggages/"
curl -s -o /dev/null -w "B1-Bot UA:       %{http_code}\n" -A "B1-Bot/1.11" "https://$D/hellobots"

Lab 12 - Rate Limiting

12.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.

Test from the workstation by bursting past the threshold:

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

12.2 Rate Limit By Origin Response Code

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

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

Tick Use custom counting expression. In the Increment counter when box click Edit expression and enter the origin-response condition:

http.response.code eq 404

Set Requests = 10, Period = 1 minute. Under Then take action choose Block with duration 1 minute, then Deploy.

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

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

Lab 13 - API Discovery & Endpoint Management

13.1 Session Identifiers, Discovery & Endpoint Management

Confirm the session identifier. Go to Security > Settings, open the API abuse category, and click into Session identifiers. This managed lab preconfigures a Header identifier named session-id. If it is not present, click Add identifiers, set Type = Header and Name = session-id, and Save.

Generate API traffic from the workstation. Send a distinct session-id per simulated user across several endpoints, including the undocumented shadow endpoint:

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/status"
  curl -s -o /dev/null -H "$S" "https://$H/v1/orders"
  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"
  curl -s -o /dev/null -H "$S" "https://$H/internal/accessLogs"
done

Discovered endpoints appear under Security > Web assets > Operations (Endpoint Management) via Add operations > Select from Discovery. Until Discovery populates, add operations manually: on Add operations use Add custom operations and enter Method, Hostname (public-api.<student-domain>), and Path (for example POST /v1/orders), then Save operations.

Lab 14 - API Schema Validation & Sequence Analytics

14.1 Schema Validation

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.

Test from the workstation, one compliant request and a few violations:

H=api.<student-domain>
CT="Content-Type: application/json"
curl -s -o /dev/null -w "valid:          %{http_code}\n" -X POST -H "$CT" -d "{\"createdBy\":\"alice\",\"items\":[\"sku1\"]}" "https://$H/v1/orders"
curl -s -o /dev/null -w "extra field:    %{http_code}\n" -X POST -H "$CT" -d "{\"createdBy\":\"alice\",\"items\":[\"sku1\"],\"evil\":\"x\"}" "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"

Finally, add a fallthrough block. In Schema validation, use the Fallthrough template / setting to Block requests to the API host that do not match any known operation.

14.2 Sequence Analytics (Concept)

With session identifiers configured (Lab 13), you would generate traffic that follows the intended order (for example: check status, list orders, then create an order) plus some out-of-order calls (create an order with no preceding GETs). Sequence Analytics groups requests by session identifier and highlights the common ordered "journeys" through the API.

You would review the results under Security > Web assets > Sequences. When a risky sequence is identified (for example jumping straight to order creation without the normal preceding steps), you would mitigate it with a custom rule that references the API Shield sequence, or gate the sensitive operation behind a required precondition so out-of-order requests are challenged or blocked.

Lab 15 - Threat Intel with Managed Lists (Concept)

15.1 Using Managed Lists (Concept)

You would go to Security > Security rules > Custom rules, create a rule named "Block Malicious IPs by Managed List", and build the match with the expression editor: Field = IP Source Address, Operator = is in list, and select the managed Open Proxies list, then add an Or condition for the Anonymizers list. The Expression Preview reads:

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

You would set the action to Block and deploy.

Lab 16 - Spectrum for TCP/UDP (Concept)

16.1 Protecting TCP/UDP Applications (Concept)

Spectrum lives at (domain) > Spectrum. The page lists any existing applications and offers Create an Application.

The Create an Application dialog collects, in order: the Application Type (protocol carried edge-to-origin, for example TCP or UDP); a Domain subdomain that becomes the public entry point (Cloudflare creates the DNS record); Edge IP Connectivity (IPv4, IPv6, or both); an Edge Port (single port or a range); the Origin (an IP/DNS record, a Load Balancer, or a Virtual Network); and optional Edge TLS Termination, IP Access Rules, and Proxy Protocols.

A representative configuration would front an SSH jump host: Application Type TCP, Domain ssh.<student-domain>, Edge Port 22, Origin the jump host's IP on port 22. Users would connect to ssh.<student-domain> and reach the origin through Cloudflare, with the origin IP never exposed.

Lab 17 - Page Shield: Client-Side Protection

17.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.

17.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 17.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. Once you confirm nothing legitimate is caught, switch the action to Allow to enforce the allowlist.

Confirm the policy is live by checking the response header from the workstation:

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

End of hands-on labs. Lab 18 recaps and, as a concept, describes sealing the origin.

Lab 18 - Seal & Validate the Perimeter (Concept)

18.1 Seal the Origin (Concept)

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. 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.

18.2 Replay the Lab 1 Attacks (Concept)

On a sealed origin, you would rerun the Lab 1 attacks through the Cloudflare hostname (<student-domain>) and against the raw IP, and compare to your baseline:

• Sensitive file, now virtually patched. The Lab 9 managed ruleset blocks /.git/secrets.txt through Cloudflare with a 403, where Lab 1 returned the secrets.
• Volumetric abuse, now throttled. The Lab 12 rate limits cap repeated hits with 429, where Lab 1 let every request through.
• Direct-to-IP, now refused. A request to http://20.88.188.200/ would fail (connection refused, timeout, or TLS handshake failure) once the origin only accepts Cloudflare traffic.

18.3 Architecture Recap (Concept)

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.

End of Unified Lab Guide (Legacy Edition).