Supabase Dashboard Builder
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is coherent for building Supabase dashboards, but its example uses a high-privilege Supabase service key behind broad, apparently unauthenticated API endpoints that could expose sensitive tables or prompt/embedding data if copied as-is.
Only use this as a starting template if you add real admin authentication, restrict CORS, declare and protect the Supabase service key, and replace `select=*` with explicit safe column allowlists before deployment.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If deployed as written, anyone who can reach the dashboard API may be able to read service-key-backed Supabase data from the allowed tables.
The template instructs using a high-privilege Supabase service key for a network API endpoint, but does not show authentication, authorization, or least-privilege controls for callers.
SUPABASE_KEY = os.environ["SUPABASE_SERVICE_KEY"]
HEADERS = {"apikey": SUPABASE_KEY, "Authorization": f"Bearer {SUPABASE_KEY}"}
@app.get("/api/mc/{table}")Require user authentication and authorization before proxying Supabase data, prefer least-privilege/read-only access where possible, rely on RLS where appropriate, and declare the required Supabase credential clearly in metadata.
Sensitive operational knowledge, prompts, or embedded content could be exposed through the dashboard API if the default all-column select is used.
The proxy allows the knowledge_vault table and defaults to selecting all columns, which can include sensitive stored knowledge, prompts, or embeddings.
allowed = {"ai_agents", "skills", "knowledge_vault", "tools", "workflows"}
...
async def get_table(table: str, select: str = "*", limit: int = 100, offset: int = 0)Use explicit safe column allowlists per table, avoid default `select=*`, exclude prompt/embedding/secret fields unless specifically authorized, and add auditing for access to knowledge-vault data.
A deployed dashboard could be accessed cross-origin more broadly than intended, increasing the chance that privileged Supabase-backed data is exposed.
The suggested wildcard CORS configuration is broad for a service-key-backed admin API and could make accidental exposure easier if used outside local development.
app.add_middleware(CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"])
Limit CORS to trusted dashboard origins, keep wildcard CORS only for local development if needed, and combine it with authentication and authorization.