Application Security Demo

~25–30 min · Path: Protect & Connect → Application Security · Style: Conversational

Pre-demo setup checklist

Two windows side-by-side: Terminal (big font) + Application Security → Investigate
nginx.tarheel.us — proxied, WAF on, no Access
eve-ng.tarheel.us — proxied, WAF + Cloudflare Access
Custom WAF rule active on nginx.tarheel.us: lower(http.request.uri) contains "union" → Block
Browser tabs queued to Investigate and Security Analytics

Pre-flight (run 30 sec before going live)

FMT="Status: %{http_code}\n"
echo "T1 nginx ambiguous (expect 200):" && curl -s -o /dev/null -w "$FMT" "https://nginx.tarheel.us/?id=1%27%20OR%20%271%27=%271"
echo "T2 nginx UNION    (expect 403):" && curl -s -o /dev/null -w "$FMT" "https://nginx.tarheel.us/?id=1+UNION+SELECT+1,2,3"
echo "T3 eve-ng ambig.  (expect 302):" && curl -s -o /dev/null -w "$FMT" "https://eve-ng.tarheel.us/?id=1%27%20OR%20%271%27=%271"
echo "T4 eve-ng UNION   (expect 403):" && curl -s -o /dev/null -w "$FMT" "https://eve-ng.tarheel.us/?id=1+UNION+SELECT+1,2,3"

0. Opening — Setting the Stage

"Most companies have five or six tools doing this job today. WAF in one place, DDoS in another, bot management somewhere else, API security from yet another vendor. Each one is its own console, its own logs, its own contract."

"Cloudflare collapses all of that into one platform. Every request to your app already passes through our edge, so we can apply every one of those controls in a single pass — and you see all of it from a single nav."

1. Application Security — Landing Overview

2. Security Insights

"This page answers one question: 'what does my application security posture actually look like — across every domain on my account?'"

"In the old dashboard you hopped into each zone one at a time. This rolls all of it up — misconfigurations, recommendations, exposure indicators."

"This is the page I open first thing Monday morning. Not because I expect surprises — but because if there's going to be one, I want to see it before someone else does."

3. WAF

Managed Rulesets

Custom Rules

Rate Limiting

Bot signals woven through

4. Investigate + LIVE DEMO (the centerpiece)

TEST 1 — nginx.tarheel.us (ambiguous SQLi) → 200

curl -s -o /dev/null -w "Status: %{http_code}\n" \
  "https://nginx.tarheel.us/?id=1%27%20OR%20%271%27=%271"

What that URL actually says ?id=1' OR '1'='1

