Application Security

Combined interactive edition of the four Application Security classes: Cloudflare Setup (AppSec 1), Build and Tune Effective Security Rules (AppSec 2), Bot and Abuse Mitigation (AppSec 3), and Stop Attacks in Real Time (AppSec 4).

Typographical Conventions

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

How to Use This Guide

This is one guide split into four parts, one per Application Security class: Part 1 (Cloudflare Setup), Part 2 (Build and Tune Effective Security Rules), Part 3 (Bot and Abuse Mitigation), and Part 4 (Stop Attacks in Real Time). Lab numbers restart in each part, matching the individual class guides. Work the parts in order; later parts assume the rules and state created by earlier ones.

Why These Labs

AppSec 1 - Cloudflare Setup: From Start to Best Practices

Lab 1: DNS Investigation & Configuration

In this lab, you will diagnose and fix a DNS configuration that exposes an origin server and bypasses Cloudflare's security and performance services.

1.1 Investigate with dig

Compare the A-record response for www with the response for the root domain:

dig A www.<lab-slug>.sxplab.com
dig A <lab-slug>.sxplab.com

Record the returned IP addresses and query times.

1.2 Fix the Exposed DNS Record

In the Cloudflare dashboard, select your lab domain.

Go to DNS > Records.

Find the www record.

Change Proxy status from DNS Only to Proxied.

Run the two lookups again and confirm that www now returns Cloudflare addresses.

Lab 2: SSL/TLS Configuration

In this lab, you will observe how Full (Strict) protects the connection to the origin, then restore the lab's required state.

2.1 Induce the SSL Error

Go to SSL/TLS > Overview.

Open Configure encryption mode if the encryption-mode options are not already visible.

Change the mode from Full to Full (Strict).

Open your lab domain in another tab.

Record the Cloudflare error code that appears. The published lab currently expects 525: SSL handshake failed.

2.2 Restore the Lab State

Return to SSL/TLS > Overview.

Change the mode back to Full.

Confirm that the site loads.

Lab 3: Verifying Traffic in Analytics

3.1 Find the Error in Analytics

Go to Analytics > HTTP Traffic.

Add an Edge status code filter for the code you recorded in Lab 2. The published scenario expects 525; use 526 if that is what your lab origin produced.

Confirm that you can find the error generated in Lab 2.

Adjust the time range if the request is not immediately visible.

Lab 4: Enabling the Web Application Firewall (WAF)

4.1 Enable and Verify the Cloudflare Managed Ruleset

Go to Security > Settings.

Filter the settings for Web application exploits.

Turn on Cloudflare managed ruleset.

Go to Security > Analytics > Events.

Find the pre-existing local-file-inclusion scanner traffic and inspect the action Cloudflare took.

4.2 Deploy OWASP Safely

Return to Security > Settings and turn on OWASP Core.

Select View ruleset.

Configure Paranoia Level 1 with Action = Log.

Save the configuration.

4.3 Test the Logging Rule

Run this simulated SQL-injection request against your assigned domain:

curl "https://<lab-slug>.sxplab.com/?id=1'%20OR%20'1'='1'"

Return to Security > Analytics > Events, find the request, and confirm that its action is Log. Inspect the matched rule and anomaly-score details. If the event is not visible, check the request, time range, ruleset configuration, and threshold.

Appendix: Lab Command Reference

The dig commands used in this class, for quick reference:

dig A www.<lab-slug>.sxplab.com
dig A <lab-slug>.sxplab.com
dig NS <lab-slug>.sxplab.com

AppSec 2 - Build and Tune Effective Security Rules

You are a security engineer at AcmeCorp. You will investigate suspected scraping, build a mitigation, resolve a rule conflict, and tune the rules without blocking legitimate users.

Lab 1: Assess - The Threat Hunt

1.1 Investigate the Traffic

Go to Security > Analytics > Traffic.

Use Add filter to investigate source ASN, URI path, user agent, and status code.

Look for high-volume traffic from one non-residential network targeting /services/.

Confirm that the requests return 200, indicating that content is being served.

Record the suspected scraper ASN for Lab 2.

Lab 2: Build - The First Attempt

2.1 Create the Block Rule

Go to Security > Security rules > Custom rules.

Select Create rule.

Configure the rule:

• Rule name: BLOCK - Scraping ASN
• Field: ASN
• Operator: equals
• Value: the ASN identified in Lab 1
• Action: Block

Deploy the rule.

Lab 3: Test - The Rule Conflict Puzzle

3.1 Check the Result

Go to Security > Analytics > Events.

Filter for BLOCK - Scraping ASN.

Inspect whether the target scraper traffic is being blocked.

Return to Security > Security rules > Custom rules and read the rules from top to bottom.

Identify BYPASS - Main Customer Geo above your new rule. Its Skip action catches the scraper's geography before the Block rule can evaluate it.

3.2 Fix the Order

Move BLOCK - Scraping ASN to position 1, above BYPASS - Main Customer Geo.

Return to Security > Analytics > Events.

Confirm that your rule now blocks the target traffic.

Lab 4: Tune - The False Positive (Part 1)

4.1 Switch to Log

Edit BLOCK - Scraping ASN.

Change Action from Block to Log.

Rename it LOG - Scraping ASN.

Save the rule.

4.2 Compare the Traffic

Go to Security > Analytics > Events and filter for the logging rule.

Compare the user agents:

• Suspected scraper: python-requests
• Legitimate VPN user: normal browser user agent

4.3 Refine the Rule

Edit the rule and require both conditions:

(ip.src.asn eq <SCRAPER_ASN>) and (http.user_agent eq "python-requests")

Review representative Log matches before enforcement.

Rename the rule BLOCK - Scraping ASN+UA.

Change Action to Block and deploy it.

Lab 5: Tune - The False Positive (Part 2)

The trusted site monitor uses the same ASN and user agent as the scraper but has a known static source address.

5.1 Create the Trusted-Service List

Go to Manage account > Configurations > Lists.

Create an IP list named site_monitor_ips.

Add 34.83.115.243.

Save the list.

5.2 Create the Skip Rule

Return to the lab domain and go to Security > Security rules > Custom rules.

Create BYPASS - Site Monitor IP.

Use this expression:

(ip.src in $site_monitor_ips)

Select Skip and include All remaining custom rules.

Deploy the rule and move it to position 1.

Keep BLOCK - Scraping ASN+UA in position 2.

Lab 6: Tune - Rule Set Hygiene

6.1 Fix the Over-Broad Rule

Find BLOCK - RU Android 5.0 in Custom rules.

Its OR condition blocks all Russian traffic and all Android 5 users globally.

Change OR to AND so both intended conditions must be true:

(ip.geoip.country eq "RU") and (http.user_agent contains "Android 5.")

Save the rule.

Review the remaining rules for other logic that is broader than the AcmeCorp requirements.

Lab 7: Proactive Security - Rate Limiting

7.1 Rate-Limit the Contact Form

Go to Security > Security rules > Advanced rate limiting rules.

Create a rule with these settings:

• Rule name: Protect - Contact Form
• URI path: equals /contact
• Rate: 10 requests in 2 minutes
• Counting characteristic: IP address
• Action: Managed Challenge

Deploy the rule and monitor its events for intended and unintended matches.

Appendix: Lab Reference

AppSec 3 - Bot and Abuse Mitigation

You are a security engineer at AcmeCorp. A distributed credential-stuffing attack is targeting the admin login. You will enable bot signals, investigate the traffic, deploy a broad first mitigation, test its rule order, correct a mobile-app false positive, and add rate-based defenses.

Exercise Starting State

The AppSec 3 lab environment is provisioned with a planned starting state. It uses the following Custom rules:

