T09 · Insecure Skill Coding Practices
- Location
assets/templates/setup-supabase.sql:26- Finding
Client-side PIN does not enforce access control over dashboard data
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The dashboard skill is purpose-aligned, but its remote tiers need review because they can publish operational data with weak client-side protection and public Supabase read/write access.
Use Tier 1 or add real server-side authentication before publishing anything sensitive. Do not rely on the embedded PIN for confidentiality, avoid internal URLs, secrets, private error text, or personal data in dashboard fields, and tighten Supabase policies before using Tier 3. Review any cron update carefully because it can keep publishing agent and cron status on a schedule.
assets/templates/setup-supabase.sql:26Client-side PIN does not enforce access control over dashboard data
assets/templates/setup-supabase.sql:31Anonymous database writes can produce dashboard tampering and stored cross-site scripting
assets/tier3-realtime.html:7Mutable third-party JavaScript is executed without version pinning or integrity verification
assets/push-dashboard.sh:30Push script accepts and transmits arbitrary JSON despite documented safe-field assurances
Referenced artifact was not completely inspected
In `tier3-realtime.html`:
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
<div class="card full-width">
<!-- Spans all columns -->
</div>
The skill instructs use of shell-capable operations such as gh repo create, git push, vercel deploy, exporting environment variables, and curl, yet it does not declare a restrictive tool scope. That mismatch can cause the agent to request or exercise broader execution capability than users expect, increasing the risk of unintended command execution or repository/network changes.
The skill metadata claims all data stays on the user's machine and implies no external exposure, but the body explicitly describes publishing dashboard state to GitHub Pages, Supabase, and Vercel. This is dangerous because users and downstream policy systems may trust the misleading privacy claim and authorize the skill without understanding that operational data will be transmitted to third-party services.
The security section says the skill does not send data to third-party services, but elsewhere the skill instructs pushing status data to GitHub and Supabase. Contradictory security documentation undermines informed consent and can lead operators to expose internal task names, cron status, URLs, and error details under the false belief that no third-party transmission occurs.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)
# Update the dashboard_state table using anon key
RESPONSE=$(curl -s -w "\n%{http_code}" -X PATCH \
"$SUPABASE_URL/rest/v1/dashboard_state?id=eq.main" \
-H "apikey: $SUPABASE_ANON_KEY" \
-H "Authorization: Bearer $SUPABASE_ANON_KEY" \
This HTML/JS code initializes a Supabase client and subscribes to realtime updates from the dashboard_state table, which transmits dashboard and activity data to the browser. Although the code logs connection events to the console, there is no user-facing notice in the UI, comment, or inline documentation explaining that remote operational data will be fetched and continuously streamed.
The customization guide demonstrates rendering data.customData into the DOM using innerHTML with unsanitized ${item.name} values. If that data can be influenced by an attacker or untrusted source, this creates a client-side XSS path where arbitrary HTML or script-capable payloads could execute in the dashboard viewer's browser.
The document declares lang="en", which hard-codes English as the page language. Under the policy, forcing a specific language without user opt-in or clear justification is a natural-language locale constraint.
The page declares lang="en", which hard-codes the interface language/locale to English. There is no indication in the file that this is optional, configurable, or justified as a region-specific tool.
The page loads Google Fonts from external domains, which causes client browsers to make third-party network requests and disclose metadata such as IP address, user agent, and access timing. In the context of a supposedly local/PIN-protected operational dashboard, this weakens the claim that data stays local and introduces avoidable privacy and supply-chain exposure.
The document declares lang="en", which fixes the interface language to English, and all visible UI text is likewise English-only. There is no indication of user opt-in, locale selection, or documentation that this is a deliberately region-specific tool.
No suspicious patterns detected.