Every %27 in the curl is just a URL-encoded single quote ('). Browsers and servers see the decoded version — the textbook SQL injection payload.

Output: Status: 200

"Single quotes, OR '1'='1'. Textbook SQLi from every tutorial. HTTP 200. The page loaded. The attacker reached my origin."

⏸ Pause — this is the moment people get confused.

"And here's the question your audience is asking: 'Wait, Cloudflare let it through?' Let me answer it."

"The WAF doesn't block what looks suspicious. It blocks patterns that have a HIGH probability of being a real attack. Single quotes and OR appear in totally legitimate URLs — search queries, names like O'Brien, encoded forms. Block every quote in a URL and half the internet breaks."

"So the managed ruleset is calibrated. Maximize block rate on real attacks. Minimize false positives on real users."

TEST 2 — nginx.tarheel.us (UNION SELECT) → 403

curl -s -o /dev/null -w "Status: %{http_code}  |  Ray: %header{cf-ray}\n" \
  "https://nginx.tarheel.us/?id=1+UNION+SELECT+1,2,3"

Output: Status: 403 | Ray: abc123... (copy the Ray ID for the pivot)

"HTTP 403 Forbidden. Cloudflare block page comes up — 'Sorry, you have been blocked. The action you just performed triggered the security solution.'"

▶ Pivot: Domains → tarheel.us → Security → Analytics → search the CF-RAY ID. Show the event with full forensic detail.

"Why did THIS one get blocked when the first didn't? UNION SELECT in a query string is almost never legitimate. It's the technique attackers use to dump your customer database. No real-world URL where that string belongs."

"And here's the moat — that calibration is informed by Cloudflare's view of ~20% of all internet traffic. Threat research sees attack patterns evolve in real time across millions of sites. You don't maintain this. We do."

TEST 3 — eve-ng.tarheel.us (ambiguous SQLi) → 302

curl -s -o /dev/null -w "Status: %{http_code}\nRedirect: %{redirect_url}\n" \
  "https://eve-ng.tarheel.us/?id=1%27%20OR%20%271%27=%271"

What that URL actually says ?id=1' OR '1'='1

Same payload as TEST 1 — different destination. This time Access intercepts before the WAF ever sees the payload.

Output: Status: 302 + Redirect: https://<team>.cloudflareaccess.com/...

"HTTP 302. A redirect. The application didn't respond — Cloudflare did. Look at the location header — sending the attacker to cloudflareaccess.com."

"Before any rule engine even evaluated the payload, Access intercepted: 'Who are you? Authenticate first.' The attacker can't answer — they get bounced to a login they have no chance of completing."

"The application is invisible to anyone who isn't authorized. They didn't even get to confirm the app exists, let alone try a payload."

TEST 4 — eve-ng.tarheel.us (UNION SELECT) → 403

curl -s -o /dev/null -w "Status: %{http_code}\n" \
  "https://eve-ng.tarheel.us/?id=1+UNION+SELECT+1,2,3"

Output: Status: 403

"HTTP 403. The WAF still fires on this one — UNION SELECT is severe enough to trip the rule even on the protected domain."

"So eve-ng has BOTH layers in play. Access makes the door invisible to the wrong people. The WAF kills obvious attacks at the edge. Defense in depth on a single domain, in a single platform."

TEST 5 — Simulated DDoS → flood + block

for i in {1..200}; do echo -n "$i: "; curl -o /dev/null -s -w "%{http_code}\n" "http://nginx.tarheel.us/echo?blockme=npvenJAo9gMlnd5yD37xQ9P2qp3934"; done

Expected output pattern 1: 404 2: 404 ... 7: 404 8: 403 9: 403 ... 200: 403

First few requests reach your origin (nginx returns 404 because /echo doesn't exist there). Then the rate-limit rule fires and Cloudflare starts blocking with 403 — every request from that point never touches your server.

"Watch what happens. First few requests get through — Cloudflare doesn't block a single request in isolation, because one request could be a real user. But by request 8, Cloudflare has recognized this isn't human behavior — same IP, same URL, hammering the endpoint. From that point forward, every request is blocked at the edge. 403 Forbidden."

"The attacker's laptop is now burning CPU sending traffic that never reaches me. That's the DDoS story in miniature: Cloudflare absorbs it so my origin doesn't have to."

⏸ If somebody asks "why did the first 7 go through?"

"Two reasons. First, rate limiting has to see a rate before it can react — a single request isn't a rate. Second, blocking any request that looks unusual is how you break legitimate users. So the rule is: watch for a pattern, then act. In production this threshold is tuned per-endpoint — login pages get aggressive limits, product pages get looser ones."

▶ Pivot: Domains → tarheel.us → Security → Analytics. Show the DDoS event and the blocks — filter for the blockme query param to isolate this test.

THE ARCHITECTURAL POINT

Same account. Same edge. Same family of attack payloads. Three distinct outcomes — each one the right outcome:

Public + ambiguous → 200 · WAF calibrated to not false-positive on legitimate-looking patterns
Public + unambiguous → 403 · Real attack, real block, no info leaked
Private + ambiguous → 302 · Access intercepts. Attacker can't even reach the app.
Private + unambiguous → 403 · WAF still fires at the edge. Both layers active.

"You can mix and match per domain. Public marketing site doesn't need Access. Private internal tool absolutely does. Right layer, right app, one account, one UI."

5. Infrastructure (Security Center Inventory)

Domain + Proxied

Access Policy

"eve-ng.tarheel.us shows Secured — Access policy in front. That's why our curl got a 302."

"nginx.tarheel.us shows Not Secured — proxied but no Access. For a public site, that's the right design. For an internal tool, it'd be a finding."

"Cloudflare is doing inventory drift detection for me. I didn't have to hunt through twenty Access apps and forty DNS records."

security.txt

6. Brand Protection (Beta)

"Class of attack most security tools just don't cover. Brand Protection watches the public internet for lookalike domains, typo-squats, phishing pages spun up to harvest your customers' credentials."

"How? Cloudflare sees an enormous share of all DNS queries — we run 1.1.1.1, plus resolve traffic for millions of domains. When a brand-new domain registers cloudfIare.com (capital I instead of lowercase L), we see it almost immediately."

"You add brands and keywords. Cloudflare matches against new domains, certificate transparency logs, and live web content. From there: block it for your users via Gateway, or trigger takedown workflows."

7. Turnstile

8. Closing

"This isn't a tour of seven different security products. It's one security platform, sitting in front of every request to your apps, applying every control in a single pass."

"Posture in Security Insights. Decisions in WAF. Forensics in Investigate. APIs and origin in Infrastructure. Lookalike domains in Brand Protection. Form protection in Turnstile."

"DDoS isn't a tab — it's always on. Bot management isn't a tab — it's a signal woven into every WAF rule. That's the architectural difference."

"The question isn't 'can Cloudflare replace my WAF?' It's 'why am I running six tools when one platform sees every request anyway?'"

"Nothing to install. Change your nameservers, traffic flows through Cloudflare, and from that moment on you have all of this. Sign up today, protected today."

Three next-step offers — pick the one that matches the room

Option 1 — Proof of Concept (recommended if they're technical and engaged)

"The best next step is a short proof of concept. We stand up Cloudflare in front of one of your properties — could be a staging environment or a production site running in log-only mode — and let it observe real traffic for a week or two. At the end you see: what would have been blocked, what got through, how many bots, how many attacks, what shape the noise looks like on your infrastructure. No commitment, no billable events, no rip-and-replace. Just data on your own traffic."

"That gives us both something concrete to talk about instead of hypotheticals — and it's the fastest way for you to know whether this is worth doing at scale."

Option 2 — Technical Deep-Dive (if they need to bring more people in)

"If you'd like to bring your security lead, your platform team, or anyone else who'd need to sign off on this into the conversation — happy to run a technical deep-dive next week. We go deeper into whatever piece of this matters most to your environment: WAF tuning, API Shield, Bot Management, integration with your existing SIEM. Live account walkthrough, real questions, no slides."

Option 3 — Architecture Review + Proposal (if they're further along in the process)

"If you already know this is the direction and you're thinking about what a real deployment looks like — I can pull together an architecture review that maps your current stack against what a Cloudflare-fronted environment would look like: which controls consolidate, what stays in place, what gets deprecated. That comes with a sized proposal so you can take a real number to whoever holds the budget."

▶ If nobody bites on any of the three: "Totally fair. Would it be helpful if I sent you a one-pager summarizing what we walked through today, plus a couple of relevant case studies from customers with similar shapes to yours? That way you have something to circulate internally." (Nobody says no to that. It gives you an email thread to keep warm.)

Application Security Demo — Cheat Sheet

Pre-demo setup checklist

Pre-flight (run 30 sec before going live)

0. Opening — Setting the Stage

1. Application Security — Landing Overview

2. Security Insights

3. WAF

Managed Rulesets

Custom Rules

Rate Limiting

Bot signals woven through

4. Investigate + LIVE DEMO (the centerpiece)

The Setup — same attack, two domains

TEST 1 — nginx.tarheel.us (ambiguous SQLi) → 200

TEST 2 — nginx.tarheel.us (UNION SELECT) → 403

TEST 3 — eve-ng.tarheel.us (ambiguous SQLi) → 302

TEST 4 — eve-ng.tarheel.us (UNION SELECT) → 403

TEST 5 — Simulated DDoS → flood + block

5. Infrastructure (Security Center Inventory)

Domain + Proxied

Access Policy

security.txt

Three questions this page answers in seconds

6. Brand Protection (Beta)

7. Turnstile

8. Closing

Three next-step offers — pick the one that matches the room

Q&A — back-pocket answers