T09 · Insecure Skill Coding Practices
- Location
scripts/auth/oauth_auth.py:14- Finding
OAuth Tokens Are Stored Without Enforced Restrictive File Permissions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly matches a Spotify assistant, but it asks for broad Spotify authority and stores sensitive listening and token data with under-scoped safeguards.
Install only if you are comfortable granting Spotify playback, playlist, and library permissions and storing Spotify tokens plus listening/profile data locally. Before use, restrict file permissions on data/tokens.json and the data directory, keep config.json trusted and unchanged, consider removing unused Spotify write scopes, and avoid enabling phone-context or relationship-status features unless you explicitly want that sensitive data used for recommendations.
scripts/auth/oauth_auth.py:14OAuth Tokens Are Stored Without Enforced Restrictive File Permissions
scripts/playback/playback_control.py:52Mutable API Base URL Can Redirect Spotify Bearer Tokens to an Untrusted Origin
scripts/auth/oauth_auth.py:43OAuth Authorization Code Is Accepted Without State Verification
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
data/*.sqlite
data/*.db
data/tokens.json
.env
The declared purpose focuses on Spotify auth, playback, recommendations, and governance, but the detected behavior includes local telemetry/metrics logging and generic request instrumentation not clearly disclosed in the description. Undisclosed persistence and instrumentation can hide secondary data collection behavior, undermining user trust and making review of data handling and privacy exposure more difficult.
The declared purpose focuses on Spotify auth, playback, recommendations, and governance, but the detected behavior includes local telemetry/metrics logging and generic request instrumentation not clearly disclosed in the description. Undisclosed persistence and instrumentation can hide secondary data collection behavior, undermining user trust and making review of data handling and privacy exposure more difficult.
This logic directly uses a sensitive relationship-status flag to change how tracks tagged with an emotional condition are classified and archived. That is risky because it operationalizes intimate personal data for automated behavioral decisions, which is disproportionate to the stated music-intelligence purpose and could cause privacy, compliance, and user-trust harm if the data is wrong, leaked, or repurposed.
The skill advertises Python entrypoints with access to environment variables, local file read/write, network, and shell-like execution surfaces, but the manifest declares no explicit tool scope or permission boundaries. This weakens least-privilege controls and makes it easier for a caller or downstream runner to invoke broader capabilities than users would reasonably infer from the metadata.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"playlist-modify-public",
"user-top-read"
],
"apiBase": "https://api.spotify.com/v1"
},
"storage": {
"dbPath": "./data/spotify-intelligence.sqlite",
The document’s instructional text and operational descriptions are written entirely in German, including user-facing workflow steps and rationale examples. There is no indication that German is optional, user-selected, or required for a region-specific compliance reason, which creates a natural-language locale policy concern.
The documentation expands the skill from Spotify-focused functionality into phone-node signal ingestion, including GPS, Bluetooth, and motion context, which is a meaningful scope increase beyond the stated purpose. In a music recommendation skill, collecting environmental/device telemetry creates unnecessary privacy and trust risk because operators may enable broader sensing without clear product justification or consent boundaries.
The documentation describes enabling and ingesting sensitive phone-node context signals with no accompanying privacy notice, consent flow, or warning about the implications of collecting location, Bluetooth proximity, and motion data. In the context of a consumer-facing Spotify skill, this is especially risky because users would not reasonably expect this level of telemetry, making covert or accidental privacy invasion more likely.
The file instructs ingestion and use of Bluetooth, location, and motion data without clearly demonstrating necessity for the declared Spotify intelligence purpose. That mismatch increases the chance of overcollection and secondary use of sensitive contextual data, especially since location and device-nearby signals can reveal habits, presence, and routines.
The file's instructional content is written in German throughout, without offering a language choice or explaining that the skill is intentionally region- or locale-specific. Under the policy, forcing a specific language without opt-in is a natural-language policy violation.
This read-layer document includes explicit write-capable restore workflows against the Spotify API, which weakens the boundary implied by a read-focused component. That mismatch can cause operators or downstream automation to invoke state-changing actions from a supposedly read-only context, increasing the risk of unintended playlist modification or privilege overreach.
The documentation instructs continuous playback capture and storage of listening behavior without an explicit privacy warning, consent guidance, retention limits, or minimization controls. In a skill that profiles Spotify activity, this can lead to silent collection of sensitive behavioral data such as habits, preferences, and presence patterns.
The documentation repeatedly instructs users to run PowerShell with -ExecutionPolicy Bypass, which weakens a built-in safety control and normalizes unsafe execution practices. In a skill context where users may copy-paste commands verbatim, this increases the chance of executing tampered or untrusted scripts without policy-based friction or review.
The skill persists access and refresh tokens to data/tokens.json, which is a sensitive file write involving credentials. There is no confirmation prompt, warning comment/docstring, or prior user-facing disclosure before saving these tokens.
The code reads SPOTIFY_CLIENT_ID and SPOTIFY_CLIENT_SECRET from environment variables and uses them in an HTTP token exchange request. Although this is functionally expected for OAuth, the file provides no user-facing warning, explanatory comment, or visible disclosure about handling and transmitting these credentials.
The user-facing question string is written only in German and there is no visible mechanism in this file for language selection, opt-in, or locale-aware behavior. This creates a natural-language policy issue because the skill imposes a specific language on users without offering a choice or documenting a justified regional restriction.
The schema and default rules introduce storage and use of life-phase and emotionally sensitive labels such as relationship status and heartbreak, which goes beyond ordinary playlist management and creates sensitive profiling risk. In a Spotify playlist skill, collecting and acting on intimate personal context is not necessary for core functionality and can expose users to privacy harm if accessed, inferred, or reused unexpectedly.
The default rules embed German-language playlist names such as "Löschvorschläge" and "Emotions-Archiv" directly in the skill logic. This imposes a specific locale in behavior without any user opt-in or documented region-specific justification, which matches the language/locale policy violation criteria.
The script emits a user-facing question string in German only: "Soll ich mal aufräumen?...". This is a natural-language locale policy issue because the skill does not offer any language choice, opt-in, or documented region-specific justification.
This script is in a read-side path but performs persistent database writes by inserting raw event records and updating aggregate statistics. That violates read/write separation and can make seemingly low-risk read operations mutate state, enabling data poisoning, unintended side effects, and easier abuse by any caller that is only expected to have observational access.
This file lives under scripts/read and is named rebuild-cleanup-candidates, which suggests a read/rebuild-style reporting operation, but the code creates tables, alters schema, inserts system metadata, writes playlist_cleanup_candidates rows, and updates last-run state. That behavior is materially write-oriented rather than purely read/analysis, creating a semantic mismatch with the apparent documented intent implied by the file placement and naming.
Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.
last_seen_at, oldest_playlist_added_at, years_in_playlist, playlist_count,
total_played_ms, total_played_minutes,
score, reason
) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
""",
(
run_id,
The script persists sensitive Spotify data such as user profile details, email, playlists, and listening history into a local SQLite database without any access controls, minimization, encryption, or user-consent mechanism. In an agent skill context, this creates a real privacy and data-retention risk because the data can remain on disk longer than expected and may be accessible to other local users, processes, backups, or logs.
The queue path invokes another script to add tracks to a playback device and then updates the local database to mark items as queued. In this file there is no confirmation prompt, comment/docstring warning, or user-facing disclosure before these state-changing operations occur.
Detected: suspicious.install_untrusted_source