Skip to content

CWE-73: External Control of File Name or Path

Overview

This vulnerability occurs when user input is used to construct file or directory names, allowing attackers to read, write, or delete arbitrary files on the system.

OWASP Classification

A06:2025 - Insecure Design

Risk

High: Attackers may access sensitive files, overwrite application data, or execute arbitrary code by manipulating file paths.

Relationship to Other CWEs

CWE-73 vs CWE-22 vs CWE-35:

  • CWE-73 (This page): Broad category covering any situation where user input controls file paths. This includes both path traversal attacks and arbitrary file selection within allowed directories. Most general of the three.
  • CWE-22 (Path Traversal): Specific subset of CWE-73 focusing on ../ sequences that escape intended directories. If your CWE-73 finding shows path traversal patterns, also apply CWE-22 guidance for traversal-specific mitigations.
  • CWE-35 (Path Equivalence): Specific subset focusing on different representations of the same path bypassing validation. Less common; mainly applies if your validation compares path strings without canonicalization.

Which guidance to follow: - If your finding is CWE-73 with traversal patterns (../, encoded dots): Apply both CWE-73 and CWE-22 guidance - If your finding is CWE-73 without traversal: Focus on indirect references and allowlisting (steps 2-3 below) - If uncertain: Follow all CWE-73 remediation steps - they cover the common cases

Remediation overlap: Indirect references (step 2) and canonicalization (step 3) apply to all three CWEs.

Remediation Steps

Core principle: Never let untrusted input choose file names, paths, or file operations; map external identifiers to server-controlled filenames and enforce canonical containment and safe file semantics.

Trace the Data Flow from Untrusted Source to File Operation

  • Review the security findings to identify the specific file, line number, and code pattern
  • Trace how untrusted data (user input, external files, databases, network requests) flows to the file operation
  • Identify all points where the file path is constructed or modified
  • Understand the complete data flow from source to sink

Eliminate Direct Use of Untrusted Data in File Paths

  • Never use untrusted data directly as a file name or path component
  • Replace direct file path construction with indirect references
  • Map user selections to internal identifiers (e.g., numeric IDs)
  • Use allowlists that map safe identifiers to actual file paths
  • Store the mapping server-side where it cannot be manipulated

Use Strict Validation and Canonicalization

  • Canonicalize all file paths before validation using OS-appropriate functions
  • Validate that the canonicalized path stays within allowed directories
  • Reject paths containing .., absolute paths, or symbolic links
  • Block special characters and path traversal sequences (including encoded variants)
  • Use allowlists of permitted file names or patterns rather than denylists
  • Validate file extensions against expected types

Add Directory Restriction and Access Controls

  • Configure a base directory for all file operations
  • Verify that all resolved paths remain within the base directory
  • Use chroot jails or similar OS mechanisms to restrict file access scope
  • Apply principle of least privilege: run processes with minimal file system permissions
  • Set appropriate file permissions (read-only where possible)

Apply Multiple Layers of Defense

  • Implement both indirect references AND path validation
  • Add runtime monitoring and logging for all file access operations
  • Log suspicious patterns (traversal attempts, access denials)
  • Set up alerts for repeated access violations
  • Use security frameworks or libraries that provide built-in path validation

Test and Verify the Fix

  • Test with the specific input from the security finding (should be blocked)
  • Test path traversal attempts: ../../etc/passwd, ..\..\windows\system32\config\sam
  • Test encoded traversal: %2e%2e%2f, ..%252f, ..%c0%af
  • Test absolute paths: /etc/passwd, C:\Windows\System32
  • Test null bytes: allowed.txt%00.jpg, file.txt\0
  • Verify legitimate file access still works correctly
  • Re-scan with the security scanner to confirm the issue is resolved
  • Check for any new findings introduced by the changes

Common Vulnerable Patterns

  • Directly using user input in file operations
  • Allowing directory traversal via ../ or encoded characters

Unsanitized Filename from User Input (Pseudocode)

# Uses user input for file access
open(request.args['filename'])

Secure Patterns

Allowlist-Based File Access (Pseudocode)

# Use allowlist and validate path
allowed_files = {'report.txt', 'summary.txt', 'data.csv'}
filename = request.args['filename']
if filename in allowed_files:
    open(filename)
else:
    raise Exception('Invalid file')

Why this works:

  • Restricts file access to pre-approved allowlist, preventing arbitrary file read/write
  • Blocks directory traversal attacks using ../, ..\, or encoded variants to access /etc/passwd or other system files
  • Prevents attackers from accessing sensitive files outside the intended directory
  • User input never directly controls the file path, eliminating path injection vulnerabilities
  • Combined with path canonicalization, ensures file access stays within allowed boundaries

Language-Specific Guidance

  • C# - Path.GetFileName, Path.Combine, allowlist validation
  • Java - Path.normalize, Files API, canonical path checks
  • Python - pathlib.Path.resolve, os.path.normpath, path traversal prevention

Dynamic Scan Guidance

For guidance on remediating this CWE when detected by dynamic (DAST) scanners:

Additional Resources