CWE-1094, Excessive Index Range Scan for a Data Resource, applies when a product contains an index range scan for a large data table, but the scan can cover a large number of rows.
MITRE notes that the definition of large depends on the team. The CISQ standard recommends thresholds of 1000000 table rows and an index range of 10. MITRE marks the entry as a quality issue with no direct security implications, and prohibits it for mapping real vulnerabilities.
How it happens
A query filters on a range, such as dates or ids, and the range is not bounded tightly. On a small table that is fine. On a table with millions of rows, the database walks through a large slice of the index on every call.
-- Smell: caller controls both ends of the range, no upper limit on width
SELECT * FROM events
WHERE created_at BETWEEN :start AND :end
ORDER BY created_at;
If a request lets the user pick any start and end, one call can ask for the whole table.
What an attacker gains
MITRE lists reduced performance, and notes that if an attacker can reach the code, the performance problem might introduce a vulnerability. The realistic one is denial of service by expensive query: a few wide range requests keep the database busy and starve other users.
How to find it
- Review queries with range filters on large tables, especially those driven by request parameters.
- Look at the database query plan and at slow query logs for scans that touch many rows.
- Load test with the widest range your API accepts.
How to fix it
- Cap the range width a caller can request.
- Paginate results and always apply a row limit.
- Make sure the range column has a suitable index, and use keyset pagination for deep paging.
- Set statement timeouts in the database, so no single query runs unbounded.
- Rate limit endpoints that run heavy queries.
Quick check
How can a user control the cost of a range query?
If the API accepts arbitrary start and end values with no limit, a caller can request nearly the whole table in one call.
