Custom Rules¶

Escape's built-in tests cover the bulk of the OWASP API and OWASP Web Top 10 out of the box. Custom rules let you encode the security checks specific to your product — business-logic violations, internal naming conventions, deprecated routes, environment isolation — using a deterministic YAML DSL.

There are two flavors:

• API custom rules (type: API) target REST and GraphQL APIs. They can seed requests, replay them through transformations, run matchers on the request and response, and extract values for re-injection.
• WebApp custom rules (type: WEBAPP) drive a real Playwright-controlled browser against your web application. They can perform browser actions (navigate, fill, click, complete TOTP / magic-link MFA), then assert against the rendered DOM, cookies, storage, and dialog popups.

What you can express on each surface¶

Where custom rules run¶

Custom rules are attached to a scan through the Escape platform and then picked up by whichever scanner executes your scan. Which rules actually fire depends on three things:

1. The scan kind (DAST, AI Pentesting, ASM — and what target type it runs against: API vs WebApp).

2. The rule type you authored (type: API or type: WEBAPP).

3. For API rules, the shape of the rule — rules are classified at runtime into one of three execution subtypes, each driven by a different component of the scanner:

   API rule shape	Subtype	Where it runs
   Has seed:	SEED	apicustomrulesseed task — sends the seeded request, runs detect
   Has transform:	COMPLEX	blstcheck-customrules — replays mutated requests through BLST
   Neither (detector-only)	FILTER_ONLY	APICustomRulesFilter — matches passively on observed traffic

WebApp rules (type: WEBAPP) always run the same way: the Visage browser engine executes the seed: actions and then evaluates detect.

The matrix below summarises, per scan kind, which rule types and subtypes actually execute today.

How a rule flows¶

flowchart LR
  Author[YAML rule] --> Surface{type}
  Surface -->|API| ApiPipeline["seed -> transform -> detect -> extract -> alert"]
  Surface -->|WebApp| WebPipeline["seed (browser actions) -> detect -> alert"]
  ApiPipeline --> Alert[Find vulnerability]
  WebPipeline --> Alert

Where to look next¶

Reference, in the order you usually need it when authoring a rule:

1. Seeders — inject requests (API) or drive the browser (WebApp).
2. Mutators — replay matched API requests with field-level changes.
3. Extractors — capture values from API responses for later re-injection.
4. Detectors — match conditions on requests, responses, or the rendered page.
5. Alerting — name, severity, context, category.

For real-world examples:

• Examples for APIs — every shipped API example, grouped by vulnerability.
• Examples for WebApps — every shipped WebApp example, grouped by vulnerability.

For the JSON Schema Custom Rules Reference (consumed by IDE tooling and the Escape platform).

Featured examples¶

A short tour to get you started. Each link jumps to the full prose + YAML on the matching examples page.

API¶

• Anonymous mutation succeeded
• BOLA via user swap with fingerprint comparison
• Mass assignment via privileged JSON field injection
• Header reinjection with extractor

WebApp¶

• Reflected XSS
• Stored XSS surviving a form submit + reload
• Subdomain takeover marker
• Sensitive file reachable in browser

Index¶