Describe the bug
GET /api/city does not guard against non-numeric from or to query parameters. Invalid values can become NaN and then flow into the Supabase range call.
Source proof
In src/app/api/city/route.ts:
from is calculated as Math.max(0, parseInt(searchParams.get("from") ?? "0", 10)).to is calculated with Math.min(from + 1000, parseInt(searchParams.get("to") ?? "500", 10)).- If
from=abc, parseInt("abc", 10) is NaN, and Math.max(0, NaN) is also NaN.
- The route then calls
.range(from, to - 1) with invalid numeric values.
A malformed request like /api/city?from=abc&to=500 should not be able to push NaN into the database query layer.
Expected behavior
Invalid pagination values should either default to safe bounds or return a 400 response before building the Supabase query.
Why this does not need screenshots
The bug is fully reproducible from the query parsing and range call in the API route.
Describe the bug
GET /api/citydoes not guard against non-numericfromortoquery parameters. Invalid values can becomeNaNand then flow into the Supabase range call.Source proof
In
src/app/api/city/route.ts:fromis calculated asMath.max(0, parseInt(searchParams.get("from") ?? "0", 10)).tois calculated withMath.min(from + 1000, parseInt(searchParams.get("to") ?? "500", 10)).from=abc,parseInt("abc", 10)isNaN, andMath.max(0, NaN)is alsoNaN..range(from, to - 1)with invalid numeric values.A malformed request like
/api/city?from=abc&to=500should not be able to pushNaNinto the database query layer.Expected behavior
Invalid pagination values should either default to safe bounds or return a 400 response before building the Supabase query.
Why this does not need screenshots
The bug is fully reproducible from the query parsing and range call in the API route.