Trust Assessment
supabase received a trust score of 58/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 6 findings: 0 critical, 2 high, 4 medium, and 0 low severity. Key findings include Sensitive environment variable access: $OPENAI_API_KEY, Arbitrary SQL Execution with Full Access Key, Excessive Permissions via Supabase Service Key.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 49/100, indicating areas for improvement.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings6
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | Arbitrary SQL Execution with Full Access Key The `query` command in `supabase.sh` allows the execution of arbitrary SQL statements. This is performed using the `SUPABASE_SERVICE_KEY`, which the skill's documentation explicitly states provides 'full access' and bypasses Row Level Security (RLS). An attacker or a maliciously prompted LLM could leverage this to perform destructive operations (e.g., `DROP TABLE`), exfiltrate sensitive data, or modify database contents without restriction. If arbitrary SQL execution is truly necessary, ensure the `SUPABASE_SERVICE_KEY` is restricted to the absolute minimum required permissions. For most operations, consider using a key with RLS enabled or a custom role with limited privileges. Implement strict input validation or whitelisting for SQL commands if possible, or provide a more controlled interface than raw SQL. | LLM | scripts/supabase.sh:99 | |
| HIGH | Excessive Permissions via Supabase Service Key The skill is configured to use the `SUPABASE_SERVICE_KEY` for all database operations. The documentation explicitly states this key grants 'full access' and bypasses RLS. This means any successful prompt injection or command injection vulnerability within the skill's execution context could lead to complete compromise of the Supabase database, including data exfiltration, modification, or deletion, without any granular access control. Implement a principle of least privilege. For operations that do not require full database access, use a more restricted API key (e.g., `SUPABASE_ANON_KEY` with RLS enabled) or create custom Supabase roles with only the necessary permissions. Avoid using the service role key for general-purpose operations if possible. | LLM | SKILL.md:171 | |
| MEDIUM | Sensitive environment variable access: $OPENAI_API_KEY Access to sensitive environment variable '$OPENAI_API_KEY' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/stopmoclay/supabase/scripts/supabase.sh:356 | |
| MEDIUM | JSON Injection in Embedding Model Name In the `get_embedding` function, the `$model` variable (which can be user-controlled via the `--embedding-model` option) is directly interpolated into a JSON string without proper escaping. If `$model` contains a double quote character (`"`), it could break the JSON structure, leading to a malformed request or potentially injecting arbitrary JSON fields into the API call to the embedding service. Ensure that the `$model` variable is properly escaped for JSON before being interpolated into the `curl` command's data payload. This can be achieved by piping `$model` through `jq -Rs .` similar to how `$text` is handled, or by using a dedicated JSON escaping utility. | LLM | scripts/supabase.sh:230 | |
| MEDIUM | Unvalidated Path/Function Name Interpolation in URLs Several commands (`vector-search`, `rpc`, `select`, `insert`, `update`, `delete`, `describe`) directly interpolate user-provided table names (`$table`), RPC function names (`$func_name`), or vector match function names (`$match_fn`) into the URL path or query parameters without validation. While Supabase's PostgREST API might have internal validation, this direct interpolation could allow an attacker to craft paths that lead to unexpected endpoints, bypass intended routing, or cause errors if special characters (e.g., `/`, `?`, `&`) are used in these names. Implement strict input validation for table names, RPC function names, and vector match function names. Use a whitelist or a strong regular expression to ensure these inputs only contain characters valid for their intended purpose (e.g., alphanumeric characters and underscores), preventing path traversal or endpoint manipulation attempts. | LLM | scripts/supabase.sh:220 | |
| MEDIUM | Potential SQL Injection via Unsanitized URL Filter Values The `build_filters` function directly interpolates user-provided values (`$val`) into URL query parameters for various filter types (e.g., `--eq`, `--like`, `--gt`). While PostgREST typically sanitizes values, direct interpolation without explicit encoding or validation in the script itself can be a common vector for SQL injection if the backend's sanitization is incomplete or bypassed. Given the use of a full-access service key, this risk is elevated. Ensure all user-provided filter values are URL-encoded and/or strictly validated before being appended to the URL query string. This adds a layer of protection against potential SQL injection attempts through crafted filter values, even if the backend has its own sanitization. | LLM | scripts/supabase.sh:119 |
Scan History
Embed Code
[](https://skillshield.io/report/8ba428bf4d18af1e)
Powered by SkillShield