The credential-stuffer traffic is US-origin, targets /admin and /v1/login, has bot score 1, produces 401 responses, and carries leaked-credential signals. The legitimate mobile app uses AcmeCorp-Mobile/2.1.0, targets /v1/orders, and also has bot score 1.

Lab 1: Establishing Baseline Protections

1.1 Verify Leaked-Credential Detection

Go to Security > Settings.

Open the Fraud group.

Verify that Leaked credentials detection is on.

1.2 Enable JavaScript Detections and Model Updates

In Security > Settings, open the Bot traffic group.

Enable JavaScript Detections.

Verify that automatic Bot Management model updates are on.

1.3 Manage a Verified Crawler

Open AI Crawl Control from the domain sidebar.

Open the Security tab.

Find the Crawlers table.

Review the verified crawlers.

Set a non-essential search crawler to Block for this exercise.

Lab 2: Assess - The Threat Hunt

2.1 Investigate the Login Traffic

Go to Security > Analytics > Traffic.

Filter URI path to /admin.

Analyze the filtered data for these signals:

• Bot score 1 or other low scores
• Repetitive login behavior
• Leaked-credential signals, when exposed in the lab account
• 401 Unauthorized responses

Confirm that the combined evidence is consistent with credential stuffing.

Lab 3: Build - The First Mitigation

3.1 Create the Broad Challenge Rule

Go to Security > Security rules > Custom rules.

Create a rule with these settings:

• Rule name: CHALLENGE - low bot score
• Expression: (cf.bot_management.score eq 1)
• Action: Managed Challenge

Deploy the rule at the bottom of the Custom rules list.

Lab 4: Test - Verify the Rule

This lab adds a rule-order conflict to work through.

4.1 Trace and Fix the Order

Go to Security > Analytics > Events and filter for CHALLENGE - low bot score.

Observe that the new rule is not handling all target traffic.

Open Account > Observe > Investigate > Trace.

Trace a bot-score-1 request from the US.

Confirm that BYPASS - Main Customer Geo skips the request before the bottom-position challenge rule can run.

Return to Custom rules.

Move CHALLENGE - low bot score to position 2, immediately below BYPASS - Site Monitor IP.

Redeploy and confirm in Events that the challenge now fires.

Lab 5: Tune - The False Positive

The broad rule also challenges AcmeCorp's legitimate mobile application.

5.1 Identify the False Positive

Go to Security > Analytics > Events.

Filter for events from CHALLENGE - low bot score.

Find the legitimate traffic with both characteristics:

• User agent: AcmeCorp-Mobile/2.1.0
• URI path: /v1/orders

Confirm that this is wanted automated traffic and therefore a false positive.

Lab 6: Advanced Tuning and Mitigation

6.1 Refine the Custom Rule

Edit CHALLENGE - low bot score.

Change the expression to:

(cf.bot_management.score eq 1) and (http.request.uri.path eq "/admin")

Rename the rule CHALLENGE - Admin Credential Stuffing.

Save it in position 2.

Confirm that /admin bot traffic remains challenged and /v1/orders mobile-app traffic no longer matches.

6.2 Create a Leaked-Credential Rate Limit

Go to Security > Security rules > Advanced rate limiting rules.

Create a rule with these settings:

• Rule name: ARL - Leaked Credential Attempts
• Traffic match: leaked-credential signal
• Rate: 3 requests in 1 minute
• Counting characteristic: JA4 fingerprint
• Action: Block

Deploy the rule.

6.3 Protect the Orders API

Create another Advanced Rate Limiting rule with these settings:

• Rule name: ARL - API Scraping
• Expression: (http.request.uri.path eq "/v1/orders") and (cf.bot_management.score eq 1)
• Rate: 10 requests in 1 minute
• Counting characteristic: JA4 fingerprint
• Action: Block

Deploy the rule.

Expected End State

