A query that is fine on a thousand rows can bring a database to its knees on a hundred million.
CWE-1049 describes a product that performs a data query with a large number of joins and subqueries on a large data table. MITRE lists it as a Base weakness in any language.
How it happens
Reporting screens, search endpoints and export features tend to grow complicated queries over time. Each new requirement adds another join or a nested select.
MITRE says the meaning of large table and large number of joins or subqueries varies, and notes the CISQ defaults: 1 million rows for a large table, at least 5 joins, and at least 3 subqueries.
SELECT o.id, c.name, a.city, p.total, s.status
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN addresses a ON a.id = o.address_id
JOIN payments p ON p.order_id = o.id
JOIN shipments s ON s.order_id = o.id
JOIN products pr ON pr.id = o.product_id
WHERE o.id IN (SELECT order_id FROM returns WHERE reason IN (SELECT code FROM reasons));
The recorded consequence is reduced performance. If the relevant code is reachable by an attacker, that performance problem might introduce a vulnerability. An unauthenticated endpoint that triggers such a query on request is an easy way to exhaust the database. No CVEs are observed.
How to find it
MITRE lists no detection methods. Check query plans, slow query logs and database monitoring. Review endpoints that accept search or filter parameters.
How to fix it
MITRE lists no formal mitigations. Reasonable steps:
- Add indexes that match the filters and joins.
- Break one huge query into smaller ones or precompute results.
- Paginate and cap result sizes.
- Apply rate limits and authentication to expensive endpoints.
- Test with production sized data.
Quick check
Why does this matter for security?
If an attacker can trigger the expensive query repeatedly, the slowdown can become a denial of service.
