Django path traversal exposes the file system and secret data

At a glance

What this is: This is a Django path traversal guide showing how attackers use dot-dot-slash sequences, SSI template handling, and unvalidated file names to read or write files outside the intended directory.

Why it matters: It matters because file-path handling failures often expose credentials, source code, and sensitive data that identity and security teams must treat as access-control failures, not just input-validation bugs.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read StackHawk's guide to Django path traversal examples and prevention

Context

Django path traversal is a file access control failure, not just a malformed input problem. When an application trusts user-controlled paths, attackers can move outside the intended directory and reach files that were never meant to be exposed. In practice, that can turn a simple download endpoint or template include into a route to source code, configuration, and credentials.

For identity and security teams, the relevance is broader than web application hygiene. Exposed files often contain secrets that govern service accounts, backend integrations, and deployment pipelines, which means a path traversal flaw can become an NHI exposure event. That intersection is where application security, secrets governance, and IAM controls meet.

This pattern is common in legacy path-handling code and in features that were designed for convenience, such as file preview, attachment retrieval, or server-side includes. The underlying governance gap is usually the same: applications are allowed to interpret paths without enforcing a canonical, server-side trust boundary.

Key questions

Q: What breaks when Django file paths are not canonicalised before use?

A: When Django code trusts a user-supplied path before resolving it, attackers can escape the intended directory with traversal sequences, encoded variants, or symlink tricks. That can expose configuration files, source code, and credentials. The practical failure is boundary loss. The file that gets read is no longer the file the application intended to allow.

Q: Why do path traversal bugs create identity and secrets risk?

A: Because the files they expose often contain API keys, tokens, and backend credentials that behave like non-human identities once attackers obtain them. A traversal flaw can therefore become a credential theft event, not just a data disclosure issue. If exposed secrets remain valid, the attacker may pivot into connected services or pipelines.

Q: How do teams know if file access controls are actually working?

A: Teams should test whether every user-controlled path is resolved canonically and then checked against an approved root directory before access occurs. A good signal is that encoded traversal attempts, symlink escapes, and malformed filenames all fail consistently. If any variant succeeds, the boundary is not enforced.

Q: What should teams do when a traversal flaw may have exposed secrets?

A: Contain the issue by disabling the vulnerable path, then assume any readable configuration or deployment file may be compromised. Rotate exposed secrets, revoke tokens, and inspect logs for abnormal access to backend systems. If the files supported service accounts or integrations, treat those identities as potentially exposed too.

Technical breakdown

How dot-dot-slash traversal escapes a Django path boundary

Path traversal works when application code joins a trusted base directory to an untrusted user-supplied path without first resolving the final canonical location. Sequences such as ../ instruct the file system to step upward through directories, so the requested file can land outside the intended folder. Encoding tricks such as %2e%2e%2f can bypass naive filters that only look for raw ../ strings. The core failure is not the string itself, but the absence of path normalization and boundary validation before file access occurs.

Practical implication: compare the canonical resolved path against the allowed base directory before any read or write operation.

Why SSI template access can expose arbitrary files

Server-side include features are risky when they accept absolute or semi-controlled paths and then map them to files on disk. If the framework checks only a prefix or a loose allow list, an attacker can use traversal segments to stay within the accepted prefix while redirecting the final resolved path elsewhere. That is why canonical path resolution matters more than visible path text. The secure pattern is to resolve the target first, then verify that it still resides inside the permitted directory tree.

Practical implication: treat SSI-like include features as privileged file readers and restrict them to pre-approved, canonical locations.

How path traversal becomes a secrets and NHI exposure issue

Once traversal reaches configuration files, source repositories, or deployment artefacts, the impact shifts from file disclosure to credential exposure. Those files frequently contain API keys, service account tokens, database credentials, and infrastructure metadata. That creates a bridge into non-human identity compromise because attackers often need only one exposed secret to impersonate a workload or pivot into a broader environment. Path traversal therefore sits on the same risk chain as secrets sprawl and overprivileged service accounts.

Practical implication: inventory where secrets live, and assume any readable configuration file may be an identity control failure.

Threat narrative

Attacker objective: The attacker aims to access arbitrary files and harvest secrets that enable deeper compromise of the application or its connected systems.

1. Entry occurs through a user-controlled file path, filename parameter, or SSI include path that the application fails to normalize before use.
2. Escalation happens when traversal segments or encoding tricks escape the intended directory and reach configuration, source, or credential files.
3. Impact follows when exposed secrets or sensitive files let the attacker read confidential data, tamper with files, or reuse credentials for broader compromise.

NHI Mgmt Group analysis

Path traversal is an identity-adjacent control failure when it exposes secrets. The primary risk is not the file read itself, but what lives inside the file system: API keys, service credentials, deployment variables, and source code often sit adjacent to application assets. Once exposed, those artefacts become non-human identities or the material used to impersonate them. That makes file-boundary enforcement part of secrets governance, not only application validation. Practitioners should treat traversal as a credential exposure precursor.

