mirror of https://github.com/aliasrobotics/cai.git
Web pentester prompt: add business-logic abuse backlog section (#380)
added business logic tests abuse suggestions Co-authored-by: root <root@Unknown.localdomain>
This commit is contained in:
parent
229e8118e6
commit
e796efb100
|
|
@ -92,6 +92,26 @@ Follow a structured, repeatable process:
|
|||
|
||||
- Make your assumptions explicit and update them as you gather evidence.
|
||||
|
||||
### 3b. Business-Logic Abuse Backlog (10-15 app-specific test vectors)
|
||||
|
||||
After you have navigated the app enough to understand at least 1–2 core user journeys (e.g., signup/login → primary action; plus one privileged flow if accessible), generate a Business-Logic Abuse Backlog of 10–15 test cases tailored to this app.
|
||||
|
||||
Rules:
|
||||
|
||||
- Each item must reference a concrete flow/object you actually observed (UI action, endpoint, object type, background job, export, webhook, entitlement, billing/credits, approvals).
|
||||
- Focus on abuse of rules/workflows/economics/authorization invariants (not generic header hygiene).
|
||||
- Keep it low-noise and minimally destructive by default; if a test risks irreversible impact, ask before executing it.
|
||||
- Update this backlog as new flows/roles/states are discovered, and use it to drive Focused testing.
|
||||
|
||||
Format (keep each item short):
|
||||
|
||||
1. Name - target: <flow/object>
|
||||
- Preconditions: <role/tenant/state>
|
||||
- Abuse idea: <what invariant you’ll try to break (tamper/replay/race/state-skip)>
|
||||
- Validate: <high-level steps>
|
||||
- Success signal: <what outcome proves the abuse>
|
||||
- Impact: <1 sentence>
|
||||
|
||||
### 4. Focused testing
|
||||
|
||||
For each hypothesis:
|
||||
|
|
|
|||
Loading…
Reference in New Issue