Phase 3 — Mitigate

Phase 3 creates a before/after proof of CSD mitigation. You re-run the attack with no mitigations to establish a baseline, apply mitigations, then re-run the same attack to prove CSD blocks the network calls. Phase 2 must be complete — all DET checks PASS — before proceeding.

Note

CSD mitigation blocks script loading from mitigated domains. When a domain is on the mitigate list, the CSD JavaScript intercepts <script> tag source URLs and prevents scripts from loading — stopping supply-chain attacks at the source. CSD does not intercept fetch() or XMLHttpRequest calls. This phase captures proof of script blocking by running the same attack before and after mitigation.

Caution

Live testing note: The mitigation POST/DELETE endpoints have been validated in development environments but behavior details (response timing, effect on script detection status) may vary across tenant configurations. If you observe unexpected responses, check the API Reference for the canonical endpoint definitions.

Step 1: Confirm No Active Mitigations (Baseline)

Before capturing the “before” snapshot, verify the environment is clean — no mitigations should be active. This ensures the baseline attack runs without any CSD blocking.

Check Mitigated Domains Count

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq '{count: (.items | length)}'

If the count is not 0, mitigations remain from a prior run. Delete each one before proceeding:

# Delete a mitigated domain (repeat for each domain name)
curl -s -X DELETE \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains/<domain-name>" \
  | jq .

Replace <domain-name> with the metadata.name used when the domain was mitigated (e.g., cdn.jsdelivr.net, esm.sh, unpkg.com, ga.jspm.io, httpbin.org, jsonplaceholder.typicode.com). If httpbin.org cleanup leaves a remaining item, also try deleting www.httpbin.org — some prior runs may have used that as the metadata name.

Confirm Phase 2 Detections Are Present

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/detected_domains" \
  | jq '{total_domains: .domain_summary.totalDomains, domains: [.domains_list[]? | {domain: .domain, category: .category}]}'

Evidence

Check	Expected	Status
Mitigated domain count	0 (clean baseline)	PASS if 0, requires cleanup if > 0
Detected domain count	> 0 (Phase 2 detections present)	PASS if > 0
Exfil domains present	www.httpbin.org, jsonplaceholder.typicode.com	PASS if at least one appears

Step 2: Run Attack — Before Mitigation

Re-run the combined simulation with no mitigations active to capture a fresh baseline. This is the “before” snapshot — proof that attacks succeed when CSD mitigation is not applied.

Note

This step requires browser-side JavaScript execution — curl cannot trigger CSD detection. AI assistants with browser automation tools (MCP Chrome DevTools, Playwright, Puppeteer) execute these steps directly using the AI-Automated Execution sequence below. Operators without browser automation perform the manual steps.

AI-Automated Execution

AI assistants with browser automation tools run the attack simulation programmatically using the same Phase 2 initScript (which saves native fetch):

1. Navigate with initScript — first navigate to about:blank to ensure a clean document context (avoids stale initScripts from prior navigations), then navigate_page to http://$F5XC_DOMAINNAME/#/login with the Phase 2 initScript (verbatim code in Phase 2 — AI-Automated Execution). This initScript saves native setInterval, clearInterval, fetch, and console.log — the native fetch reference is correct here because no mitigations are active
2. Dismiss Welcome Banner — press_key with Escape to close the Welcome Banner. On subsequent visits the banner may not appear (cookies persisted). The cookie consent dialog is dismissed automatically by the Escape key
3. Wait for completion — wait 10 seconds for all CDN script load/error callbacks and fetch promise resolutions to complete
4. Capture evidence — list_console_messages to check for [CSD Demo] Simulation complete and CDN load results; list_network_requests filtered to script and fetch types to verify HTTP status codes (200/201 for success)

Caution

