Third-party lifecycle

This Azure alternate scenario proves the full Client-Side Defense lifecycle with one behaving third-party script. It is separate from the AWS Juice Shop reference deployment. The webapp-api-protection repository owns the Azure application, its F5 Distributed Cloud configuration, and the optional mitigated-domain resource. The separately deployed cdn-simulator repository owns the edge that serves /csd-demo/checkout.js. The script reads synthetic payment fields, so CSD inventories the edge host as a High Risk third-party domain.

The csd_cdn_simulator_host Terraform value passes the cdn-simulator repository’s edge_fqdn output into the webapp-api-protection deployment as both the page’s script host and the mitigation target. Each Azure repository retains its own Terraform backend and state. Its owner must create, review, and apply the exact saved plan from that repository; do not copy resources between states, recompute an approved apply, or manage either repository’s resources through terraform/aws or the standalone CSD API workflow. Matching the script host to the mitigation target produced repeatable detect, mitigate, and block results in this lab, but classification and processing time remain tenant-dependent. Use an FQDN, not a raw IP.

注意

This Azure scenario uses synthetic values against the authorized F5 demo application. For the AWS Juice Shop reference deployment and its mutually exclusive API or Terraform ownership modes, use the other demo pages. Choose one ownership mode. Never run the API create/update/delete workflow against resources present in Terraform state.

Prerequisites

• Deployed webapp-api-protection and cdn-simulator plans. The simulator must origin-pull the web application’s origin.
• csd_cdn_simulator_host set to the simulator’s edge_fqdn output.
• A real-client workstation with Google Chrome, Node.js, and current checkouts of webapp-api-protection and traffic-generator.
• XCSH_API_URL and XCSH_API_TOKEN available through the approved credential store.
• The web application Terraform backend and Azure authentication configured as described in its Terraform README.

Export paths and deployment-specific hostnames:

export LB_FQDN="<protected-application-fqdn>"
export CSD_CDN_HOST="<cdn-simulator-edge-fqdn>"
export WEBAPP_REPO="<path-to-webapp-api-protection-checkout>"
export TRAFFIC_REPO="<path-to-traffic-generator-checkout>"

Phase 1: Build and validate the topology

Verify that the edge FQDN resolves, the edge serves the skimmer, and the checkout HTML references the exact same host:

dig +short "$CSD_CDN_HOST"
curl --fail --silent --output /dev/null \
  "http://$CSD_CDN_HOST/csd-demo/checkout.js"
curl --fail --silent "http://$LB_FQDN/csd-demo/" \
  | grep --fixed-strings "http://$CSD_CDN_HOST/csd-demo/checkout.js"

All three checks must succeed before generating traffic. A host mismatch prevents the CSD mitigated-domain object from controlling the script that the browser loads.

Phase 2: Drive the population and verify detection

CSD requires multiple distinct real-browser fingerprints for this scenario. Prepare Playwright in a temporary directory, record the population epoch, and drive eight headed Chrome sessions:

PLAYWRIGHT_DIR=$(mktemp -d)
npm install --prefix "$PLAYWRIGHT_DIR" playwright-core
export SINCE_EPOCH=$(date +%s)

HEADFUL=1 \
SESSIONS=8 \
EXPECT_SCRIPT=loaded \
EXPECTED_SCRIPT_URL="http://$CSD_CDN_HOST/csd-demo/checkout.js" \
NODE_PATH="$PLAYWRIGHT_DIR/node_modules" \
node "$TRAFFIC_REPO/suites/csd-detection/02-population-detection.js" "$LB_FQDN"

Require classification=loaded, passed=true, sensorCount=8, and eventBeaconCount=8. Headless traffic or one reused browser context can exercise sensor liveness, but does not satisfy the population gate.

Next, require fresh evidence for the exact edge FQDN:

EXPECTED_DOMAIN="$CSD_CDN_HOST" \
SINCE_EPOCH="$SINCE_EPOCH" \
VERIFY_PHASE=detection \
POLL_MIN=30 \
"$WEBAPP_REPO/scripts/csd-verify.sh"

Exit 0 proves that the domain appears in both domain and script telemetry, the script is High Risk, its timestamp is no older than this population, and at least one affected user exists. Exit 3 means aggregation is healthy but pending; do not mitigate yet. Exit 2 identifies a configuration, authentication, or dataplane failure that must be repaired before continuing.

Phase 3: Mitigate and prove blocking

Continue only after the detection verifier exits 0. In the webapp-api-protection/terraform directory, have that deployment’s owner create and inspect a complete saved plan. Do not use -target; an independently recomputed targeted apply is not the reviewed change:

terraform plan \
  -var=csd_demo_mitigation_enabled=true \
  -out=csd-mitigation-enable.tfplan
terraform show csd-mitigation-enable.tfplan
terraform apply csd-mitigation-enable.tfplan

Apply only those reviewed saved-plan bytes against the same backend and state. Any unrelated action, replacement, provider error, or change to the separately owned simulator blocks the apply.

This creates block-cdn-simulator for the host supplied by csd_cdn_simulator_host; it does not maintain a second domain list. After propagation, run the same population with only the expected outcome changed:

HEADFUL=1 \
SESSIONS=8 \
EXPECT_SCRIPT=blocked \
EXPECTED_SCRIPT_URL="http://$CSD_CDN_HOST/csd-demo/checkout.js" \
NODE_PATH="$PLAYWRIGHT_DIR/node_modules" \
node "$TRAFFIC_REPO/suites/csd-detection/02-population-detection.js" "$LB_FQDN"

Require classification=blocked, passed=true, and blocked=8. Retain the original detection epoch and verify the backend state:

EXPECTED_DOMAIN="$CSD_CDN_HOST" \
SINCE_EPOCH="$SINCE_EPOCH" \
VERIFY_PHASE=mitigation \
POLL_MIN=30 \
"$WEBAPP_REPO/scripts/csd-verify.sh"

Exit 0 requires the exact mitigated domain plus either a positive blocked_scripts counter or a blocked action on the fresh High Risk script. Browser blocking and telemetry are both required for the before-and-after proof.

Phase 4: Remove the mitigation and prove restoration

The webapp-api-protection owner first removes only its demo mitigation. In that repository’s terraform directory, create and inspect a complete saved plan with the false toggle. Do not use -target or run a newly recomputed apply after review:

terraform plan \
  -var=csd_demo_mitigation_enabled=false \
  -out=csd-mitigation-disable.tfplan
terraform show csd-mitigation-disable.tfplan
terraform apply csd-mitigation-disable.tfplan

Apply only those reviewed saved-plan bytes against the same backend and state.

After propagation, prove restoration with one fresh headed browser session:

HEADFUL=1 \
SESSIONS=1 \
EXPECT_SCRIPT=loaded \
EXPECTED_SCRIPT_URL="http://$CSD_CDN_HOST/csd-demo/checkout.js" \
NODE_PATH="$PLAYWRIGHT_DIR/node_modules" \
node "$TRAFFIC_REPO/suites/csd-detection/02-population-detection.js" "$LB_FQDN"

Require classification=loaded, passed=true, loaded=1, and blocked=0. These are lab-observed classifications from the current tenant, not guaranteed timing or classification in another tenant. Then require the webapp-api-protection owner to run a full refresh-aware plan against the same backend and state; exit code 0 with no changes is the restoration gate:

terraform plan -detailed-exitcode -out=csd-restoration-check.tfplan

Exit code 2 means restoration is incomplete: inspect the saved plan, correct the owning configuration or runtime condition, and repeat the saved-plan review and apply workflow. For broader cleanup, obtain explicit approval and use each Azure repository’s owner-specific teardown procedure: the webapp-api-protection owner destroys only its state, and the cdn-simulator owner separately destroys only its state. Do not use this repository’s terraform/aws stack, Phase 4 API teardown, or any standalone API DELETE operation for these Azure-owned resources.

Remove the temporary dependency directory when the exercise is complete:

rm -rf "$PLAYWRIGHT_DIR"