Custom Rules Reference¶

Auto-generated reference for the JSON Schema accepted by the Escape platform. Both surfaces are covered below.

Shared models (AlertModel, Compliance, CustomRuleID, ...) are documented once in the API reference; the WebApp reference lists only WebApp-specific models and links back to the API section for shared definitions.

API reference¶

APICustomRule¶

Objects¶

APIExtractor¶

APILogicalAndDetector¶

APILogicalNotDetector¶

APILogicalOrDetector¶

AlertModel¶

BaseStringMutate¶

Compliance¶

CurlSeeder¶

CustomRuleID¶

FingerprintCountDetector¶

FingerprintsSameDetector¶

HTTPRAWSeeder¶

Use the raw HTTP seeder to call a private host (internal.example.com) and alert on a successful response when the production environment is not isolated from internal services.

Multi-environment platforms expect production runtime to be network-isolated from internal/back-office services. When a production-runtime container can resolve and reach internal.example.com, a single SSRF or admin-route mistake becomes a path into the internal network.

The seeder uses the raw HTTP seeder (with the @Host directive) so the request actually leaves the application's normal base_url and goes to the internal hostname.

When to use: Run this from the same scanning environment you want to validate. Replace internal.example.com with the actual hostname you want to assert is unreachable.

OWASP: A05:2021 Security Misconfiguration · CWE: CWE-918

Severity rationale: HIGH when paired with any user-controlled URL fetch in the API; MEDIUM as a standalone configuration finding.

Features used: seed, detect, http raw seeder with @Host directive

rule:
  id: example-api-environment-isolation-internal-host
  type: API
  alert:
    name: Production environment can reach internal host
    context: |
      A request issued to `internal.example.com` from the production
      scanner returned a successful response. The runtime
      environment is not isolated from internal services.
    severity: HIGH
    category: REQUEST_FORGERY
  seed:
  - protocol: http
    raw: |
      @Host: https://internal.example.com
      GET /api/health HTTP/1.1
      Host: internal.example.com
  detect:
  - if: schema.url
    contains: internal.example.com
  - if: helpers.response.is_successful
    is: true

References:

• https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
• https://cwe.mitre.org/data/definitions/918.html For standard REST endpoints prefer the rest seeder (auto-fillshost and scheme from the scan target). | | raw* | string | | The raw HTTP request in Nuclei format. | | user | string | null | The user to use for the request. If not provided, the request is sent without authentication. |

HelpersRequestCrudDetector¶

HelpersResponseIsSuccessfulDetector¶

Detect any successful CREATE / UPDATE / DELETE issued without an authenticated user.

Most APIs gate state-changing operations behind authentication. When a public (unauthenticated) request manages to perform a CREATE / UPDATE / DELETE and receives a 2xx response, the endpoint is missing an authn or authz check.

