Business Logic

Introduction

Business logic vulnerabilities are the hardest class of bugs to find with automated tools because scanners don’t understand what the application is supposed to do. These are the flaws that exist precisely because developers designed features to work under normal conditions — attackers find ways to use them abnormally.

Always obtain written, explicit authorization before testing business logic. Use dedicated test accounts. Never test logic flaws against real user data or production transactions.

The attacker’s perspective: every feature is a potential weapon. If I can buy something for $0, transfer someone else’s funds, or elevate my own privilege using the application’s own mechanisms — that’s a business logic vulnerability.

IDOR

Purpose of the Test

IDOR occurs when an application uses user-controllable references (IDs in URLs, request bodies, or parameters) to access objects without verifying that the current user is authorized to access that specific object.

Impact

• Horizontal privilege escalation: access other users’ data with the same role
• Vertical privilege escalation: access admin data as a regular user
• Data exfiltration at scale: enumerate all user records
• Unauthorized modification or deletion of other users’ data

Expected Outcomes

Positive finding: Changing a user ID, order ID, or document ID in the request returns another user’s data without an authorization error.

Clean result: Requests for objects belonging to other users return 403 Forbidden, regardless of whether the object ID is valid.

Ethical Considerations

• When testing IDOR, use two test accounts (Account A and Account B) — never access real user data
• If you accidentally view real user data, stop, document only that the vulnerability exists, and report immediately
• Never enumerate IDs to build a database of real user records
• Hard stop: If IDOR exposes real PII (names, emails, health data, financial data) — stop, do not collect, report immediately

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Two-account controlled test only"]
    D["Document (no real data)"]
    A --> B --> C --> D

Manual Testing Steps

1. Create two test accounts: Account A (attacker) and Account B (victim)
2. As Account B: create a resource (order, document, profile entry) and note its ID
3. As Account A: send a request accessing Account B’s resource ID
4. Observe: does the server return Account B’s data? Or a 403?
5. Test all HTTP methods: GET (read), PUT/PATCH (modify), DELETE
6. Test indirect references: download links, report IDs, export endpoints
7. Document the vulnerable endpoint, the IDs used, and the response (without real data)

AI-Assisted Testing

Prompt Template — IDOR Test Planning

[ROLE] Web security testing assistant
[APPLICATION] E-commerce platform — endpoints include:
  GET /api/orders/{order_id}
  GET /api/users/{user_id}/profile
  GET /api/documents/{doc_id}/download
[TASK] Design a controlled IDOR test plan for these endpoints.
  - Two-account test methodology only (no real user data)
  - Identify which HTTP methods to test per endpoint
  - Define what constitutes a confirmed finding vs. false positive
[OUTPUT FORMAT]
  - Test matrix: Endpoint | Method | Test Action | Expected Vulnerable Response | Expected Secure Response
[CONSTRAINTS] Two test accounts only. No real user data access.

AI Hard Stops for This Topic

• [NO] Never use real user IDs — only test accounts
• [NO] Stop immediately if real user data appears in a response
• [NO] Never enumerate real user IDs at scale
• [YES] Two-account methodology is the standard for IDOR testing
• [YES] Document the finding description without including any real user data

Race Conditions

Purpose of the Test

Race conditions occur when the application assumes operations are atomic but they are not — a brief window between “check” and “use” allows an attacker to submit the same operation multiple times simultaneously, each succeeding before the other’s result is committed.

Impact

• Double-spending: redeem a coupon or gift card multiple times
• Balance manipulation: withdraw more funds than available
• Duplicate premium feature activation with a single payment
• Bypassing rate limits that are not atomically enforced

Expected Outcomes

Positive finding: Simultaneous requests cause multiple successful operations that should have been limited to one (e.g., both coupon redemptions succeed, balance goes negative).

Clean result: Only one request succeeds when concurrent requests are sent; database transactions use appropriate locking.

Ethical Considerations

• Test race conditions only in a staging or sandbox environment
• Use test currency/credits — never test with real financial transactions
• Confirm with the client before testing: concurrent load can stress the application
• Hard stop: If race condition testing causes real financial transactions to occur, stop immediately and notify the client

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Staging environment only"]
    D["Parallel request test"]
    E["Document"]
    A --> B --> C --> D --> E

Manual Testing Steps

