|
| 1 | +--- |
| 2 | +pcx_content_type: reference |
| 3 | +title: Sequence Mitigation custom rules |
| 4 | +sidebar: |
| 5 | + order: 2 |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +import { GlossaryTooltip, Render } from "~/components" |
| 10 | + |
| 11 | +API Shield sequence custom rules use the configured API Shield <GlossaryTooltip term="session identifier">session identifier</GlossaryTooltip> to track the order of requests a user has made and the time between requests, and makes them available via [Cloudflare Rules](/rules). This allows you to write rules that match valid or invalid sequences. |
| 12 | + |
| 13 | +These rules are different from [cookie sequence rules](/bots/concepts/sequence-rules/) in a few ways: |
| 14 | + |
| 15 | +- They only require an API Shield subscription. |
| 16 | +- They require [session identifiers](/api-shield/get-started/#session-identifiers) to be set in API Shield. |
| 17 | +- Because they use an API's session identifiers, they can be used for APIs designed for mobile applications. |
| 18 | +- Because Cloudflare stores the user state in memory and not in a cookie, the session lifetime is limited to 10 minutes. |
| 19 | + |
| 20 | +Rules built using these custom rules are different from sequence mitigation rules built [via API or the Cloudflare dashboard](/api-shield/security/sequence-mitigation/). The custom rules syntax enables free-form logic and response options that the dashboard does not. |
| 21 | + |
| 22 | +## Availability |
| 23 | + |
| 24 | +<Render file="sequence-rules-availability" product="bots" /> |
| 25 | + |
| 26 | +## Example rules |
| 27 | + |
| 28 | +Each saved endpoint will have an endpoint ID visible in its details page in Endpoint Management in the form of a UUID. The references below (`aaaaaaaa`, `bbbbbbbb`, and `cccccccc`) are the first eight characters of the endpoint ID. |
| 29 | + |
| 30 | +The visitor must wait more than 2 seconds after requesting endpoint `aaaaaaaa` before requesting endpoint `bbbbbbbb`: |
| 31 | + |
| 32 | +```txt |
| 33 | +cf.sequence.current_op eq "bbbbbbbb" and |
| 34 | +cf.sequence.msec_since_op["aaaaaaaa"] ge 2000 |
| 35 | +``` |
| 36 | + |
| 37 | +The visitor must request endpoints `aaaaaaaa`, then `bbbbbbbb`, then `cccccccc` in that exact order: |
| 38 | + |
| 39 | +```txt |
| 40 | +cf.sequence.current_op eq "cccccccc" and |
| 41 | +cf.sequence.previous_ops[0] == "bbbbbbbb" and |
| 42 | +cf.sequence.previous_ops[1] == "aaaaaaaa" |
| 43 | +``` |
| 44 | + |
| 45 | +The visitor must request endpoint `aaaaaaaa` before endpoint `bbbbbbbb`, but endpoint `aaaaaaaa` can be anywhere in the previous 10 requests: |
| 46 | + |
| 47 | +```txt |
| 48 | +cf.sequence.current_op eq "bbbbbbbb" and |
| 49 | +any(cf.sequence.previous_ops[*] == "aaaaaaaa") |
| 50 | +``` |
| 51 | + |
| 52 | +The visitor must request either endpoint `aaaaaaaa` before endpoint `bbbbbbbb`, or endpoint `cccccccc` before endpoint `bbbbbbbb`: |
| 53 | + |
| 54 | +```txt |
| 55 | +(cf.sequence.current_op eq "bbbbbbbb" and |
| 56 | +any(cf.sequence.previous_ops[*] == "aaaaaaaa")) or |
| 57 | +(cf.sequence.current_op eq "bbbbbbbb" and |
| 58 | +any(cf.sequence.previous_ops[*] == "cccccccc")) |
| 59 | +``` |
0 commit comments