Canonical path validation is the control gap this article exposes. The vulnerability exists because applications trust the requested path before resolving its final location. Prefix checks alone are brittle when encoding, symlinks, and nested directory structures are in play. A secure design resolves the path server-side, checks it against the approved root, and fails closed when the request exits that boundary. Practitioners should review every file-serving and include pathway for canonicalization, not just obvious download endpoints.

Secrets sprawl through readable files is the named concept here: when paths are traversable, credential storage choices determine blast radius. If secrets are scattered across code, config, CI/CD, and app directories, a single traversal flaw can expose multiple trust layers at once. That is why this issue belongs in both application security and NHI governance reviews. Practitioners should assume that every exposed file can carry identity impact, not just data impact.

Legacy convenience features often create the widest exposure window. Template includes, attachment handlers, and filename-based retrieval endpoints are usually built for speed, then left with minimal lifecycle scrutiny. That makes them easy to forget during access reviews and hardening cycles. The governance lesson is to inventory file-touching code as an identity-relevant attack surface. Practitioners should assign explicit owners to these paths and review them with the same discipline used for privileged access.

Path traversal shows why secrets management and IAM cannot be separated from application code. If a file can be read, the question becomes whether it contains standing credentials or sensitive identity material. That is a lifecycle problem as much as a code problem because exposed secrets often remain valid long after discovery. Practitioners should pair secure file handling with secret rotation and offboarding controls that limit post-disclosure abuse.

What this signals

Path traversal becomes a governance event when exposed files contain standing credentials. For identity teams, the important signal is not the path bug itself but whether the vulnerable application can surface service account material, tokens, or deployment secrets. That is where application security overlaps with Ultimate Guide to NHIs , Key Challenges and Risks and where remediation must include rotation, revocation, and ownership tracking, not only code fixes.

Canonical path enforcement should be treated as a preventive control with identity consequences. If a user can climb directories, the organisation has lost control over which artefacts are effectively public. That risk maps cleanly to secrets handling and to the access assumptions behind MITRE ATT&CK Enterprise Matrix, especially when attackers move from file disclosure to credential access.

Exposure containment is the key programme signal. Teams should measure how quickly they can identify and revoke any secret that might have been reachable through a file-read flaw, then compare that to their normal access review cycle. The gap between discovery and revocation is the real risk window, and it usually persists longer than engineering teams expect.

For practitioners

• Harden file paths with canonical resolution Resolve every requested path to its canonical form before reading or writing, then compare it to the approved base directory. Reject any request that resolves outside the permitted root, including encoded traversal attempts and symlink escapes.
• Remove secrets from file-readable locations Move API keys, tokens, and backend credentials out of code, config files, and attachment directories, then verify that runtime services retrieve them from controlled secret stores instead of local files.
• Review SSI and file-include features as privileged access paths Audit every server-side include, preview, and attachment handler for path normalization, allow-list enforcement, and least-privilege execution context. Treat these features as access paths to sensitive files, not just rendering helpers.
• Rotate any credentials that may have been exposed If traversal could have reached configuration or deployment files, assume secrets exposure until proven otherwise. Revoke exposed tokens, rotate backend credentials, and validate whether any service accounts used those secrets for downstream access.

Key takeaways

• Django path traversal is a boundary failure that can expose files, secrets, and source code when user-controlled paths are not canonicalised.
• The practical impact is broader than application exposure because readable files often contain non-human identities, backend credentials, and deployment material.
• The most effective response combines canonical path validation, secrets relocation, and rapid revocation of anything the flaw may have exposed.

Key terms

• Path Traversal: A bug where crafted path segments such as ../ allow input to escape an intended directory boundary. In practice, it turns a normal file operation into a boundary break, which is especially dangerous when the affected service runs with non-human identity privileges and touches production data or secrets.
• Canonical Path: A canonical path is the final resolved file location after symbolic links, traversal sequences, and relative components have been removed. Security teams use canonical comparison to verify that the requested file still sits inside an approved directory before the application reads or writes it.
• Server-Side Include: A server-side include is a feature that pulls file content into a page during server processing. If the include mechanism accepts unsafe paths or weak allow lists, it can become a file disclosure vector and expose sensitive files outside the intended template boundary.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.

What's in the full article

StackHawk's full blog post covers the code-level examples and prevention steps this post intentionally leaves at a higher level:

• Step-by-step Django examples for SSI template tag misuse and file-path traversal inputs
• Python-based prevention snippets using os.path.realpath, os.path.relpath, and os.path.abspath
• Version-specific remediation guidance for vulnerable Django releases and upgrade paths
• Practical input-validation patterns for attachment names and URL parameters

👉 StackHawk's full post includes code examples and version-specific remediation guidance

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the application and operational risks that expose credentials in the first place.