Examples

Start with small automation patterns and verify the requests they launch.

Minimal learning example

The debug-to-reflection rule has one exact passive trigger and one active action. It is suitable for learning the format with the provided fixtures; it does not claim that a debug parameter is a vulnerability.

SQL injection candidates from the reviewed pack

The pack's SQLi_Rule uses this trigger/action selection:

{
  "match": ["true,,Passive Request,SQLi_Parameters"],
  "execute": [
    "true,Profile,SQLi,All Matches",
    "true,Profile,SQLi_Timebased_Encoded_Space,All Matches"
  ]
}

This is a rule fragment, not a complete profile. Parameter names are a heuristic for selecting tests, not evidence of SQL injection. Confirm the resulting request scope and findings.

Technology detection

A passive response profile can identify an application technology and trigger a specific active check. Prefer the narrowest useful selection, especially when a technology tag contains many historical CVEs. Detecting WordPress does not establish that every WordPress plugin is present.

The reviewed Wordpress_Rule includes an unresolved action name, easy_wp_smtp_listing_enabled. It is not present in the reviewed profile pack. Review the dependency before using that action; this documentation update does not silently rewrite the pack.

Multiple conditions

Some shipped rules contain request and response rows connected by And. They express the author's intended combination, but the current evaluator does not enforce that strict conjunction. Read the rule limitations rather than copying such a pattern as a guaranteed gate.

Broad tag actions

true,Tag,All,All Matches

This action can select a large set of enabled active profiles. The reviewed pack includes disabled broad scanning rules for this reason. Keep broad rules disabled unless their scope and traffic are deliberate. Changing a tag's membership also changes the selected work.

For the full current pack listing, see default rules.