T09 · Insecure Skill Coding Practices
- Location
scripts/supabase.sh:165- Finding
Update and delete safeguards accept non-predicate options
- Content
View full analysis
&2 exit 1 fi local url="${REST_URL}/${table}?${filters:1}" api_request PATCH "$url" "$data" | jq . ``` ```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 protections only verify that the complete query-string fragment returned by `build_filters` is nonempty. They do not verify that the arguments include an actual row-selection predicate. Non-predicate options such as `--limit` generate a nonempty string and therefore satisfy the safety check. Ordering can also contribute query-string content when combined with applicable options. Consequently, the error message claims that a filter such as `--eq` is required, but the implementation does not enforce that requirement. Because every request is authenticated with `SUPABASE_SERVICE_KEY`, these mutations execute with a service-role credential that normally bypasses Supabase Row Level Security. The failure is therefore more consequential than the same validation flaw under an unprivileged credential. ### Attack Path 1. An attacker influences a natural-language database request, automation input, or arguments passed to ...[truncated 1013 chars]- Remediation
View remediation
