T09 · Insecure Skill Coding Practices
Error
- Location
scripts/supabase.sh:231- Finding
Mutation Safety Guard Accepts Non-Predicate Query Options
- Content
View full analysis
&2 exit 1 fi local url="${REST_URL}/${table}?${filters:1}" api_request PATCH "$url" "$data" | jq . ``` The delete operation uses the same insufficient check: ```bash local filters filters=$(build_filters "$@") if [[ -z "$filters" ]]; then echo "Error: At least one filter required for delete (use --eq)" >&2 exit 1 fi local url="${REST_URL}/${table}?${filters:1}" api_request DELETE "$url" | jq . ``` ### Technical Analysis The update and delete commands claim to require a row filter, but the implementation only checks whether `build_filters` returned any query-string content. Options such as `--limit`, `--offset`, and `--order` can produce a nonempty string without creating a predicate that restricts rows by column value. Consequently, modifier-only commands can pass the safety check. For example, `delete users --limit 100` produces a nonempty query string even though no `eq`, `neq`, `gt`, `lt`, or other row predicate is present. The problem is especially serious because the request is authenticated with a Supabase service-role key, which bypasses Row Level Security. The server's precise handling of modifiers on update and delete requests depends on the PostgREST configuration and ...[truncated 1401 chars]- Remediation
View remediation
&2 exit 1 fi ``` ]]>