# 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.

## Investigation sequence

1. Name the protected resource
2. Prepare recording stubs
3. Establish limit controls
4. Vary one budget dimension
5. Count committed work
6. Restore and retest

## Used in these playbooks

[Web & API](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/web-api.html) · [OSS & self-hosted](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/oss.html) · [Cloud & containers](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/cloud.html) · [AI, agents & MCP](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/ai.html)

## 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](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/), [API6](https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/).

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](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/state-business-logic.html) for one-time transitions and the [API protocol module](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/api-protocols.html) 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.

```bash
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](https://curl.se/docs/manpage.html).

## 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](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/resource-allocation-limit-failure.html) — 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](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities/sensitive-flow-frequency-limit.html) — An actor exceeds an intended recipient, reservation, workflow or tenant allocation through repeated otherwise valid operations.