T09 · Insecure Skill Coding Practices
- Location
scripts/supabase.sh:5- Finding
Privileged Supabase credentials can be transmitted to an arbitrary or plaintext endpoint
- Content
View full analysis
&2 exit 1 fi if [[ -z "${SUPABASE_SERVICE_KEY:-}" ]]; then echo "Error: SUPABASE_SERVICE_KEY not set" >&2 exit 1 fi REST_URL="${SUPABASE_URL}/rest/v1" RPC_URL="${SUPABASE_URL}/rest/v1/rpc" ``` ```bash # Make API request api_request() { local method="$1" local endpoint="$2" local data="${3:-}" local extra_headers=("${@:4}") local args=( -s -X "$method" -H "apikey: ${SUPABASE_SERVICE_KEY}" -H "Authorization: Bearer ${SUPABASE_SERVICE_KEY}" -H "Content-Type: application/json" -H "Prefer: return=representation" ) for header in "${extra_headers[@]:-}"; do [[ -n "$header" ]] && args+=(-H "$header") done if [[ -n "$data" ]]; then args+=(-d "$data") fi curl "${args[@]}" "$endpoint" } ``` ### Technical Analysis `SUPABASE_URL` is only checked for emptiness. The script does not parse the value, require HTTPS, reject embedded credentials, or verify that the destination is an expected Supabase project. Every API request places `SUPABASE_SERVICE_KEY` in both the `apikey` and bearer authorization headers. Consequently, if the environment variable is maliciously or accidentally configured with an attacker-controlled URL, the privileged key is sent directly to that server. An `http://` URL would additionally expose the key and request data to network interception. This is especially sensitive because the documentation states that the service-role key bypasses Supabase Row Level Security. ### Attack Path 1. An attacker gains influence over the process environment, deployment configuration, `.env` source ...[truncated 1359 chars]- Remediation
View remediation
&2 exit 1 ;; esac ``` For self-hosted installations, replace the broad pattern with a configurable but explicit hostname allowlist rather than accepting arbitrary URLs. ]]>
