Laravel SQL injection: request input as column name
Rule ID: vetkit.php.sql-injection.laravel-column-name
Request input is used as a column / table name in a Laravel query-builder call (orderBy, where, select, pluck …). PDO cannot bind identifiers, so Laravel only wraps them; an attacker can sort or filter by hidden columns (password hashes, tokens) and, on some grammars, break out of the wrapping (SQL injection).
Last updated:
Suite: Security
php
Request input is used as a column / table name in a Laravel query-builder call (orderBy, where, select, pluck …). PDO cannot bind identifiers, so Laravel only wraps them; an attacker can sort or filter by hidden columns (password hashes, tokens) and, on some grammars, break out of the wrapping (SQL injection).
Category: SECURITY · Engine rule severity: WARNING
How to fix it
Map the requested column to an allow-list (match / in_array with a fixed list, or a validation rule such as Rule::in([...])) and pass the mapped constant to the builder; never pass request values as identifiers.
References
Source: packages/engine/rules/sast/php.yml.
Related checks
- PHP Doctrine DQL SQL injection from request input
- Laravel SQL injection in DB::raw, whereRaw, orderByRaw
- PHP SQL injection: query built from request input
- WordPress $wpdb->prepare() SQL injection in format string
- WordPress $wpdb query SQL injection without prepare()
- PHP loose == hash comparison: type juggling auth bypass
Check your own repository for this
vetkit runs this rule as part of a repository audit, alongside secret scanning, dependency vulnerabilities, code quality and AI code risk checks. It reads a temporary checkout and never executes your code.
Start with the free Security Quick Scan · See how the platform works
Generated from shipped rule definitions at build time. Matching is a review signal, not proof of exploitability. “generic” denotes text matching, not complete language or framework coverage. Runtime configuration and available tools affect whether a rule runs.