The tuned Custom rule is CHALLENGE - Admin Credential Stuffing in position 2. The two new Advanced Rate Limiting rules are ARL - Leaked Credential Attempts and ARL - API Scraping. The other preloaded rules remain in place.

AppSec 4 - Stop Attacks in Real Time

You are a security administrator for AcmeCorp, and the site is under an active application-layer attack.

The Incident Response Framework

Use this framework throughout the exercise:

1. Assess: Understand what is happening.
2. Define: Identify the threat and security gap.
3. Respond: Deploy a precise mitigation.
4. Evaluate: Verify the result and check legitimate-user impact.

Lab 1: Assess - Initial Triage

1.1 Observe the Blunt Control

Open the lab domain's Overview page.

Enable Under Attack Mode.

Refresh the lab site and observe the challenge applied broadly to visitors.

Disable Under Attack Mode immediately.

1.2 Investigate the Traffic

Go to Security > Analytics > Traffic.

Use Add filter to investigate these signals:

• URI path /search
• 503 Service Unavailable responses
• Source ASN
• JA3 or JA4 fingerprints
• User agent

Confirm a large traffic spike concentrated on /search with increased 503 responses and concentrated source characteristics.

Lab 2: Define - The Threat and The Gap

2.1 Define the Attack

Classify the incident as application abuse intended to impact service. The clients repeatedly invoke the compute-intensive search function rather than sending an undirected network flood.

2.2 Audit the Existing Defense

Go to Security > Security rules > Advanced rate limiting rules.

Open Block high rate of requests.

Confirm that it targets the search path.

Inspect the threshold. The planted starting value is 200 requests in 1 minute, which is too high to protect the lab application's search function effectively.

Lab 3: Respond - Tune the Mitigation

3.1 Determine a Data-Driven Threshold

Return to Security > Analytics > Traffic.

Keep the analysis focused on /search.

Open Request rate analysis.

Use the graph and slider to identify the maximum one-minute request rate for clients that are not attacking the endpoint.

Select a threshold above the observed non-attacking clients and below the abusive clients. Do not assume one fixed threshold fits another application.

3.2 Update the Existing Rule

Return to Security > Security rules > Advanced rate limiting rules.

Edit Block high rate of requests.

Keep the rule targeted to /search.

Set the one-minute threshold to the value derived from Request rate analysis.

Change the action from Block to Managed Challenge.

Extend the mitigation timeout so clients that exceed the rate remain challenged for an appropriate period.

Save the rule.

Lab 4: Evaluate & Activate

4.1 Confirm the Result in Analytics

Return to Security > Analytics > Traffic.

Compare the periods before and after the rule update.

Confirm that abusive /search traffic and 503 responses decrease.

Test normal search behavior in the lab application.

4.2 Test the Rate Limit

Run the loop against your assigned domain:

for i in {1..100}; do
  curl -so /dev/null -w "${i} - %{http_code}\n" \
    "https://<lab-slug>.sxplab.com/search/?q=testing"
done

Observe when the response changes after the configured rate is exceeded. Confirm the corresponding mitigation events rather than relying only on terminal status codes.

4.3 Evaluate Events and Client Solve Rate

Go to Security > Security rules > Advanced rate limiting rules.

Use the rule's Events link or graph to open Security > Analytics > Events filtered to the rule.

Inspect when and how often the rule acted.

Review the rule's Client Solve Rate (CSR).

4.4 Tune and Prepare

Discuss how an attacker might distribute requests across more clients or move to another expensive endpoint. Record those hypotheses before changing controls.

As a proactive follow-up, go to Manage account > Notifications.

Select Add.

Review the available security and traffic notifications for the account.

Configure an appropriate notification if the lab account permits it.

Exercise State

No new Custom rule, Internal Health Monitor exception, or WAF Trace step is used.

Resources

Reference material for all four classes. External links open Cloudflare documentation in a new tab.

End of Lab Guide.