Detection rules

Custom rules let you tag scans for things specific to your business — a competitor's brand, a prohibited phrase, a risky redirect pattern.

Rule types

• Stopword — match literal terms, either in the page content (stopword_content) or in a URL in the chain (stopword_url).
• Regex — match a regular expression against page content (regexp_content), main-frame URLs in the redirect chain (regexp_url), every captured network and subresource request URL (regexp_request_url), or the contents of the sub-resources the page loaded (regexp_request_body). Request-URL and request-body rules choose a target like content rules do: the landing page, the creative, or both.
• Blacklist domain — flag when the redirect chain touches a domain on your list.
• Combo — combine conditions on other tags (e.g. a keyword and a redirect to a given domain), counted either across the whole scan or within a single link. See combo rules.
• AI — describe in natural language what to flag; the AI applies it.

Authoring

Open Rules -> New Rule, pick the type, define the condition, and choose which tag it assigns and which target it inspects — page (the landing), the creative, or both. The available targets depend on the rule type. Save to activate.

On an ad-tag scan the creative loads sub-resources of its own, inside its own frame — they appear on no landing page's request list. A rule aimed at page therefore cannot see them, which matters most for the thing they are usually hiding: a payload whose filename rotates every few hours. Aim the rule at the creative, or at both surfaces to reuse one pattern; a match reports which surface it came from either way. The creative's own request tree is shown under Creative sub-requests on the scan report.

Network-request and request-body regex rules accept a non-empty pattern of at most 4,096 characters and optional flags. Omit flags or use an empty string for case-sensitive matching; i enables case-insensitive matching. Other flags and config keys are rejected before the rule is saved or tested.

To check a rule before saving it, test it against scans you already have. Through the API you can test up to 20 draft rules against up to 50 scans in one call; see the Rule testing API.

Matching sub-resource contents

regexp_request_body matches the bytes a page's sub-resources served, not their addresses. Use it when the thing you want to catch keeps the same code but changes its filename on every visit — the pattern that defeats a regexp_request_url rule.

What the pattern is run against, per scan:

• The scripts and fetch / XHR responses the page loaded, plus the documents inside its iframes. The landing document itself is covered by regexp_content, and images, video, fonts and stylesheets are never captured.
• Up to 400 sub-resources, each up to 128 KB, and up to 8 MB in total. A resource above those limits is recorded by URL but its content is not searched.

Captured contents are kept for one day. A rule test against a scan older than that finds nothing to match — which reads exactly like a non-match, so test new body rules against a recent scan.

Rechecking

After saving a rule you can recheck existing scans so historical results pick up the new tag — handy when you add a rule in response to an incident and want to find everything it already touched.

Fresh scans provide request-URL rules with up to 5,000 captured network URLs. Rule tests and rechecks of an existing scan reconstruct URLs from its persisted initiator tree, which currently stores the main-frame hops and up to 200 subrequests and omits selected resource types. Historical request-URL results are therefore best-effort; the ordinary redirect-chain fields and their existing rule semantics are unchanged.