Path Traversal
Dot-dot-slash and the fight over file boundaries. When an application resolves user-supplied filenames without validation, the filesystem becomes the attack surface.
Dot-dot-slash and the fight over file boundaries. When an application resolves user-supplied filenames without validation, the filesystem becomes the attack surface.
Path traversal (also known as directory traversal) is an access control vulnerability that lets an attacker read arbitrary files on the server by manipulating file path inputs. Instead of fetching the intended resource, the server resolves a path like ../../../etc/passwd and returns sensitive system files.
../ sequences escape the intended directory.../ becomes a skeleton keyMany web applications serve files dynamically based on user input. A photo gallery might use ?file=profile_123.jpg, or a document viewer might read /docs/report.pdf. If the server naively joins the user-supplied string with a base directory, an attacker can inject ../ to climb up the directory tree and read any file the server process has access to.
Path traversal is not limited to web apps — it appears in archive extractors (zip slip), file upload handlers, templating engines, and even container escape exploits. The core issue is always the same: user input controls a file path, and no validation ensures the resolved path stays within the intended sandbox.
The sandbox below simulates a server admin panel with a file viewer. You can enter file paths and see what gets returned. Try /etc/passwd or ../../../etc/shadow. Toggle the traversal check to see how proper path validation blocks unauthorised file access.
Enter a file path and click "Read" to view its contents.
In 2019, a former AWS employee exploited a Server-Side Request Forgery (SSRF) vulnerability in a Capital One web application firewall (WAF) configuration. The attacker sent crafted requests that included path traversal sequences to reach the internal metadata endpoint of the AWS instance. This allowed her to assume an IAM role with broad S3 access and exfiltrate data on over 100 million credit card applicants.
The breach highlighted how path traversal is rarely exploited in isolation. Attackers chain it with SSRF, local file inclusion (LFI), or zip slip to amplify impact. The fix involved stricter input validation, canonicalising paths before use, and restricting which directories the application could read.
The first line of defence is path canonicalisation — resolve the user-supplied path to its absolute form and reject it if it does not start with the expected base directory. Never pass user input directly to filesystem APIs. Use safe abstractions that map user-facing identifiers to server-side file paths.
// VULNERABLE - trusts user-supplied path directly
app.get('/api/files/:path', async (req, res) => {
const fullPath = path.join('/var/www/uploads', req.params.path);
const data = await fs.readFile(fullPath);
res.send(data);
});
// SAFE - canonicalise and validate
app.get('/api/files/:path', async (req, res) => {
const base = '/var/www/uploads';
const requested = path.resolve(base, req.params.path);
if (!requested.startsWith(base)) {
return res.status(403).json({ error: 'Access denied' });
}
const data = await fs.readFile(requested);
res.send(data);
});
// SAFER - use opaque identifiers
const FILE_MAP = new Map([
['a1b2', '/var/www/uploads/profile_123.jpg'],
['c3d4', '/var/www/uploads/report_q4.pdf'],
]);
const filePath = FILE_MAP.get(req.params.id);
if (!filePath) return res.status(404).end();Additional layers: run the application with the minimum OS permissions needed (never root), use chroot or container-level filesystem isolation, and validate that archive extraction libraries prevent zip slip by rejecting entries with ../ in their paths.
../ or using absolute paths.1.A file download endpoint reads from /var/www/files/ + req.query.filename. What is the vulnerability?
2.What is the purpose of path canonicalisation?
3.A developer writes a zip file extraction utility. What is the safest approach?