CWE-1060 is about a product that makes too many data queries without using efficient processing such as stored procedures. It hits any application with a database behind it, especially those built on an ORM where each property access can quietly run a query.
How it happens
A function loops over a list and issues a query for each item. Fifty items, fifty round trips. MITRE notes that what counts as "too many" varies by product, and that CISQ recommends a default maximum of 5 data queries for an inefficient function or procedure.
# Pattern to avoid: one query per order
for order_id in order_ids:
rows = db.execute("SELECT * FROM items WHERE order_id = %s", (order_id,))
# Better: one query for the whole set
rows = db.execute(
"SELECT * FROM items WHERE order_id = ANY(%s)", (order_ids,)
)
What an attacker gains
MITRE lists reduced performance due to computational expense. If an attacker can reach the code, the slowdown "might introduce a vulnerability." A request that triggers hundreds of queries is cheap to send and costly to serve.
How to find it
The record lists no detection methods. Turn on query logging in a test environment and count queries per request. Any endpoint whose query count grows with the input size is a candidate.
How to fix it
- Replace loops of queries with a single set-based query or a join.
- Move heavy multi-step data work into a stored procedure when it fits your design.
- Cap the size of lists a caller may submit.
Quick check
What default threshold does MITRE cite?
CISQ recommends a default maximum of 5 data queries for an inefficient function or procedure, though interpretation varies by product.
