T09 · Insecure Skill Coding Practices
- Location
scripts/supabase.sh:229- Finding
Mutation Safety Guard Can Be Bypassed Without a Row Predicate
- Content
View full analysis
&2 exit 1 fi local url="${REST_URL}/${table}?${filters:1}" api_request PATCH "$url" "$data" | jq . ``` ```bash # Delete from table 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 safety checks for `update` and `delete` only verify whether `build_filters` returned a nonempty query string. They do not verify that the string contains a row-selection predicate. Non-predicate options such as `--order`, `--limit`, or `--offset` can make the query string nonempty. In particular, `--order` produces an `order=...` parameter but does not constrain which rows match the request. Consequently, the script may send a `PATCH` or `DELETE` operation that applies to every row exposed by the target table. This contradicts the command documentation, which states that update and delete operations require an `-- ...[truncated 1488 chars]- Remediation
View remediation
&2 exit 1 fi ``` ]]>
