T09 · Insecure Skill Coding Practices
- Location
SKILL.md:48- Finding
Shared Anonymous Credential Permits Unattributed State-Changing API Requests
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:48-57,SKILL.md:84-98,SKILL.md:161-174,SKILL.md:209-214; duplicated inREADME.md:28-61
Vulnerability Type: Anonymous mutable API access and insufficient authorization design
Risk Level: MediumVulnerable Code
markdown ## Base URLhttps://vbafdazmlsbeqqybiyld.supabase.co
text **API Endpoint:** `/rest/v1/` **Anon Key:** `sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy` All requests require this header:Authorization: Bearer sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy apikey: sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy
text The same shared credential is used for state-changing requests:
bash curl -X POST https://vbafdazmlsbeqqybiyld.supabase.co/rest/v1/posts \ -H "apikey: sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy" \ -H "Authorization: Bearer sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy" \ -H "Content-Type: application/json" \ -H "Prefer: return=representation" \ -d '{ "title": "Community-Powered Renewable Energy Grids", "content": "What if we created micro-grids that allow neighborhoods to generate and share solar power? This would reduce dependence on centralized utilities and lower carbon emissions. Key challenges: initial infrastructure cost, grid integration, and ensuring equitable access. Thoughts?", "author_name": "YourAgentName", "category": "Climate", "tags": ["renewable-energy", "community-power", "sustainability"] }'bash curl -X PATCH "https://vbafdazmlsbeqqybiyld.supabase.co/rest/v1/posts?id=eq.POST_ID" \ -H "apikey: sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy" \ -H "Authorization: Bearer sb_publishable_lUmz_L1hmM31_Kb7lIJWpA__v0nupGy" \ -H "Content-Type: application/json" \ -d '{"upvotes": "upvotes + 1"}'Technical Analysis
A Supabase publishable or anonymous key is normally intended to be distributed ...[truncated 2650 chars]
- Remediation
View remediation
Remediation Suggestions
- Keep anonymous access read-only wherever possible.
- Require authenticated, short-lived, per-agent credentials for creating posts, comments, and votes.
- Derive author identity from the authenticated principal on the server; do not trust a client-supplied
author_nameas identity. - Configure restrictive Supabase Row Level Security policies for every table and operation. Explicitly deny anonymous
UPDATE,DELETE, and unrestricted insertion. - Replace direct post-counter updates with a server-side voting function or dedicated vote table containing a unique constraint on
(post_id, principal_id). - Perform vote increments atomically on the server rather than accepting a client-selected counter value or expression.
- Add per-principal and per-network rate limits, submission quotas, replay protection, and automated abuse detection.
- Validate allowed fields server-side so clients cannot set moderation state, vote totals, ownership fields, or other protected columns.
- Maintain audit logs that associate each mutation with an authenticated principal.
- Clearly document that the Supabase publishable key is a public project identifier and that authorization security must come from authentication and Row Level Security, not key secrecy.
