CWE-316: Cleartext Storage of Sensitive Information in Memory

Overview

Storing sensitive data (passwords, keys, tokens) in memory as cleartext exposes it to memory dumps, core dumps, swap files, hibernation files, debuggers, and memory disclosure vulnerabilities. Sensitive data should be cleared from memory immediately after use and prevented from being swapped to disk.

OWASP Classification

A06:2025 - Insecure Design

Risk

Medium-High: Cleartext in memory enables data theft via crash dumps, debugger attachment, memory disclosure bugs (Heartbleed), swap file analysis, hibernation file reading, memory scraping malware, and cold boot attacks on RAM.

Remediation Steps

Core principle: Avoid cleartext sensitive data in memory; minimize lifetime and exposure, and use safe handling where possible.

Locate cleartext sensitive data in memory

Review the flaw details to identify the specific file, line number, and code pattern where sensitive data is stored in memory
Identify what sensitive data is in memory: passwords, cryptographic keys, tokens, PII
Trace the data lifetime: where it's loaded into memory, how long it persists, when it's cleared
Determine exposure risk: can it be swapped to disk, captured in crash dumps, exposed via debuggers

Clear sensitive data after use (Primary Defense)

Zero memory containing passwords/keys: Explicitly overwrite memory with zeros after use (Arrays.fill(password, '\0') in Java)
Use SecureString (C#), SecretBytes (Java): Platform-specific secure memory types that auto-clear on disposal
Clear char arrays, don't use String for passwords: Strings are immutable and stay in memory; use char[] and clear it
Use explicit_bzero() or memset_s() (C/C++): Compiler-safe memory clearing functions (memset can be optimized away)

Prevent memory swapping to disk

Use mlock() to lock pages in RAM (Linux): Prevents sensitive memory pages from being swapped to disk
VirtualLock() on Windows: Windows equivalent to prevent memory paging
Mark pages as non-swappable: Use OS-specific APIs to prevent sensitive data from being written to swap files
Disable swap for critical processes: For high-security processes, disable swap entirely to prevent any disk exposure

Use secure memory abstractions

Use SecureString (.NET): Auto-encrypts content in memory, clears on disposal
Use GuardedString (Java): Java identity management secure string type with auto-clearing
Bouncycastle's SecureRandom: Use for cryptographic random data that needs secure handling
Libsodium's sodium_malloc(): Secure memory allocation with guard pages and auto-locking

Minimize exposure time in memory

Keep sensitive data in memory briefly: Load just before use, clear immediately after
Clear immediately after use: Don't let passwords/keys persist longer than necessary
Don't log sensitive values: Avoid logging passwords, keys, tokens (even to debug logs)
Avoid string concatenation with secrets: String concatenation creates immutable copies that can't be cleared

Test the memory protection fix

Verify sensitive data is cleared after use (use debugger to inspect memory, should see zeros)
Test with memory dump analysis tools to confirm no plaintext secrets in dumps
Verify memory locking is working (check mlock/VirtualLock calls succeed)
Test that application doesn't crash from memory locking failures
Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

Storing passwords in String objects
Not clearing char[] after use
Logging sensitive data
Sensitive data in immutable strings
Not locking memory pages

Language-Specific Guidance

For detailed implementation guidance and code examples in your programming language:

Python - Using bytearray, mlock, context managers, and secure framework patterns
Java - Using char[], Arrays.fill(), SecureString alternatives, and Spring Security
JavaScript/Node.js - Using Buffer, fill(0), crypto.timingSafeEqual(), and Express/Next.js patterns
C# - Using SecureString, Array.Clear(), SafeHandle, and ASP.NET Core Data Protection