T09 · Insecure Skill Coding Practices
Error
- Location
- config.json:63
- Finding
- Highly Sensitive Health Records Are Stored Without Encryption<![CDATA[ ## Vulnerability Details **File Location**: `config.json:63-70` **Vulnerability Type**: Plaintext storage of sensitive health information **Risk Level**: High ### Vulnerable Configuration ```json "privacy": { "sensitive_files": [ "private_sexual_health.json" ], "require_double_confirm": true, "encrypt_sensitive": false, "security_log": "security_log.txt", "_note": "encrypt_sensitive to be implemented in v3.1" } ``` The affected data model is documented in `references/storage_schema.md:147-172`: ```json { "enabled": true, "created_at": "2026-03-17", "gender_specific": { "male": { "frequency": "2-3 times/week", "quality_rating": 7, "concerns": [] }, "female": { "cycle_tracking": true, "last_period_start": "2026-03-01", "cycle_length_days": 28 } }, "notes": "Optional user notes" } ``` ### Technical Analysis The project explicitly disables encryption for `private_sexual_health.json`. The file can contain sexual activity, erectile function, menstrual-cycle, satisfaction, and other health information. Separating this information from the primary profile and requiring confirmation before application-level export does not provide confidentiality at rest. Any process or local account able to read the project directory can access the JSON file directly and bypass the confirmation workflow. The reviewed implementation also does not establish owner-only file permissions or use an operating-system credential store. The privacy statements in `references/onboarding_sexual_health.md:13-24` therefore provide workflow safeguards but not filesystem-level security. In addition, `references/storage_schema.md:398-409` suggests Base64 encoding as part of an encryption approach. Base64 is reversible encoding and provides no confidentiality, integrity, or authentication. ### Attack Path 1. A user opts into sexual-health profiling and supplies sensitive information. 2. The application store ...[truncated 1124 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Encrypt sensitive records using authenticated encryption such as AES-256-GCM or ChaCha20-Poly1305. 2. Store encryption keys outside the project directory, preferably in the operating-system keychain, credential manager, or another platform-backed secret store. 3. Never store the key adjacent to the ciphertext or derive it from a hardcoded password. 4. Create sensitive files with owner-only permissions, such as mode `0600` on POSIX systems, and verify the resulting permissions after creation. 5. Apply equivalent protections to temporary files, drafts, logs, and decrypted intermediate data. 6. Use atomic writes to an owner-only temporary file, then replace the destination to prevent partially written plaintext records. 7. Remove the Base64 recommendation. Explicitly document that encoding is not encryption. 8. Minimize the collected data and define retention and secure-deletion policies. 9. Ensure application-level confirmation is required for reading, exporting, backing up, and deleting sensitive records, while recognizing that confirmation does not replace encryption. 10. Add automated tests verifying that sensitive field values do not appear as plaintext in files, logs, backups, or exports. ]]>