Unbounded list query
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
A find/select query with no limit/pagination can return unbounded result sets as data grows.
Why it matters
A query that fetches an entire table works fine with the 50 rows you have in dev, then one day production has 200,000 and every request loads them all into memory, times out, or knocks over the database. These are the slowdowns that appear months after launch with no code change. Bounding the query now is cheap; doing it during an incident is not.
How to fix it
Add an explicit limit and pagination to every list query: .find({}).limit(n) with cursor or skip pagination in Mongoose/MongoDB, LIMIT with OFFSET or keyset pagination in SQL, and select the specific columns the caller needs instead of *. Expose limit and cursor parameters on the API routes that serve these queries, with a sane default and a hard maximum.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo