Will It Vibe?SQL query built directly from request data
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
A cursor execute() call builds its SQL text with an f-string, %-formatting, .format(), or concatenation where the interpolated value is request.args/form/values/json/data itself, confirming the query is attacker-controlled rather than merely dynamic. This is SQL injection.
Why it matters
Building SQL text with an f-string or %-formatting where the interpolated value is request.args, request.form, or similar means the database driver receives attacker-controlled text as part of the query itself, not as a bound parameter. A value like ' OR '1'='1 or a stacked statement can read, modify, or delete data the query was never meant to touch, and because the value is confirmed to come directly from the request, this is not a maybe, it is exploitable as written.
How to fix it
Pass the request value as a parameter to execute() instead of interpolating it into the string: cursor.execute("SELECT * FROM users WHERE id = %s", (request.args.get("id"),)) for most DB-API drivers, or the equivalent named-parameter style for your driver/ORM. If the project uses an ORM (SQLAlchemy, etc.), use its query-building API instead of raw SQL entirely.
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