zone.js incompatibility — Juice Shop uses Angular’s zone.js, which patches setTimeout, setInterval, fetch, XMLHttpRequest, and other browser APIs. This breaks the MCP evaluate_script, fill, and click tools with Cannot read properties of undefined (reading 'call'). Use navigate_page with initScript instead — initScript runs before zone.js loads, so you can save native API references and use them in polling callbacks. The initScript must fill form fields using the native HTMLInputElement.prototype.value setter (not fill) and run the detection script inline (not via setTimeout, which zone.js may intercept after page load). See Trigger Detection — AI-Automated Execution for details.

Note

initScript accumulation — each navigate_page call with an initScript parameter adds the script to a persistent list that runs on every subsequent document load. To avoid stale scripts interfering, either navigate to about:blank between runs or use new_page with isolatedContext for a clean browser context.

Manual Execution

Operators without browser automation tools run the simulation manually using the same procedure as Phase 2 — Step 8: Attack Simulation:

1. Navigate to http://xF5XC_DOMAINNAMEx/#/login
2. Enter dummy credentials in the Email and Password fields (do not submit)
3. Open DevTools — press F12 and switch to the Console tab
4. Paste and run the Combined Detection Script from Trigger Detection
5. Observe console output — all CDN scripts should load and exfil calls should succeed with 200/201 responses

Evidence — Before Mitigation

Check	Expected (Before Mitigation)	Status
CDN scripts injected	All 4 script tags load — [Supply Chain] Loaded from messages appear, network tab shows 200	PASS
Exfil fetch to www.httpbin.org	Network tab shows 200 — data sent	PASS
Exfil fetch to jsonplaceholder.typicode.com	Network tab shows 201 — data sent	PASS
Console output	[CSD Demo] Simulation complete	PASS

Note

Verifying with network requests: The most reliable evidence is the Network tab (or list_network_requests for AI assistants), not console callbacks. Zone.js in Juice Shop can break promise .then() callbacks and script onload handlers, causing console messages to be incomplete even when network requests succeed. Always cross-reference console output with network request status codes.

Tip

This is the baseline proof: with no mitigations active, the attacker’s scripts load freely and data exfiltration succeeds. Save or screenshot this evidence — you will compare it directly against the “after” results in Step 5.

Step 3: Apply Mitigations

For each detected domain, POST to the mitigated domains endpoint. The primary targets from the Phase 2 simulation are the 4 CDN injection domains and any data exfiltration domains detected.

Primary mitigation targets (from the combined simulation script):

Domain	Role
cdn.jsdelivr.net	CDN script injection
esm.sh	CDN script injection
unpkg.com	CDN script injection
ga.jspm.io	CDN script injection
www.httpbin.org	Data exfiltration endpoint
jsonplaceholder.typicode.com	Data exfiltration endpoint

Note

The POST body requires both metadata.name (the identifier for the object) and spec.mitigated_domain (the domain string CSD will classify). Both must be set — spec: {} causes a 400 error. For most domains, both fields use the same value (e.g., cdn.jsdelivr.net). See the httpbin.org exception below.

Mitigate a domain (run once per domain):

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "cdn.jsdelivr.net",
      "namespace": "xF5XC_NAMESPACEx"
    },
    "spec": {
      "mitigated_domain": "cdn.jsdelivr.net"
    }
  }' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

Repeat for each domain:

esm.sh

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"esm.sh","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"esm.sh"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# unpkg.com
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"unpkg.com","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"unpkg.com"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# ga.jspm.io
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"ga.jspm.io","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"ga.jspm.io"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# httpbin.org — use www.httpbin.org as mitigated_domain (see note below)
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"httpbin.org","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"www.httpbin.org"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

# jsonplaceholder.typicode.com
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"jsonplaceholder.typicode.com","namespace":"xF5XC_NAMESPACEx"},"spec":{"mitigated_domain":"jsonplaceholder.typicode.com"}}' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq .

Note