The rule combines three deterministic signals: the inferred CRUD operation is not READ, the request was issued by the public pseudo-user (Escape's representation of an anonymous caller), and the response is in the 2xx range.

When to use: Apply on every API. This is one of the highest-signal rules in the library and rarely produces false positives because all three conditions must hold simultaneously.

OWASP: API2:2023 Broken Authentication · CWE: CWE-306

Severity rationale: HIGH — anonymous mutations typically allow unauthorized data writes, deletion of resources, or trivial denial-of-service via mass creation.

Features used: detect, helpers.request.crud, request.is_authenticated, helpers.response.is_successful

rule:
  id: example-api-unauthenticated-mutation
  type: API
  alert:
    name: Unauthenticated mutation succeeded
    context: |
      A CREATE / UPDATE / DELETE request issued without authentication
      returned a 2xx response. The endpoint is missing an authentication
      or authorization check.
    severity: HIGH
    category: ACCESS_CONTROL
  detect:
  - if: helpers.request.crud
    is_not: READ
  - if: request.is_authenticated
    is: false
  - if: helpers.response.is_successful
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/
• https://cwe.mitre.org/data/definitions/306.html | | is | boolean | null | Condition is true | | is_not | boolean | null | Condition is false |

JSONMatchesAllDetector¶

JSONMatchesCountDetector¶

JsonValue¶

Middleware¶

ObjectMatcher¶

ObjectTypeMatcher¶

RESTSeeder¶

Probe the Spring Boot actuator /env and /beans endpoints (with and without the /actuator prefix) and alert if the body leaks JAVA_HOME — proof the actuator is reachable.

Spring Boot's actuator exposes deep introspection endpoints (/env, /beans, /heapdump, /configprops, /mappings) that in default 1.x configurations were public. They leak environment variables, database connection strings, JWT secrets, S3 credentials, anything passed via -D flags or env vars.

The rule probes the four most common path layouts and asserts a successful response containing JAVA_HOME, which is virtually certain to be present in /env output.

When to use: Any backend potentially using Spring Boot. False-positive rate is very low because the JAVA_HOME marker rarely appears in legitimate API responses.

OWASP: API8:2023 Security Misconfiguration · CWE: CWE-200

Severity rationale: HIGH — actuator output usually contains credentials, signing keys, and infrastructure URLs that lead to direct compromise.

Features used: seed, detect, helpers.response.is_successful, response.body.text contains

rule:
  id: example-api-spring-boot-actuator-env
  type: API
  alert:
    name: Spring Boot actuator /env exposed
    context: |
      A request to the Spring Boot actuator `/env` endpoint returned
      a successful response containing `JAVA_HOME`, indicating the
      actuator is publicly reachable and leaking environment data.
    severity: HIGH
    category: INFORMATION_DISCLOSURE
  seed:
  - protocol: rest
    method: GET
    path: /actuator/env
    headers: {}
  - protocol: rest
    method: GET
    path: /actuator/beans
    headers: {}
  - protocol: rest
    method: GET
    path: /env
    headers: {}
  - protocol: rest
    method: GET
    path: /beans
    headers: {}
  detect:
  - if: helpers.response.is_successful
    is: true
  - if: response.body.text
    contains: JAVA_HOME

References:

• https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/
• https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html
• https://cwe.mitre.org/data/definitions/200.html In context — exposed SQL dump probing with Range header:#### Exposed SQL dumps reachable over HTTP { #example-api-information-disclosure-exposed-sql-dumps }

Probe a curated list of common SQL dump filenames at the root of the target and alert if the server returns the file with a SQL DDL/DML signature in the body.

Backups left in the web root are one of the highest-impact and cheapest-to-find exposures in API testing. This rule probes a curated list of common backup filenames (backup.sql, dump.sql, db.sql, mysqldump.sql, ...) using a Range: bytes=0-3000 header so the download stays small even if the file is multi-gigabyte. Extend the seed: list with additional paths to suit your target.

Detection requires both a 200/206 status and a body containing typical SQL DDL/DML keywords (DROP TABLE, CREATE TABLE, INSERT INTO, LOCK TABLE). The status code and body regex are AND-combined so a generic 200 page with no SQL content does not fire.

When to use: Run against every public host. Especially useful immediately after deployments, when build artifacts are sometimes left in /public by accident.

OWASP: A05:2021 Security Misconfiguration · CWE: CWE-540

Severity rationale: HIGH — exposed dumps regularly contain credentials, password hashes, and full PII.

Features used: seed, detect, rest seeder with custom Range header, response.body.text regex, response.status_code in

rule:
  id: example-api-exposed-sql-dumps
  type: API
  alert:
    name: Exposed SQL dump
    context: |
      A request to a common SQL dump filename returned a 200/206 with
      DDL/DML keywords in the body, indicating a database backup
      reachable over HTTP.
    severity: HIGH
    category: INFORMATION_DISCLOSURE
  seed:
  - protocol: rest
    method: GET
    path: /backup.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /database.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /dump.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /db.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /mysqldump.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /db_backup.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /wp-content/uploads/dump.sql
    headers:
      Range: bytes=0-3000
  detect:
  - if: response.body.text
    regex: .*((DROP|CREATE|(?:UN)?LOCK) TABLE|INSERT INTO).*
  - if: response.status_code
    in:
    - 200
    - 206

References:

• https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
• https://cwe.mitre.org/data/definitions/540.html | | user | string | null | The user to use for the request. If not provided, the request is sent without authentication. |

RegexMatchesAllDetector¶

RegexMatchesCountDetector¶

RegexReplace¶

RequestArgument¶

RequestBodyJSONDetector¶

RequestBodyJSONMutator¶

Inject role: admin (and friends) into every successful JSON write issued by a regular user; alert if the modified request still succeeds — the API failed to filter dangerous fields.

Mass assignment (a.k.a. autobinding, BOPLA) happens when an API deserializes a client JSON payload directly into a server-side data model without a field allow-list. An attacker can then pass extra fields (is_admin, role, verified, subscription_tier, ...) and elevate their own state.

The deterministic test:

1. transform.trigger selects every successful CREATE / UPDATE issued by tester@example.com whose JSON body does not yet carry an admin marker.
2. transform.mutate adds is_admin: true and role: admin using a JQ expression.
3. detect fires when the augmented request is still successful — proving the server accepted the privileged fields.

When to use: Any REST or GraphQL endpoint that accepts a JSON object describing a user-owned resource (profile, account, organization, settings). Adjust the JQ expression to the field names your API uses.

OWASP: API3:2023 BOPLA · CWE: CWE-915

Severity rationale: HIGH — successful mass assignment typically grants full admin impersonation or unbounded subscription upgrades.

Features used: transform, detect, request.body.json mutator (jq), helpers.request.crud

rule:
  id: example-api-mass-assignment-role-injection
  type: API
  alert:
    name: Mass assignment accepted privileged fields
    context: |
      A request augmented with `is_admin: true` and `role: admin` was
      accepted by the API. The endpoint deserializes user-supplied
      fields into a server-side data model without a field allow-list.
    severity: HIGH
    category: ACCESS_CONTROL
  transform:
    trigger:
    - if: helpers.response.is_successful
      is: true
    - if: helpers.request.crud
      in:
      - CREATE
      - UPDATE
    - if: request.user
      is: tester@example.com
    mutate:
    - key: request.body.json
      jq: '. + {"is_admin": true, "role": "admin"}'
  detect:
  - if: helpers.response.is_successful
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/
• https://cwe.mitre.org/data/definitions/915.html
• https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html In context — fuzz every string in the body with a SQL-breaking suffix:#### SQL injection in JSON body via JQ-targeted payloads { #example-api-injection-sql-injection-jq-string-fields }

Walk every string field of a successful JSON request body and append a SQL-breaking payload to its value, then alert on a DBMS error in the response.

REST APIs that consume JSON usually deserialize it into typed objects. The classic concatenation-style SQLi sink is then accessible via any user-controlled string field that is passed unvalidated into a query.

The transform uses a JQ expression that walks the JSON structure and rewrites every string leaf by appending ' OR 1=1--. The detector then looks for the same DBMS error fingerprints used by the text-based SQLi rule.

When to use: Any REST or GraphQL endpoint that accepts JSON. Pair with the error-disclosure SQLi rule for text-encoded request bodies.

OWASP: A03:2021 Injection · CWE: CWE-89

Severity rationale: HIGH — same impact as classic SQLi.

Features used: transform, detect, request.body.json mutator (jq), response.body.text regex

rule:
  id: example-api-sql-injection-jq-string-fields
  type: API
  alert:
    name: SQL injection via JSON string field
    context: |
      A SQL-breaking suffix appended to every string value in the
      request body caused the API to leak a DBMS error string in the
      response.
    severity: HIGH
    category: INJECTION
  transform:
    trigger:
    - if: helpers.response.is_successful
      is: true
    - if: request.body.json
      jq: any(.. | strings)
    mutate:
    - key: request.body.json
      jq: (.. | strings) |= . + "' OR 1=1--"
  detect:
  - if: response.body.text
    regex: .*(syntax error|sql error|ORA-[0-9]+|mysql_fetch|psql:|sqlite3.OperationalError|SQLSTATE\[).*

References:

• https://owasp.org/Top10/A03_2021-Injection/
• https://cwe.mitre.org/data/definitions/89.html Tip: test your JQ queries at \<jqplay.org before using them. | | use_extraction | boolean | false | If True, variable references between {{ }} will be replace with the extracted value (If exists). The string representation of the variable will be used without any extra-processing. |

RequestBodyTextDetector¶

RequestBodyTextMutator¶

RequestCookieExtractor¶

RequestHeadersDetector¶

RequestHeadersMutator¶

RequestIsAuthenticatedDetector¶

RequestMethodDetector¶

RequestMethodMutator¶

Re-issue every successful CREATE / UPDATE / DELETE issued by tester@example.com as attacker@example.com and alert if the write still succeeds — the endpoint is missing horizontal authorization.

Horizontal authorization failures appear when user A can perform a state-changing operation on a resource that belongs to user B. Unlike BOLA (which is read-side), this rule targets writes: delete-someone-else's-record, update-someone-else's-profile, cancel-someone-else's-order.

The trigger picks successful writes by tester@example.com. The mutator switches request.user to attacker@example.com. If the replayed write is still successful, the API never re-checked ownership of the targeted resource against the new caller.

When to use: Any API where users can mutate records keyed by a path/body id. Pair with the platform's authentication configuration: define tester@example.com and attacker@example.com with disjoint resources before enabling this rule.

OWASP: API1:2023 BOLA · CWE: CWE-639

Severity rationale: HIGH — horizontal write escalation typically lets attackers delete or alter records belonging to other tenants and can be weaponized for denial-of-service or sabotage.

Features used: transform, detect, helpers.request.crud, request.user mutator

rule:
  id: example-api-horizontal-privilege-escalation-write
  type: API
  alert:
    name: Horizontal privilege escalation on write
    context: |
      A successful write issued by `tester@example.com` was replayed as
      `attacker@example.com` and still succeeded. The endpoint is
      missing a horizontal authorization check.
    severity: HIGH
    category: ACCESS_CONTROL
  transform:
    trigger:
    - if: helpers.response.is_successful
      is: true
    - if: helpers.request.crud
      in:
      - CREATE
      - UPDATE
      - DELETE
    - if: request.user
      is: tester@example.com
    mutate:
    - key: request.user
      value: attacker@example.com
  detect:
  - if: helpers.response.is_successful
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• https://cwe.mitre.org/data/definitions/639.html | | value | HTTPMethod | null | The value to set. | | values | List[HTTPMethod] | null | The values to set, generates multiple queries. |

RequestObjectDetector¶

RequestObjectMutator¶

RequestUserDetector¶

Replay every successful authenticated request as a different user and flag responses that succeed AND return the same body fingerprint — classic Broken Object Level Authorization.

Broken Object Level Authorization (BOLA / IDOR) is the #1 API risk in the OWASP API Top 10. The pattern is straightforward: endpoint X correctly authenticates tester@example.com and returns its own data, but never re-checks ownership when a different user calls the same URL — so attacker@example.com gets the same response.

This rule encodes the test deterministically:

1. transform.trigger selects every successful request issued by tester@example.com.
2. transform.mutate re-issues that request with request.user set to attacker@example.com.
3. detect fires when the replayed response is also successful AND its body fingerprint matches the original — meaning the API returned the first user's data to the second user.

When to use: Any REST or GraphQL endpoint that returns user-scoped data. Pair with your authentication configuration in the Escape platform: define at least two users with disjoint resources for the fingerprint check to be meaningful.

OWASP: API1:2023 BOLA · CWE: CWE-639

Severity rationale: HIGH — cross-tenant data leakage is typically a reportable security incident and a frequent cause of GDPR / SOC 2 findings.

Features used: transform, detect, request.user mutator, helpers.fingerprints.same, helpers.response.is_successful

rule:
  id: example-api-bola-user-swap-fingerprint
  type: API
  alert:
    name: Possible BOLA via user swap
    context: |
      A successful authenticated response was returned with an identical
      body fingerprint when the same request was replayed as a different
      user. The endpoint is likely missing an object-level authorization
      check.
    severity: HIGH
    category: ACCESS_CONTROL
  transform:
    trigger:
    - if: helpers.response.is_successful
      is: true
    - if: request.user
      is: tester@example.com
    mutate:
    - key: request.user
      value: attacker@example.com
  detect:
  - if: helpers.response.is_successful
    is: true
  - if: helpers.fingerprints.same
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• https://cwe.mitre.org/data/definitions/639.html | | in | List[string] | null | Condition is in this list (case-insensitive) | | is | string | null | Condition is this string (case-insensitive) | | is_not | string | null | Condition is not this string (case-insensitive) | | regex | string | null | Condition is matched on this regex with fullmatch (case-insensitive) | | use_extraction | boolean | false | If True, variable references between {{ }} will be replace with the extracted value (If exists). The string representation of the variable will be used without any extra-processing. |

RequestUserMutator¶

Re-issue every successful CREATE / UPDATE / DELETE issued by tester@example.com as attacker@example.com and alert if the write still succeeds — the endpoint is missing horizontal authorization.

Horizontal authorization failures appear when user A can perform a state-changing operation on a resource that belongs to user B. Unlike BOLA (which is read-side), this rule targets writes: delete-someone-else's-record, update-someone-else's-profile, cancel-someone-else's-order.

The trigger picks successful writes by tester@example.com. The mutator switches request.user to attacker@example.com. If the replayed write is still successful, the API never re-checked ownership of the targeted resource against the new caller.

When to use: Any API where users can mutate records keyed by a path/body id. Pair with the platform's authentication configuration: define tester@example.com and attacker@example.com with disjoint resources before enabling this rule.

OWASP: API1:2023 BOLA · CWE: CWE-639

Severity rationale: HIGH — horizontal write escalation typically lets attackers delete or alter records belonging to other tenants and can be weaponized for denial-of-service or sabotage.

Features used: transform, detect, helpers.request.crud, request.user mutator

rule:
  id: example-api-horizontal-privilege-escalation-write
  type: API
  alert:
    name: Horizontal privilege escalation on write
    context: |
      A successful write issued by `tester@example.com` was replayed as
      `attacker@example.com` and still succeeded. The endpoint is
      missing a horizontal authorization check.
    severity: HIGH
    category: ACCESS_CONTROL
  transform:
    trigger:
    - if: helpers.response.is_successful
      is: true
    - if: helpers.request.crud
      in:
      - CREATE
      - UPDATE
      - DELETE
    - if: request.user
      is: tester@example.com
    mutate:
    - key: request.user
      value: attacker@example.com
  detect:
  - if: helpers.response.is_successful
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• https://cwe.mitre.org/data/definitions/639.html In context — BOLA via user swap with fingerprint comparison:#### BOLA via user swap with fingerprint comparison { #example-api-access-control-bola-user-swap-fingerprint }

Replay every successful authenticated request as a different user and flag responses that succeed AND return the same body fingerprint — classic Broken Object Level Authorization.

Broken Object Level Authorization (BOLA / IDOR) is the #1 API risk in the OWASP API Top 10. The pattern is straightforward: endpoint X correctly authenticates tester@example.com and returns its own data, but never re-checks ownership when a different user calls the same URL — so attacker@example.com gets the same response.

This rule encodes the test deterministically:

1. transform.trigger selects every successful request issued by tester@example.com.
2. transform.mutate re-issues that request with request.user set to attacker@example.com.
3. detect fires when the replayed response is also successful AND its body fingerprint matches the original — meaning the API returned the first user's data to the second user.

When to use: Any REST or GraphQL endpoint that returns user-scoped data. Pair with your authentication configuration in the Escape platform: define at least two users with disjoint resources for the fingerprint check to be meaningful.

OWASP: API1:2023 BOLA · CWE: CWE-639

Severity rationale: HIGH — cross-tenant data leakage is typically a reportable security incident and a frequent cause of GDPR / SOC 2 findings.

Features used: transform, detect, request.user mutator, helpers.fingerprints.same, helpers.response.is_successful

rule:
  id: example-api-bola-user-swap-fingerprint
  type: API
  alert:
    name: Possible BOLA via user swap
    context: |
      A successful authenticated response was returned with an identical
      body fingerprint when the same request was replayed as a different
      user. The endpoint is likely missing an object-level authorization
      check.
    severity: HIGH
    category: ACCESS_CONTROL
  transform:
    trigger:
    - if: helpers.response.is_successful
      is: true
    - if: request.user
      is: tester@example.com
    mutate:
    - key: request.user
      value: attacker@example.com
  detect:
  - if: helpers.response.is_successful
    is: true
  - if: helpers.fingerprints.same
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• https://cwe.mitre.org/data/definitions/639.html | | regex_replace | RegexReplace | null | Regex replace pattern. | | use_extraction | boolean | false | If True, variable references between {{ }} will be replace with the extracted value (If exists). The string representation of the variable will be used without any extra-processing. | | value | string | null | The value to set. | | values | List[string] | null | The values to set, generates multiple queries. |

ResponseBodyJSONDetector¶

ResponseBodyJSONExtractor¶

ResponseBodyTextDetector¶

ResponseBodyTextExtractor¶

ResponseCookieExtractor¶

ResponseDurationDetector¶

ResponseDurationExtractor¶

ResponseHeaderExtractor¶

ResponseHeadersDetector¶

ResponseObjectDetector¶

ResponseStatusCodeDetector¶

Probe a curated list of common SQL dump filenames at the root of the target and alert if the server returns the file with a SQL DDL/DML signature in the body.

Backups left in the web root are one of the highest-impact and cheapest-to-find exposures in API testing. This rule probes a curated list of common backup filenames (backup.sql, dump.sql, db.sql, mysqldump.sql, ...) using a Range: bytes=0-3000 header so the download stays small even if the file is multi-gigabyte. Extend the seed: list with additional paths to suit your target.

Detection requires both a 200/206 status and a body containing typical SQL DDL/DML keywords (DROP TABLE, CREATE TABLE, INSERT INTO, LOCK TABLE). The status code and body regex are AND-combined so a generic 200 page with no SQL content does not fire.

When to use: Run against every public host. Especially useful immediately after deployments, when build artifacts are sometimes left in /public by accident.

OWASP: A05:2021 Security Misconfiguration · CWE: CWE-540

Severity rationale: HIGH — exposed dumps regularly contain credentials, password hashes, and full PII.

Features used: seed, detect, rest seeder with custom Range header, response.body.text regex, response.status_code in

rule:
  id: example-api-exposed-sql-dumps
  type: API
  alert:
    name: Exposed SQL dump
    context: |
      A request to a common SQL dump filename returned a 200/206 with
      DDL/DML keywords in the body, indicating a database backup
      reachable over HTTP.
    severity: HIGH
    category: INFORMATION_DISCLOSURE
  seed:
  - protocol: rest
    method: GET
    path: /backup.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /database.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /dump.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /db.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /mysqldump.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /db_backup.sql
    headers:
      Range: bytes=0-3000
  - protocol: rest
    method: GET
    path: /wp-content/uploads/dump.sql
    headers:
      Range: bytes=0-3000
  detect:
  - if: response.body.text
    regex: .*((DROP|CREATE|(?:UN)?LOCK) TABLE|INSERT INTO).*
  - if: response.status_code
    in:
    - 200
    - 206

References:

• https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
• https://cwe.mitre.org/data/definitions/540.html | | in | List[integer] | null | Condition is in this list of integers (exact match) | | is | integer | null | Condition is this exact integer | | is_not | integer | null | Condition is not this exact integer | | lt | integer | null | Condition is less than this integer |

ResponseStatusCodeExtractor¶

ScanTypeDetector¶

SchemaNeedAuthenticationDetector¶

SchemaPathRefDetector¶

Flag any successful response on a path containing /admin/ issued without authentication — the cheapest deterministic check for an accidentally-public administrative surface.

Almost no application intentionally exposes admin functionality to anonymous callers. When an endpoint matching /admin/ returns a 2xx to a public request, the most likely explanations are:

• missing authentication middleware,
• a route that bypasses the global auth filter,
• a debug / staging route accidentally promoted to production.

The rule combines three signals (schema.path_ref contains /admin, request is unauthenticated, response is successful) so it fires only when all three hold.

When to use: Any HTTP API. Equally useful as a regression test in CI and as a routine production scan rule. Tighten contains: /admin to a more specific path if your product legitimately exposes anonymous admin metadata pages.

OWASP: API5:2023 Broken Function Level Authorization · CWE: CWE-862

Severity rationale: HIGH — anonymous admin access is reliably exploitable and one of the most common high-severity misconfigurations in real-world API security reports.

Features used: detect, schema.path_ref, request.is_authenticated, helpers.response.is_successful

rule:
  id: example-api-public-admin-route
  type: API
  alert:
    name: Public administrative route
    context: |
      An unauthenticated request to a path containing `/admin/`
      returned a 2xx response. The route is missing an authentication
      check.
    severity: HIGH
    category: ACCESS_CONTROL
  detect:
  - if: schema.path_ref
    contains: /admin/
  - if: request.is_authenticated
    is: false
  - if: helpers.response.is_successful
    is: true

References:

• https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/
• https://cwe.mitre.org/data/definitions/862.html | | in | List[string] | null | Condition is in this list (case-insensitive) | | is | string | null | Condition is this string (case-insensitive) | | is_not | string | null | Condition is not this string (case-insensitive) | | regex | string | null | Condition is matched on this regex with fullmatch (case-insensitive) | | use_extraction | boolean | false | If True, variable references between {{ }} will be replace with the extracted value (If exists). The string representation of the variable will be used without any extra-processing. |

SchemaPathRefMutator¶

SchemaUrlDetector¶

SchemaUrlExtractor¶

SchemaUrlMutator¶

StringMatcher¶

VariableDefinedDetector¶

VariableName¶

Enums¶

CRUD¶

CustomRuleCategory¶

CustomRuleScanType¶

CustomRuleSeverity¶

HTTPMethod¶

OBJECT_TYPE¶

WebApp reference¶

FrontendCustomRule¶

Objects¶

CheckAction¶

ClickAction¶

ClickMailMagicLinkAction¶

CookieDetector¶

DialogMessageDetector¶

FillAction¶

FillMailTOTPAction¶

FillTOTPAction¶

FocusPageAction¶

FrontendGotoAction¶

FrontendLogicalAndDetector¶

FrontendLogicalNotDetector¶

FrontendLogicalOrDetector¶

FrontendRequestAction¶

HeaderDetector¶

JSAssertionDetector¶

LastRequestResponseTextDetector¶

LocalStorageDetector¶

PageSelectorDetector¶

PageStatusCodeDetector¶

PageTextDetector¶

SelectAction¶

SessionStorageDetector¶

SleepAction¶

SolveCaptchaAction¶

WaitElementAction¶

WaitTextAction¶

Enums¶