API6:2023 - Unrestricted Access to Sensitive Business Flows

Unrestricted Access to Sensitive Business Flows happens when an API exposes a valid business action but does not include enough protection against repeated, automated, or abusive use.

The requests themselves may be valid. The problem is that the flow can be abused in a way that violates business rules and creates unfair or harmful outcomes.

This issue appears when an API implements a valid business flow, but does not add enough controls to stop replay, abuse, or excessive repetition.

Typical weak points include coupon redemption, reservation flows, reward claims, bonus issuance, checkout steps, and other actions that transfer value.

Core Issue

# vulnerable
@app.post("/api/coupons/redeem")
def redeem(payload, claims=Depends(current_claims)):
    email = claims["email"]
    wallet = WALLETS[email]

    if payload.code == "WELCOME10":
        wallet["credits"] += 10
        wallet["redeems"] += 1
        return {
            "status": "ok",
            "credits": wallet["credits"],
            "redeems": wallet["redeems"],
        }

Correct Direction

# safer
@app.post("/api/coupons/redeem")
def redeem(payload, claims=Depends(current_claims)):
    email = claims["email"]

    if already_redeemed(email, payload.code):
        raise HTTPException(status_code=409, detail="Coupon already used")

    enforce_coupon_rate_limit(email)
    mark_coupon_redeemed(email, payload.code)
    apply_coupon_credit(email, payload.code)

    return {"status": "ok"}

Key concept: the action may be allowed once, but that does not mean it is safe to allow unlimited identical replays.

From an attacker’s perspective, API6 is about finding a valid business action that transfers value and then repeating it faster or more often than the business intended.

• Find a flow tied to money, balance, rewards, or inventory.
• Execute it once and confirm the normal effect.
• Replay the same action with identical input.
• Measure whether value keeps accumulating.

If the same valid request keeps producing value without safeguards, the business flow is vulnerable.

This benchmark models a coupon redemption API where a normal authenticated user can redeem the same promotion repeatedly to inflate wallet credits.

Relevant routes in the benchmark:

• POST /api/auth/login issues a valid token.
• POST /api/coupons/redeem applies coupon value to the user wallet.
• GET /api/wallet returns wallet state and unlocks VIP reward data at high credit totals.

The important point is that the user is allowed to redeem coupons as a normal customer. The vulnerability is that the same coupon can be replayed indefinitely without one-time usage enforcement.

Example endpoint:

Expected behavior: a promotional coupon such as WELCOME10should be redeemable only within business-safe constraints.

Vulnerable Logic

if payload.code == "WELCOME10":
    wallet["credits"] += 10
    wallet["redeems"] += 1
    return {
        "status": "ok",
        "credits": wallet["credits"],
        "redeems": wallet["redeems"],
    }

• Coupon Replay: the same discount or reward code can be redeemed repeatedly.
• Bonus Claim Abuse: a sign-up or loyalty reward can be triggered multiple times.
• Reservation Hoarding: valid booking actions are repeated until capacity is monopolized.
• Promotion Farming: business incentives are exhausted by automation rather than normal customer use.

1. Treat sensitive business actions as stateful

If an action should only happen once, the backend must remember that state and reject repeats explicitly.

2. Enforce replay resistance

Repeated submissions of the same business event should not keep producing value.

def redeem_coupon(email, code):
    if already_redeemed(email, code):
        raise HTTPException(status_code=409, detail="Coupon already used")

    mark_coupon_redeemed(email, code)
    apply_credit(email, code)

3. Use idempotency and flow-safe validation

For value-transferring actions, identical requests should not create multiple business outcomes unless that is explicitly intended.

4. Add anti-automation and rate controls

Sensitive flows need quotas, cooldowns, velocity checks, or other friction mechanisms even for authenticated users.

5. Monitor business outcomes, not just request success

Track wallet spikes, repeated reward claims, and unusual redemption patterns. Business abuse often looks technically normal unless you measure outcomes.

Detecting API6 requires testing whether a valid business action can be repeated to produce business value beyond intended limits.

Common techniques:

• Find flows that transfer balance, rewards, inventory, or access.
• Execute the action once to establish a baseline.
• Replay the same request with identical parameters.
• Observe whether value keeps accumulating.
• Look for missing one-time checks, idempotency, or rate controls.

API6 is about business harm caused by unrestricted use of a valid workflow.

It exists whenever:

• A value-transferring flow can be replayed without restriction.
• The API allows business abuse through repeated valid requests.
• One-time or limited actions are not enforced server-side.
• Technical correctness hides operational harm.

Every sensitive workflow should answer: If this action is repeated with valid input, does the business still behave safely?

If the answer is no, the API is exposed.