Skip to content

CWE-313: Cleartext Storage in a File or on Disk

Overview

Storing sensitive data (passwords, API keys, PII, credit cards, session tokens) unencrypted in files or databases enables data theft if storage is compromised through backup exposure, filesystem access, database dumps, stolen laptops/servers, or insider threats.

OWASP Classification

A06:2025 - Insecure Design

Risk

High: Cleartext storage exposes sensitive data in backups, database dumps, log files, config files, stolen devices, and filesystem snapshots. Enables credential theft, PII exposure (GDPR/CCPA violations), payment card theft (PCI-DSS violation), and complete data breach.

Remediation Steps

Core principle: Never store sensitive data in files on disk in cleartext; encrypt and limit access with least privilege.

Locate the cleartext storage in files or on disk

  • Review the flaw details to identify the specific file, line number, and code pattern where sensitive data is stored without encryption
  • Identify what sensitive data is stored: passwords, API keys, PII, credit cards, session tokens
  • Determine storage locations: database files, configuration files, log files, temporary files, backups
  • Trace the data flow: where data is written to disk and in what format

Encrypt sensitive data at rest (Primary Defense)

  • Use AES-256-GCM for symmetric encryption: Strong authenticated encryption for data at rest
  • Store keys in secure key management systems: AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault (never store keys with encrypted data)
  • Encrypt database columns with sensitive data: Use database-level encryption (TDE) or application-level encryption for specific columns
  • Use full disk encryption as defense-in-depth: BitLocker (Windows), FileVault (macOS), LUKS (Linux) for underlying storage

Use proper key management

  • Never store encryption keys with data: Keys must be stored separately from encrypted data (different server, service, or KMS)
  • Use cloud KMS: AWS KMS, Azure Key Vault, GCP KMS for centralized key management with access control and audit logging
  • Rotate keys regularly: Implement key rotation schedule (annually or after security incident), automated rotation where possible
  • Use separate keys per environment: Different keys for dev, staging, production; different keys per tenant in multi-tenant systems

Hash instead of encrypt (when appropriate)

  • Passwords: Hash with bcrypt/Argon2 (never encrypt): Passwords should be hashed, not encrypted (use bcrypt work factor 12-14, Argon2id with proper memory cost)
  • Tokens: Hash for lookup, store hash not plaintext: If you only need to verify tokens, hash them (don't need to decrypt)
  • API keys: Hash if verification only needed: Hash API keys if you only need to verify them during authentication
  • Use encryption only when need to decrypt: Only encrypt data that must be read back in plaintext (credit cards for refunds, PII for display)

Minimize storage of sensitive data

  • Don't store if not necessary: Avoid storing sensitive data unless required for business function
  • Truncate credit cards (store last 4 digits): Store only ****-****-****-1234 instead of full card number
  • Tokenize payment data (use payment processors): Use Stripe, PayPal, or payment gateway tokens instead of storing credit cards
  • Delete sensitive data when no longer needed: Implement data retention policies and automated purging

Test the encryption implementation thoroughly

  • Verify sensitive data is encrypted in files and database (inspect files, database to confirm ciphertext, not plaintext)
  • Test decryption works correctly for legitimate access
  • Verify keys are stored separately from encrypted data (check different service, KMS, vault)
  • Test backup/restore process maintains encryption (backups should also be encrypted)
  • Verify file permissions are restrictive (600 or 640, not world-readable)
  • Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • Passwords in database as VARCHAR
  • API keys in config files
  • Credit cards in plaintext columns
  • Session tokens not encrypted
  • PII without encryption

Additional Resources