T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:32
- Finding
- Platform Credentials Stored in a General-Purpose JSONB Column Without Specified Protection## Vulnerability Details **File Location**: `SKILL.md`, lines 32–35 and 107–108 **Vulnerability Type**: Plaintext or inadequately protected sensitive credential storage **Risk Level**: High ### Vulnerable Snippets ```markdown - `platform_connections` — id, platform, account_name, credentials (JSONB), status, scopes ``` ```markdown - **Credentials in JSONB**: Each platform stores different auth shapes (API keys vs OAuth tokens vs page tokens) in a single `credentials` JSONB column ``` ### Technical Analysis The proposed architecture places API keys, OAuth tokens, and page access tokens in a general-purpose Supabase JSONB column. The Skill does not require encryption at the application layer, envelope encryption with externally managed keys, a managed secret store, restrictive row-level security, secret redaction, or controls preventing the connection API from returning stored credentials. JSONB provides data representation and querying, not secret protection. Database administrators, compromised service credentials, permissive Supabase policies, exposed backups, logging pipelines, or an authorization defect in the proposed `GET/POST /api/social/connections` interface could consequently reveal reusable platform credentials. Sending credentials to official platform endpoints is necessary for the declared publishing functionality. Persisting their raw values in ordinary application storage without explicit safeguards is not the minimum secure privilege model. The application generally needs server-side use of narrowly scoped tokens, not broad capability to expose their values through database reads or API responses. ### Attack Path 1. A user connects a social-media account, causing an API key, OAuth token, or page token to be stored in `platform_connections.credentials`. 2. An attacker obtains read access through a permissive Supabase row-level security policy, compromised backend/service credentials, an authorization flaw in the connections endpoint, an e ...[truncated 1111 chars]
- Remediation
- ## Remediation Suggestions 1. Store credentials in a managed secret vault and keep only opaque secret references in `platform_connections`. If direct database storage is unavoidable, use application-layer envelope encryption with keys maintained outside Supabase. 2. Ensure secret decryption is available only to the server-side publishing component. Frontend clients and ordinary application queries must never receive raw credentials. 3. Apply deny-by-default Supabase row-level security and narrowly scoped service roles. Separate credential access from general post, calendar, and analytics access. 4. Make connection API responses return only non-sensitive metadata such as platform, account name, connection state, granted scopes, and token-expiration time. Explicitly exclude credential values. 5. Request the minimum platform scopes needed for enabled features. Avoid administrative, messaging, profile-management, or unrelated read scopes. 6. Implement token expiration handling, rotation, revocation on disconnect, and rapid emergency revocation procedures. 7. Redact authorization headers, tokens, request bodies, database fields, exception details, and query parameters from logs, traces, analytics, and error responses. 8. Audit all secret reads and publishing operations. Alert on bulk credential access, unusual destinations, unexpected publication volume, and repeated authentication failures. 9. Protect backups and database exports with encryption and strict access controls, and ensure retention and deletion policies also cover revoked credentials. 10. Validate outbound destinations against fixed official platform API hosts so credentials cannot be forwarded to attacker-controlled endpoints.