Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →supabase/safe-sql-execution
Use whenever code will build, return, fetch, or execute SQL that runs against a user's real Postgres database — even when the request reads like an ordinary feature or bug fix and never says "security," "injection," or "SafeSqlFragment." This covers: writing or editing any pg-meta function, query builder, or endpoint that builds/returns SQL for database objects (tables, views, functions, DB triggers, indexes, RLS policies); interpolating a schema/table/column/search/route-param value into SQL te
Passed 20 of 22 test cases with the skill, and 6 of 22 without it.
and 18 more in the full report
14 fixed6 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
In a Supabase Studio search view, I receive an unverified filter string directly from `searchParams.get('filter')`. I need to mark this string as untrusted for tracking before passing it to display utilities. Provide the TypeScript snippet to wrap this search parameter.
| Checked | Without skill | With skill |
|---|---|---|
| Imports untrustedSql from @supabase/pg-meta. | Missed | Passed |
| Wraps the search parameter string with untrustedSql. | Missed | Passed |
The instructions your model reads when the skill loads.
Supabase Studio executes SQL statements directly against the user's database. Because this is the authenticated user's own database, our security model is different from most frontend applications: a user should be able to execute any SQL statement, as long as it is proven that they themselves authored it. What we SHOULD NOT ALLOW is execution of SQL statements that can be influenced by an attacker, such as through URL parameters.
The security model for SQL execution in Supabase Studio is based on the principle of "proven authorship". This means that a user should only be able to execute SQL statements that they have explicitly authored, and not statements that can be influenced by external input.
There are three classes of SQL fragments:
Hardcoded within the application code. These are safe to execute because
they cannot be influenced by an attacker. They can be marked with the
safeSql utility with pg-meta:
import { safeSql } from '@supabase/pg-meta'
const sql = safeSql`
SELECT *
FROM users
WHERE id = 1
`
safeSql automatically creates a string of the branded type
SafeSqlFragment. (See Provenance Tracking below.)
Third-party influenceable. These are SQL fragments that can be influenced
by an attacker, such as through URL parameters or LLM output. These should
be marked with the untrustedSql utility with pg-meta:
test cases passed, vs 6 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.