1. Confirm you are in a staging environment with test data
2. Identify race-prone operations: coupon redemption, “use credit,” “claim offer,” single-use tokens
3. Set up a parallel request test using Burp Suite’s “Send group in parallel (last-byte sync)”
4. Send 10-20 identical requests simultaneously (same session, same payload)
5. Analyze responses: how many returned success vs. error?
6. Check application state: was the action applied multiple times?
7. Document the endpoint, payload, number of parallel requests, and how many succeeded

AI-Assisted Testing

Prompt Template — Race Condition Analysis

[ROLE] Security testing assistant
[ENDPOINT] POST /api/coupons/redeem — body: {"code": "TESTCOUPON10"}
[RESULT] 20 parallel requests sent: 14 returned HTTP 200 "Coupon applied", 6 returned HTTP 400 "Already used"
[TASK] Assess this race condition test result.
  - Confirm this constitutes a race condition vulnerability
  - Calculate the business impact (e.g., value of unlimited coupon redemption)
  - Assign CVSS and provide remediation
[OUTPUT FORMAT]
  - Finding description
  - Business impact quantification
  - CVSS score
  - Remediation: database-level locking or idempotency key approach
[CONSTRAINTS] Analysis and remediation only.

AI Hard Stops for This Topic

• [NO] Never test race conditions with real financial transactions
• [NO] Staging environment only — confirm before testing
• [YES] Burp Suite parallel send is the standard low-risk testing method
• [YES] Report even partial success — even 1/20 concurrent success is a finding

Price Parameter Tampering

Purpose of the Test

Applications that trust client-supplied values for prices, quantities, discount amounts, or other financial parameters are vulnerable to tampering. If the server accepts a negative quantity or a price of $0.01, the attacker can purchase items for free or at manipulated prices.

Impact

• Purchase of goods or services for $0 or negative amounts
• Applying discounts beyond their intended limits
• Changing subscription tiers without paying the price difference
• Negative quantity exploits leading to credit balance increases

Expected Outcomes

Positive finding: Modified price, quantity, or discount value accepted by the server; order placed at manipulated price.

Clean result: All pricing calculated server-side; client-supplied price/discount values ignored; server validates against current catalog price.

Ethical Considerations

• Test only in staging with test payment methods (Stripe test mode, etc.)
• If a tampered transaction succeeds in production, reverse it immediately and report
• Do not attempt to profit from discovered vulnerabilities — even in a bug bounty context
• Hard stop: If parameter tampering causes a real financial transaction, stop, reverse if possible, and report immediately

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Staging/test payment only"]
    D["Document"]
    E["Do not profit"]
    A --> B --> C --> D --> E

Manual Testing Steps

1. Intercept a purchase/add-to-cart request via Burp Suite
2. Identify price, quantity, discount, or tier parameters in the request body
3. Modify the price to 0.01 or 0 and submit
4. Modify quantity to -1 or a very large number
5. Check if the order is processed at the modified price
6. Test the same manipulation on API endpoints directly (not just forms)
7. Verify the server re-validates price against the product catalog on checkout

AI-Assisted Testing

Prompt Template — Parameter Tampering Test Design

[ROLE] Business logic security tester
[FLOW] E-commerce checkout:
  1. POST /api/cart/add {"product_id": 123, "quantity": 1, "price": 49.99}
  2. POST /api/checkout/confirm {"cart_id": "abc", "total": 49.99}
[TASK] Identify parameter tampering opportunities in this flow.
  - Which parameters should be server-side only?
  - What modifications to test (price, quantity, discount)?
  - How to verify if the server accepts tampered values?
[OUTPUT FORMAT]
  - Tampering test matrix: Parameter | Tampered Value | Expected Secure Response | Expected Vulnerable Response
[CONSTRAINTS] Staging environment with test payment only. No real transactions.

AI Hard Stops for This Topic

• [NO] Never test with real payment methods in production
• [NO] Reverse any successful tampered transactions immediately
• [NO] Do not retain any financial benefit from a successful tamper test
• [YES] Staging with test payment credentials only
• [YES] Document the vulnerability without demonstrating full exploitation

Privilege Escalation Chain

Purpose of the Test

This tests whether combining multiple legitimate features in an unexpected sequence can elevate privileges beyond what any individual feature was designed to allow. These are multi-step bugs requiring creative thinking about feature interactions.

Impact

• Elevating from user to admin via a combination of legitimate features
• Accessing premium features without the required subscription
• Impersonating other users through invite/delegation features
• Gaining write access via a read-only feature’s side effects

Expected Outcomes

Positive finding: A sequence of legitimate API calls results in elevated access that should not be possible.

Clean result: Each feature validates authorization independently at every step; privilege checks are not bypassable through feature sequencing.

Ethical Considerations

• Test only against your own test accounts
• If escalation reaches admin or other users’ data, stop and report immediately
• Document each step of the chain — these bugs require precise reproduction steps
• Hard stop: If escalation grants access to real user data or admin functions, stop immediately

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Map feature interactions"]
    D["Test sequences in staging"]
    A --> B --> C --> D

Manual Testing Steps

1. Map all available features for each user role (regular user, premium, admin)
2. Identify invitation, delegation, impersonation, or role-assignment features
3. Test: can a regular user invite themselves to a higher-privileged role?
4. Test: does accepting an invite before validating email elevate privileges?
5. Test: can a user modify their own role via profile update APIs?
6. Document each step in the chain with exact API calls and responses
7. Test the complete chain in sequence against a test account

AI-Assisted Testing

Prompt Template — Feature Chain Analysis

[ROLE] Business logic security analyst
[FEATURES] Available API features for a regular user:
  - POST /api/invites/send (invite team members)
  - POST /api/invites/accept (accept invite to an organization)
  - PATCH /api/users/me (update own profile, including role field)
[TASK] Identify potential privilege escalation chains using these features.
  - Map unexpected interactions between these features
  - Propose test sequences to verify each potential chain
[OUTPUT FORMAT]
  - Chain hypothesis: Steps | Expected outcome if vulnerable | How to verify
[CONSTRAINTS] Analysis of feature interactions only — no automated attack sequences.

AI Hard Stops for This Topic

• [NO] Stop if privilege escalation reaches admin functions
• [NO] Stop if the chain exposes other users’ data
• [YES] Document each step precisely — these findings require careful reproduction steps

Account Takeover Flows

Purpose of the Test

Account takeover (ATO) logic bugs occur in the flows designed to help users recover access — password reset, email change, account recovery. Flaws in these flows are especially severe because they bypass authentication entirely.

Impact

• Complete account takeover via manipulated password reset links
• Account hijacking by changing the recovery email before verification
• Exploiting host header injection in password reset emails
• Pre-account-takeover via registering an account before the victim

Expected Outcomes

Positive finding: Password reset link doesn’t expire, reset token is predictable, email change not verified, host header injection in reset email, pre-registration possible.

Clean result: Reset tokens are cryptographically random, single-use, and expire quickly; email changes require verification from the old email; reset tokens invalidated after use.

Ethical Considerations

• Only test ATO flows against your own test accounts
• Never attempt to take over real user accounts — even to demonstrate the vulnerability
• If host header injection redirects a reset email to attacker-controlled domain, document the behavior without capturing real user tokens
• Hard stop: Any path to a real user’s account takeover — stop immediately and report

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Two-account controlled test"]
    D["Document"]
    A --> B --> C --> D

Manual Testing Steps

1. Test password reset token entropy: request multiple resets and compare tokens for patterns
2. Test token expiry: request a reset, wait 24 hours, use the link — does it still work?
3. Test token reuse: use a reset link, reset the password, use the same link again
4. Test host header injection: intercept the reset request, modify the Host header to attacker.example.com
5. Test email change flow: does changing email require confirmation from the old email?
6. Test parallel reset requests: request two resets simultaneously — which token works?
7. Test pre-account-takeover: register an unactivated account with the victim’s expected email

AI-Assisted Testing

Prompt Template — ATO Flow Review

[ROLE] Authentication security specialist
[PASSWORD RESET FLOW]
  1. POST /api/auth/forgot-password {"email": "user@example.com"}
  2. Email sent with link: https://app.example.com/reset?token=TOKEN
  3. POST /api/auth/reset-password {"token": TOKEN, "new_password": "..."}
[TASK] Identify security weaknesses in this password reset flow.
  - Token entropy and expiry
  - Host header injection risk
  - Token reuse and invalidation
[OUTPUT FORMAT]
  - Weakness checklist with severity
  - Safe test for each weakness
  - Remediation per weakness
[CONSTRAINTS] Safe test methods only — no actual account takeover attempts.

AI Hard Stops for This Topic

• [NO] Never attempt to take over a real user’s account
• [NO] Do not capture real password reset tokens
• [YES] All tests against your own test accounts only
• [YES] Document the vulnerability pattern without completing the full takeover chain

Resources

• OWASP Testing Guide — Authentication
• PortSwigger Business Logic Labs
• HackerOne Hacktivity — Logic Bugs