> For the complete documentation index, see [llms.txt](https://hackermater.gitbook.io/pentesting-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hackermater.gitbook.io/pentesting-notes/web-application-security/business-logic.md). # Business Logic Business logic testing focuses on the application's rules, state transitions, limits, and assumptions. These issues usually appear when individually valid requests are combined in an invalid sequence or context. ## Quick workflow ``` Understand feature → Write expected invariant → Map states → Map actors → Capture normal sequence → Reorder / repeat / omit → Change quantities / ownership / timing → Validate server-side enforcement ``` ## Start from invariants Write down what must always be true. Examples: ``` A coupon can only be redeemed once A refund cannot exceed the original payment A user cannot approve their own request Inventory cannot become negative A transfer must debit and credit exactly once An invite cannot grant a role higher than the inviter A completed order cannot return to a payable state ``` Then design tests that try to break one invariant at a time. ## Map the state machine Example of a business workflow state machine to use when testing invalid or unexpected transitions: ``` Draft → Submitted → Approved → Paid → Refunded ``` For each transition record: ``` Endpoint Method Required role Object state before Object state after Relevant IDs Price / amount Server-generated fields ``` Test unexpected transitions: ``` Draft → Paid Refunded → Paid Cancelled → Approved Submitted → Draft ``` ## Replay Capture a valid state-changing request and replay it. ```bash curl -ski \ -X POST \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json' \ --data '{"order_id":"123"}' \ https://example.com/api/orders/confirm ``` Questions: ``` Is the operation idempotent? Can it execute twice? Does the second response match the actual server state? Are side effects duplicated? ``` ## Skip steps If a workflow is: ``` Create → Verify → Confirm → Execute ``` Try controlled requests directly against later steps. Do not infer bypass from UI navigation. Verify the server accepts an invalid state transition. ## Reorder steps Examples: ``` Confirm before verify Apply discount after payment calculation Change address after shipping quote Change role after approval request Cancel while processing Redeem after refund ``` ## Change trusted client values Look for client-supplied fields such as: ``` price amount currency discount role status owner tenant is_admin approved quantity fee tax balance ``` Baseline: ```bash curl -ski \ -X POST \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json' \ --data '{"product_id":"100","quantity":1}' \ https://example.com/api/cart ``` Inspect whether calculated values are supplied back by the client and whether the server recomputes them. ## Quantity and boundary conditions Useful values: ``` 0 1 -1 Maximum allowed Maximum + 1 Very large integer Decimal where integer expected Duplicate item Empty collection ``` The objective is to test server invariants, not to cause resource exhaustion. ## Cross-user workflow abuse Use two controlled accounts. Examples: ``` A creates → B confirms A invites → B changes role A starts payment → B completes A generates export → B downloads A creates recovery flow → B consumes token ``` ## Role separation / approval flows For maker-checker or approval systems: ``` Can creator approve? Can approver modify then approve? Can approval be replayed? Can a lower role call approval directly? Can an object change after approval without invalidating it? ``` ## Discounts / credits / quotas Map: ``` Creation Application Consumption Refund/restoration Expiration Ownership Concurrency ``` Test whether the same resource can be applied more times than the business rule permits. ## Race conditions Potential targets: ``` Coupon redemption Inventory Transfers Votes Invite acceptance Password reset Username claiming Gift cards Quota consumption ``` First verify the operation safely at low concurrency. Only increase concurrency within engagement limits and with controlled test data. Record whether duplicated effects occur, not merely whether requests overlap. ## Time-based rules Test boundaries around: ``` Expiration Trial periods Booking windows Rate windows Promotion start/end Subscription changes Delayed jobs Token validity ``` Compare client time with server-enforced time. ## Business logic checklist ``` [ ] Critical workflows mapped [ ] Invariants written down [ ] State transitions mapped [ ] Repeat/replay tested [ ] Step skipping tested [ ] Step reordering tested [ ] Client-supplied trusted fields tested [ ] Boundary values tested [ ] Cross-account workflows tested [ ] Approval separation tested [ ] Discounts/credits/quotas tested [ ] Race-sensitive operations identified [ ] Time-based rules tested [ ] Impact validated with controlled objects ``` ## References * [OWASP Web Security Testing Guide - Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/) * [OWASP Transaction Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html)