T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:22
- Finding
- Unnecessary Plaintext Persistence and Cross-Skill Access to Full Birth Dates## Vulnerability Details **File Location**: `SKILL.md`, lines 22–27 and 87–103 **Vulnerability Type**: Plaintext storage and unnecessary exposure of personal data **Risk Level**: Medium ### Vulnerable Code ```yaml data_access: - path: "MEMORY.md" purpose: "Read/write user's birthday and sun sign for personalized readings" operations: ["read", "write"] - path: "../fortune-hub/MEMORY.md" purpose: "Read shared user profile fields (birthday) to avoid re-asking — fortune-hub is the central profile hub for this multi-skill repository" operations: ["read"] ``` ```markdown **Reading**: Before generating, check in this order: 1. This directory's `MEMORY.md` — use first 2. `fortune-hub/MEMORY.md` (sibling skill in the same repository) — fill in any missing profile fields If data is available, use it directly without asking again. **Writing**: If the user shares their birthday, write it to **this directory's** `MEMORY.md`: ```markdown # User Profile ## Basic Info - Birthday (Gregorian): YYYY-MM-DD - Sun Sign: [Sign Name] - Sign Period: Early / Middle / Late ``` ``` ### Technical Analysis The Skill directs the agent to persist a user's complete Gregorian birth date in a plaintext Markdown file. A full date of birth is identifying personal data, while the documented horoscope personalization logic generally requires only the month and day, derived zodiac sign, and sign-period classification. Retaining the birth year therefore exceeds the apparent minimum data necessary for the stated functionality. The configuration also authorizes reading birth-date information from a sibling Skill's `MEMORY.md`. This broadens the data-access boundary and increases the number of components that can access the profile. The instructions do not specify explicit consent before persistence, a retention period, a deletion procedure, filesystem access restrictions, or source-control exclusions. This is an ...[truncated 1532 chars]
- Remediation
- ## Remediation Suggestions 1. Apply data minimization by storing only the derived sun sign and sign-period classification. If birthday-based behavior is required, retain only month and day unless the year is demonstrably necessary. 2. Obtain explicit, informed user consent before writing any profile information to persistent storage. Do not treat merely providing a birthday in conversation as consent to retain it. 3. Make persistence opt-in and clearly state what fields will be stored, where they will be stored, and how long they will remain. 4. Provide a documented command or workflow for viewing, correcting, and permanently deleting the stored profile. 5. Avoid reading sibling Skill memory by default. Require explicit user authorization for cross-Skill profile sharing and restrict access to the minimum fields needed. 6. Restrict filesystem permissions so memory files are readable only by the intended user or process. 7. Add `MEMORY.md` and equivalent profile files to source-control ignore rules and exclude them from logs, generated artifacts, and unnecessary backups. 8. Define a retention period and automatically remove stale profile data. 9. If a full date of birth must be retained, use an approved protected storage mechanism rather than an unprotected Markdown file.