Skip to content
BuildThenTestedSee packages

Unbounded input length to the model

One oversized paste costs as much as thousands of normal requests, and a burst of them uses up your provider rate limit so real users see errors. Calls to a language model inside the app, and what they can trigger. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

// POST /api/summarise
const { text } = await req.json();            // any size accepted
const out = await anthropic.messages.create({
  model: MODEL, max_tokens: MAX_ALLOWED,
  messages: [{ role: "user", content: text }],
});
A route that forwards whatever the request contains to the model, with no cap on input size and the output allowance (max_tokens, the most text the model may return) set to the maximum.

What happens

One oversized paste costs as much as thousands of normal requests, and a burst of them uses up your provider rate limit so real users see errors.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

  1. Open the AI feature in your app and paste an unusually long text, for example a whole book chapter copied several times, then submit.
  2. Note whether the app refuses, trims or sends it. In developer tools (F12), the Network tab shows the request size in the Size column.
  3. Ask the builder's chat where the input length is checked on the server and what max_tokens the model call uses.
  4. Bad result: the request is sent unchanged, no server-side length check exists, and the output limit is set to the model's maximum.

What we check

We send inputs of increasing size and concurrency to each model route, record cost per request from the provider's usage fields, and note the point where the route starts returning rate-limit errors to other users.

Fix direction

Reject or truncate inputs above a sensible character limit on the server, set max_tokens to what the feature needs, and count tokens before sending where the provider offers it. Pair this with a per-user quota so one account cannot consume the shared allowance.

Mechanism documented in: LLM10:2025 Unbounded Consumption (verified 2026-09-21); Rate limits (verified 2026-09-21).

Covered by

Ready-to-charge check ($390, 48 hours) and Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

  • No spend cap on model callsAI features

    A script can hit the route in a loop overnight and the bill lands on your card, or the provider pauses your account mid-day when its own cap trips and every user sees errors.

    High
  • No rate limiting on sensitive routesReliability

    A script can try thousands of passwords against your login form, hammer a form that sends emails or calls a paid API, or knock the app over, and the bill lands on you.

    High
  • List endpoints that return everythingPerformance

    As the table grows, the response gets slower and heavier until it hits a platform body-size or time limit and the page simply stops loading, usually for your biggest customer first.

    Medium
  • LLM API key exposed to the clientAI features

    Anyone who views the page source can copy the key and run their own workloads on your account until the bill or the provider stops them.

    Critical

Questions

limit input size llm api

OWASP's guidance on unbounded consumption calls for strict input validation so inputs do not exceed reasonable size limits. In practice that is a character or token cap enforced on the server before the provider call, with a clear message to the user. The client-side field limit alone does not count, since requests can be sent without the form.

llm denial of wallet

Denial of wallet is OWASP's term for driving up a pay-per-use bill on purpose by sending many or oversized requests. The defences are the same as for accidental overuse: input size caps, output caps, per-user quotas, rate limiting and a spend limit in the provider console.

why does one request use my whole rate limit

Providers meter input and output tokens per minute, so a single request carrying a huge document can consume most of the minute's allowance and push other users' requests into errors. Anthropic's rate limit docs describe these per-minute token limits. Capping input size keeps one user's request from crowding out the rest.

Back to the catalogue, or run the self-check for your stack.