httpbin.org eTLD+1 constraint: The API rejects bare eTLD+1 domains as mitigated_domain values with "Invalid root domain: cannot derive eTLD+1". Use www.httpbin.org as the spec.mitigated_domain value while keeping httpbin.org as metadata.name. The mitigation is applied correctly — the name identifier is what appears in the mitigated domains list. Any bare domain (no subdomain) used as an exfil target in a custom simulation script will have the same constraint.

A 200 response returns the created mitigated domain object. A 409 response means the domain is already in the mitigated list — this is a success condition.

Step 4: Verify Mitigations Applied

List all mitigated domains and confirm the count matches the number of domains just submitted:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/mitigated_domains" \
  | jq '{count: (.items | length)}'

Note

The mitigated domains list endpoint returns items with null metadata.name for ALL items — individual domain names are not visible in the list response. Verify by checking that the item count equals the number of POST requests made (6 for the standard simulation). The 200 response from each individual POST in Step 3 is the authoritative evidence that each mitigation was created. If the count is 1 with a null-name item and no mitigations were applied, treat the count as 0 — this is a backend artifact (see Pre-flight Check for the decision rule).

Evidence

Check	Expected	Status
Mitigated domain count	6 (matches POST count)	PASS if count matches
All Step 3 POSTs returned 200 or 409	Each domain accepted	PASS

If the count is lower than expected, re-run the POST command for the missing domain from Step 3.

Step 5: Run Attack — After Mitigation

Re-run the exact same combined simulation to capture the “after” snapshot. The simulation script is identical — only CSD’s mitigation state has changed. Script loads from mitigated domains are now blocked by the CSD JavaScript (the <script> tag src is cleared to an empty string).

Note

This step uses the same browser automation sequence as Step 2. The difference is not in what you run — it’s in what you observe. With mitigations active, CSD blocks <script> tag loads from mitigated domains. Fetch API calls to mitigated exfil domains still complete — CSD mitigation targets script loading, not fetch/XHR.

AI-Automated Execution

AI assistants with browser automation tools re-run the attack simulation programmatically using the same Phase 2 initScript (verbatim code in Phase 2 — AI-Automated Execution). The initScript saves native fetch to avoid zone.js errors — this does not affect CSD mitigation because CSD does not intercept fetch() calls.

1. Navigate with initScript — use new_page with isolatedContext for a clean browser context (avoids stale initScripts from Step 2), then navigate to about:blank, then to the login page with the Phase 2 initScript
2. Dismiss Welcome Banner — press_key with Escape
3. Wait for completion — wait 10 seconds for all async callbacks
4. Capture evidence — list_console_messages to check for [CSD Demo] Simulation complete; list_network_requests filtered to script and fetch types to observe that CDN script loads are absent (CSD cleared the script src) while fetch calls to exfil domains still complete normally

Manual Execution

Operators without browser automation tools re-run the simulation manually using the same procedure as Phase 2 — Step 8: Attack Simulation:

1. Navigate to http://xF5XC_DOMAINNAMEx/#/login
2. Enter dummy credentials in the Email and Password fields (do not submit)
3. Open DevTools — press F12 and switch to the Console tab
4. Paste and run the Combined Detection Script from Trigger Detection
5. Observe console and network output — CDN script onload and onerror callbacks do not fire for mitigated domains (CSD cleared the script src to an empty string, preventing the network request entirely). Fetch calls to exfil domains (www.httpbin.org, jsonplaceholder.typicode.com) still complete with 200/201 — CSD mitigation blocks script loading, not fetch/XHR calls

Mitigation propagation timing

The CSD JavaScript is expected to block script loading from mitigated domains by intercepting the <script> tag src setter. However, in testing over HTTP (port 80), script src clearing was not observed within 5 minutes of applying mitigations — all CDN scripts continued to load normally. This may indicate that mitigation propagation requires more than 5 minutes, or that the mechanism behaves differently over HTTP vs HTTPS. If mitigation blocking is not observed, allow additional propagation time and verify the CSD telemetry script has refreshed its configuration.

