DB facade raw statement built from a variable
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
DB::select(), DB::statement(), and DB::unprepared() run their SQL string as-is. A $variable inside the SQL string argument itself (as opposed to a ? placeholder with a separate bindings array) means request-influenced data can change the query's structure, not just its values.
Why it matters
DB::select(), DB::statement(), and DB::unprepared() execute the SQL string exactly as given. A variable spliced into that string, rather than passed through the bindings array, lets request-influenced data change the query's structure rather than just one of its values, which is SQL injection.
How to fix it
Use the placeholder-plus-bindings form these methods already support: DB::select('select * from users where id = ?', [$id]) instead of DB::select("select * from users where id = $id"). DB::unprepared() does not support bindings at all, so it should only ever run a fixed string with no variables.
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