Resource budgets and sensitive business flows

Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.

Used in these playbooks#

Identify the unit that must be bounded#

An HTTP request can fan out into database queries, recipient notifications, reservations, image conversions, token generation, or recurring background work. Name the scarce resource and the authority that should own its budget: actor, tenant, recipient, workflow, or global service. A request-per-second limit does not necessarily constrain those downstream units. OWASP distinguishes unrestricted resource consumption from excessive use of sensitive business workflows; both need a concrete product-specific impact. API4, API6.

Build a small cost map before a test. For each entry point record accepted input size, batch cardinality, query/page complexity, queued jobs, retries, output size, and billed provider calls. Include failed requests: validation after a notification or job enqueue can return an error after consuming the protected resource. Use the state and business logic module for one-time transitions and the API protocol module for per-operation behavior.

Controlled procedure#

1. State the business rule. Specify the prohibited outcome, such as more than two notifications to one synthetic recipient per lab window, or a member reserving an object after their allocation is exhausted. A missing CAPTCHA or rate-limit header alone is not the outcome.
2. Prepare a faithful local deployment. Replace email, SMS, payments and model providers with recording stubs. Use supported configuration to reduce a real limit to a small lab value when possible. Record the configuration difference. Do not introduce a new guard or a fabricated endpoint and claim it represents the original application.
3. Establish accepted and rejected controls. Exercise a permitted request and one documented over-limit case. Inspect actual downstream events and final state alongside the response. If the protected limit does not exist, bound the observation through source analysis and an isolated fixture; do not seek a production outage.
4. Change one dimension. Compare a single operation with a small batch; the same actor through two permitted entry points; an original event with a duplicate; or a queued operation before and after its reservation expires. Keep the recipient, tenant, and resource ownership under your control. Test concurrency only when required to distinguish a non-atomic counter, using a local two-worker harness.
5. Measure work and isolation. Record request count, accepted operation count, provider-stub count, bytes, task retries, and the budget's key. Check whether tenant A can consume tenant B's allocation or cause B's valid request to be rejected. A shared quota can be intentional; use the stated product rule.
6. Reset and minimize. Cancel pending jobs, release synthetic reservations, clear only the dedicated fixture's state, and replay the smallest sequence. Recheck that a legitimate operation still works after the counter expires or allocation is restored.

Local command card#

The following is an adaptable request recipe, not a runnable application. Prepare lab/baseline.json, lab/at-limit.json, and lab/over-limit.json using the product's real request schema; create a header file with a synthetic lab token. Replace /api/exports with the reviewed local endpoint. Confirm the application uses recording stubs and that all three cases fit the agreed tiny experiment before running it.

mkdir -p evidence
for lab_case in baseline at-limit over-limit; do
  curl -q --noproxy '*' --proto '=http' \
    --connect-timeout 2 --max-time 10 --max-filesize 65536 \
    --request POST --header @lab/authorization.header \
    --header 'Content-Type: application/json' \
    --data-binary "@lab/${lab_case}.json" \
    --dump-header "evidence/${lab_case}.headers" \
    --output "evidence/${lab_case}.body" \
    'http://127.0.0.1:8000/api/exports' || break
done

This sends at most three sequential requests and does not follow redirects. It does not reset state, enforce the server's budget, or prove a limit. Capture the application's worker and stub logs separately. A transport failure stops the loop and must be recorded as blocked; HTTP error responses remain available for interpretation. If each case requires a fresh counter, restore the fixture between cases instead of running the loop as written. curl options.

Evidence, false positives, and completion#

Keep the expected budget, configuration, identities, input sequence, counter key, downstream effects, and valid control together. Demonstrated local resource amplification may support an impact argument; projected production cost remains an extrapolation until deployment and pricing assumptions are established. A few accepted requests below an unknown threshold do not prove unlimited access. A slow response is not proof of denial of service, and standard product automation may be intended.

• The protected resource or business allocation and intended owner are explicit.
• Real integrations are stubbed; no uninvolved recipient, customer, or bill is affected.
• The accepted control and over-limit control use the same relevant configuration.
• Downstream work is counted even when the HTTP response indicates rejection.
• Batch size, retries, async processing, and identity/tenant budget keys are considered.
• The minimal observation and any cost extrapolation are clearly separated.
• Pending work and fixture state are restored, with a legitimate operation retested.

Vulnerability reverse references#

• Unbounded resource allocation or request amplification — An operation consumes an unconstrained protected resource through input size, fan-out, queued work, output size or retries.
• Sensitive business flow exceeds its permitted frequency or allocation — An actor exceeds an intended recipient, reservation, workflow or tenant allocation through repeated otherwise valid operations.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity