Always set explicit timeouts. Use a short connect timeout, a total request timeout sized to what the user is waiting for, a cap on response size, and a strict redirect limit. With no timeout, a slow vendor holds your threads open and a vendor problem becomes your outage.
Why timeouts are a security topic
OWASP's API Security Top 10 lists unsafe consumption of APIs as a risk. Among the signs it gives that an API may be vulnerable: it does not limit the number of resources available to process third party responses, it does not implement timeouts for interactions with third party services, and it blindly follows redirections. It also notes that developers tend to trust data from well known companies more than user input, and so adopt weaker standards for validation.
A missing timeout is a denial of service waiting to happen. A vendor having a bad day, or an attacker who controls a webhook target or redirect, can tie up your workers.
The four limits to set
| Limit | Purpose | Typical approach |
|---|---|---|
| Connect timeout | Fail fast when the host is unreachable | A few seconds |
| Read or total timeout | Bound how long one call can take | Match the user's patience |
| Response size cap | Stop a huge reply exhausting memory | Set a maximum and abort above it |
| Redirect limit and allowlist | Avoid being steered to unexpected hosts | Zero or very few, only to known domains |
Specific numbers depend on your service, so measure first. Profile the vendor's real latencies, as one payment provider suggests, and set timeouts above normal peaks but well below your own request deadline.
Match timeouts to what the user sees
- Interactive checkout. The customer is waiting. Pick a total budget, such as a handful of seconds, then show a pending state and reconcile. See what to do when a payment times out.
- Background jobs. Longer timeouts are fine, with retries and a dead letter queue.
- Webhook handlers. Do not call slow vendors inline at all. Queue the work, as in why an endpoint should answer in seconds.
Budgets beat per call timeouts alone
If a page makes three vendor calls with ten second timeouts, the user could wait thirty seconds. Set an overall deadline for the request and pass the remaining time down to each call.
Retries and timeouts together
A timeout is not a verdict. For writes, retry only with an idempotency key, or reconcile. For reads, retry with backoff and jitter. Cap the attempts. Add a circuit breaker so that after repeated failures you stop calling for a short time and serve a degraded response. More in retry storms.
Validate what comes back
Even after a successful response, treat vendor data as untrusted input. OWASP's prevention advice is to use TLS, validate and sanitize data from integrated APIs before use, and keep an allowlist of known redirect locations. Check types, lengths and ranges. Do not render vendor supplied text as HTML without escaping.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how weak points in API handling show up as findings.
Where Safeguard fits
Safeguard's dependency scanning covers the HTTP client libraries that implement these limits, and its policies and gates help keep vulnerable versions out. A free scan is one way to start.
Quick check
Is the default timeout in my HTTP library enough?
Often not. Some libraries have no default total timeout. Set connect and total timeouts explicitly.
Should I follow redirects from a vendor API?
Only to a short allowlist of known locations. OWASP advises against blindly following redirects.
Sources
- API10:2023 Unsafe Consumption of APIs, OWASP API Security Top 10
- Rate limits, Stripe documentation
Last reviewed: 19 October 2026.
