CWE-377: Insecure Temporary File
Overview
Insecure temporary files occur when applications create predictable filenames, use insecure permissions (world-readable/writable), or create files in shared directories without protection, enabling information disclosure, data tampering, and symlink attacks.
OWASP Classification
A01:2025 - Broken Access Control
Risk
High: Insecure temp files enable reading sensitive data (PII, credentials) from /tmp, symlink attacks (replace temp file with link to /etc/passwd), data tampering, denial of service (fill /tmp), and privilege escalation.
Remediation Steps
Core principle: Create temporary files securely (random names, exclusive create, correct permissions) and avoid predictable paths.
Locate the insecure temporary file creation in your code
- Review the flaw details to identify the specific file, line number, and code pattern creating insecure temp files
- Identify the insecurity: predictable filename, insecure permissions (0666), shared directory (/tmp), fixed filename
- Determine what sensitive data is in temp file: credentials, PII, session data, encryption keys
- Trace the temp file lifecycle: creation, usage, deletion (or lack of deletion)
Use secure temp file APIs (Primary Defense)
- Python:
import tempfile; with tempfile.NamedTemporaryFile(delete=True) as f: f.write(data)- auto-deletes on close - Java:
File temp = File.createTempFile("prefix", ".tmp"); temp.deleteOnExit();- unpredictable name, auto-cleanup - C:
int fd = mkstemp(template);- creates file atomically with unique name and mode 0600 - Node.js: Use
tmportempnpm packages that handle secure creation and cleanup
Set restrictive permissions
- Create with mode 0600 (owner read/write only):
os.open(path, os.O_CREAT|os.O_EXCL, 0o600)(Python) - Never world-readable (0644) or writable (0666): World-readable temp files can be read by any user
- Set permissions before writing sensitive data: Change permissions immediately after creation, before writing
- Use umask(077) to ensure secure defaults: Prevents accidental creation of world-readable files
Use unpredictable filenames
- Use secure random for filename: Generate filename with cryptographic random (not timestamp or PID)
- Don't use PID, timestamp, sequential numbers: Easily guessable; enables race conditions
- Use mkstemp(), tempfile.NamedTemporaryFile(): These APIs generate cryptographically random names
- Create with O_EXCL to prevent race: Fails if file exists; prevents attacker from pre-creating file
Use user-specific temp directories
- Create private temp directory per user:
/tmp/myapp-$USER/with mode 0700 - Use $TMPDIR if user-controlled: Respect user's temp directory preference (check it's secure first)
- Don't use shared /tmp for sensitive data: Other users can read/write files in /tmp
- Clean up on exit: Delete temp files and directories when application exits (use
atexithooks)
Test the temp file security fix
- Verify unpredictable filenames are used (check temp file names are random, not sequential)
- Test file permissions are restrictive (ls -la should show 0600, not 0666 or 0644)
- Verify temp files are deleted on exit (check /tmp after application exits)
- Test with sensitive data: Ensure credentials/PII in temp files are protected
- Re-scan with security scanner to confirm the issue is resolved
Common Vulnerable Patterns
- /tmp/app_PID.tmp (predictable)
- open("/tmp/data.txt", "w") (fixed name)
- Creating temp files mode 0666
- Not deleting temp files
- Storing credentials in /tmp
Language-Specific Guidance
For detailed, framework-specific guidance on preventing insecure temporary file vulnerabilities:
- Python - tempfile module, mkstemp, NamedTemporaryFile, secure permissions
- Java - Files.createTempFile, File.createTempFile, POSIX permissions
- JavaScript/Node.js - fs.mkdtemp, tmp package, secure file creation
- C# - Path.GetTempFileName, FileOptions.DeleteOnClose, ACL permissions