Fix sQL query built by string interpolation in SolidStart
A SQL string is assembled with a template literal or concatenation and passed to a database driver. Any value interpolated into it is executed as SQL, so a request parameter can read, modify, or destroy data the query was never meant to touch. Use the driver's parameter binding instead; every driver has it.
high likely SolidStart CWE-89 / OWASP A03:2021
The vulnerable pattern in SolidStart
This finding comes from the SolidStart fixture in the owlwarden test
suite, in /api/session.
A value taken from the request is interpolated into SQL, so the caller controls part of the statement. That is enough to read other users' rows, bypass a WHERE clause, or drop a table.
The corrected handler
Bind the value as a parameter in the API route.
const rows = await pool.query('SELECT id, role FROM users WHERE email = $1', [body.email])
If you are not using SolidStart
Pass the values as query parameters instead of interpolating them. Every driver supports it, and the binding is not optional formatting - it is what stops the value being parsed as SQL.
Check your own repository
npx owlwarden scan
npx owlwarden explain sql-injection
Runs on your machine. No account, no telemetry, no network unless you ask. In CI, SARIF uploads to code scanning and the exit code is the gate.
Other SolidStart checks
Rules with a tested SolidStart example.
- cors-permissive medium Cross-origin policy accepts any origin
- hardcoded-secret high Credential hardcoded in source
- insecure-cookie medium Cookie set without its protective attributes
- install-lifecycle-script medium Package declares an install-time script
- open-redirect medium Redirect target comes from the caller
- security-headers-missing medium Security headers are not configured
- sensitive-data-logged medium Sensitive data written to a log
- ssrf high Server fetches a URL the caller controls
- stack-trace-leak high Stack trace leaked in error response
- weak-crypto high Broken cryptographic primitive protecting a secret