ASVS 5.0 V13.1.2 requires documentation that sets, for each service the app uses, the maximum number of concurrent connections and the behavior when that limit is reached, including fallback or recovery. It is a Level 3 requirement, aimed at preventing denial of service.
Why it matters
An unbounded pool lets a traffic spike open thousands of database connections and take the database down for everyone. A bounded pool with no defined behavior just moves the failure: requests queue forever and threads pile up.
How to implement it
Write down, per dependency, the pool size, the wait timeout, and what callers see when the pool is exhausted. Then configure the code to match.
- service: orders-db
max_connections: 20
acquire_timeout: 2s
on_exhaustion: fail fast with 503 and Retry-After
recovery: pool refills as connections return
HikariCP in Java:
maximumPoolSize=20
connectionTimeout=2000
Make the sum across all replicas fit under the database's own limit, and leave room for admin connections.
How to test it
Run a load test that exceeds the limit and watch for the documented behavior: quick 503 responses, no hung threads, and recovery when load drops.
Common mistakes
- Pool size copied from a tutorial and never compared to the database maximum multiplied by replica count.
- Infinite acquire timeout.
- Documentation that says "retry" with no limit.
Quick check
What must the document say about a full pool?
What the application does at that point and how it recovers, for example fail fast with a clear error.