Fetch calls are not intercepted by CSD mitigation (verified). Exfil fetch calls to mitigated domains (www.httpbin.org, jsonplaceholder.typicode.com) still complete normally with 200/201 responses, both before and after mitigation. CSD mitigation targets the supply-chain vector (malicious script loading), not data exfiltration via fetch/XHR. Use the same Phase 2 initScript (with native fetch saved) for both Step 2 and Step 5.

Evidence — After Mitigation

Check	Expected (After Mitigation)	Status
CDN script loads	Blocked — scripts do not appear in network tab (CSD cleared src to empty string)	PASS
CDN script callbacks	Neither onload nor onerror fires for mitigated domains	PASS
Exfil fetch to www.httpbin.org	200 — fetch still completes (CSD does not intercept fetch)	INFO
Exfil fetch to jsonplaceholder.typicode.com	201 — fetch still completes (CSD does not intercept fetch)	INFO
Console output	[CSD Demo] Simulation complete	PASS

Tip

Backend verification is the most reliable proof. If browser-visible script blocking is not observed within the demo timeframe, use the /detected_domains API response as primary evidence. The mitigatedDomains count and reduced actionNeededCount in the domain summary confirm that mitigations are active in the backend — even if the CSD JavaScript in the browser hasn’t yet refreshed its configuration to enforce blocking.

Step 6: Before vs After Comparison

This is the demo payoff — side-by-side evidence proving that the same attack, on the same page, with the same script, now produces a completely different result.

Comparison Table

Signal	Before Mitigation (Step 2)	After Mitigation (Step 5)
CDN script loads	200 — all 4 CDN scripts load normally	Blocked — scripts absent from network tab (CSD cleared src to empty string)
CDN onload callbacks	[Supply Chain] Loaded from messages appear	No callbacks fire (no network request was made)
Exfil to www.httpbin.org	200 — data exfiltrated	200 — fetch still completes (CSD does not intercept fetch)
Exfil to jsonplaceholder.typicode.com	201 — data exfiltrated	201 — fetch still completes (CSD does not intercept fetch)
CSD mitigated domains API	0 mitigated	6 mitigated

Verify Mitigation in Backend Data

Query /detected_domains every 60 seconds for up to 10 iterations (10 minutes). Proceed to the comparison table once the query returns, or after the 10-minute maximum — these checks are informational and do not gate Phase 4.

Check Detected Domains Post-Mitigation:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/detected_domains" \
  | jq '{total_domains: .domain_summary.totalDomains, domains: [.domains_list[]? | {domain: .domain, category: .category}]}'

Check Scripts for Mitigated Status:

NOW=$(date +%s)
START=$(( NOW - 86400 ))
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d "{\"startTime\": \"$START\", \"endTime\": \"$NOW\"}" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/scripts" \
  | jq '{total: (.scripts | length), scripts: [.scripts[]? | {script_name: .script_name, risk_level: .risk_level}]}'

Phase 3 Evidence Summary

Check	Expected	Status
Baseline clean (Step 1)	0 mitigated domains at start	PASS / FAIL
Before — attack succeeds (Step 2)	Scripts load, exfil returns 200/201	PASS / FAIL
Mitigations applied (Step 3)	All 6 domains accepted via POST (200 or 409)	PASS / FAIL
Mitigated count confirmed (Step 4)	6 items in list	PASS / FAIL
After — script loads blocked (Step 5)	CDN scripts absent from network tab, fetch calls still complete	PASS / FAIL
Before vs After comparison (Step 6)	Clear difference between Step 2 and Step 5 evidence	PASS / FAIL

Note

Detection status updates after mitigation may take time to appear in the API response. If the domains still show “Action Needed” immediately after mitigation, query /detected_domains every 60 seconds for up to 10 iterations (10 minutes). If still not updated after 10 iterations, record the current state as INFO — this does not block Phase 4.

---

Phase 3 complete. Proceed to Phase 4 — Teardown when you are ready to remove all deployment objects.