Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.


Connecting your security stack & resolution processes seamlessly.


Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.


Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.


Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.


Download whitepapers & research on hot topics in the security field.

About us

Who we are, where we came from, and our Bright vision for the future.


Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
Directory Traversal: Examples, Testing, and Prevention

Directory Traversal: Examples, Testing, and Prevention

Admir Dizdar

What Is Directory Traversal?

Directory traversal, or path traversal, is an HTTP exploit. It exploits a security misconfiguration on a web server, to access data stored outside the server’s root directory. A successful directory traversal attempt enables attackers to view restricted files and sometimes also execute commands on the targeted server. 

Typically, a directory traversal attack exploits web browsers. This means that all servers accepting unvalidated input data from web browsers are vulnerable to the attack. To launch this attack, threat actors often scan through a directory tree, which is where they can locate paths to restricted files on web servers.

In this article:

How Are Directory Traversal Vulnerabilities Exploited?

The web server receives a  request and appends the ../../etc/hosts relative path, specified by the user, to a directory of web pages (/var/www/). This creates a full path: /var/www/html/../../../etc/hosts

In systems like UNIX, the element ../ traverses a directory in the file system, and can give a malicious user access to the file /etc/hosts.

Malicious users can use this attack method to access secrets and sensitive information like passwords and database credentials. They can also exploit the vulnerability to carry out further enumeration of the system and obtain the information they need to enable a combined attack through vectors like LFI and RFI.

Learn more in our detailed guide to directory traversal attack.

Directory Traversal Examples

Simple Directory Traversal (dot-dot-slash Attack)

The simplest example of a directory traversal attack is when an application displays or allows the user to download a file via a URL parameter. 

For example, if the user provides the file name document.pdf, and the website downloads the PDF to the user’s computer via this URL:

If the website is hosted on a Linux system, website files are typically stored in /var/www which is two directories above the root. The attacker can exploit this, passing this as the file name:


If the application does not sanitize inputs, it uses the attacker’s string directly in a system call, switches to the root and then allows the attacker to access the /etc/ directory. It then allows the attacker to access the protected passwd file. 

A similar attack can be performed on a Windows system using the string \..

Using Cookies for Directory Traversal

In many cases, cookies reference directories on a web server to load files required for a website. This exposes the site to a directory traversal attack. For example, consider a cookie that accesses a file to load a new design template for a website:

    $design = 'new-design.php';
    if (isset($_COOKIE['DESIGN'])) {
        $template = $_COOKIE['DESIGN']; 
    include("../resources/" . $design); 

In this scenario, the name of the file is stored in the DESIGN cookie and appended to a path. Because there is no validation of the $design variable an attacker can send a GET HTTP request that modifies the cookie value to DESIGN=../../etc/passwd

The web server would then perform the following system call, loading the passwd file instead of the design template.


Path Traversal Prevention

Here are several ways you can use to prevent path traversal attacks: 

  • Developers should validate user input accepted from browsers. Input validation can help ensure that attackers are restricted from using command techniques, like SQL injection, which violate access privileges and may grant attackers access to a root directory. 
  • Applications should use filters to block suspicious user input. Most web applications employ filters to block URLs that contain commands, as well as escape codes commonly employed by attackers. 
  • Administrators should keep software up to date, including web server software and the underlying operating system, and apply all security patches. The practice of regularly patching software can significantly reduce security risks and reduce the chance of exploitation.

Related content: Read our guide to misconfiguration attacks.

Testing for Directory Traversal Vulnerabilities

There are several testing techniques that can help you identify directory traversal flaws and vulnerabilities in your web applications. Here are several methods recommended by the web application security project (OWASP):

Input Vectors Enumeration

Enumeration is a technique used to detect attack vectors in systems. Input vector enumeration offers a systematic evaluation of all input vectors. The goal is to learn which specific part of a web application is vulnerable to input validation bypassing.  

Testers can do this by itemizing all application components that can accept user input, such as HTTP, POST and GET calls, HTML forms, and file uploads. Here are several aspects to consider when testing this aspect:

  • Can you find request parameters which can potentially be used for file-related operations? For example:
  • Can you detect any unusual file extensions? Such as:
  • Do you see any interesting variable names? For example:

Testing Techniques

The next phase of this security testing process involves analyzing all input validation functions in the tested web application. 

To quickly test an existing web application for directory traversal vulnerabilities, you can use the following technique:

  • Insert relative paths into files existing on your web server. For example:../../../../../../etc/passwd on Linux servers. 
  • Check whether a system is vulnerable to certain tricks like a ../ removal that uses percent-encoded values like %2e%2e%2f
  • You can check for file extension by adding a null byte like %00 before you insert a valid extension. 

Manually implementing the above techniques can be time consuming and error prone for large web applications. Instead of doing this manually, you can use an automated tool. The following technologies are commonly used to automatically analyze input validation:

  • Static application security testing (SAST)—these tools review the source code of the application when it is not running. SAST checks try to identify evidence of known insecure practices and vulnerabilities. SAST solutions employ white-box techniques.
  • Dynamic application security testing (DAST)—tools that communicate with the application through its front-end in order to identify security vulnerabilities. A DAST tool does not need any access to your source code. Rather, it simulates real attacks using a black-box strategy. Security checks are performed while executing or running the application or code under review. It also involves fuzzing, a technique used to submit random and malformed data as input to the web application, using it to uncover directory traversal vulnerabilities.


DORA: Exploring The Path to Financial Institutions’ Resilience

DORA (Digital Operational Resilience Act) is the latest addition to the EU regulatory arsenal. A framework designed to bolster the cyber resilience of financial entities operating within the EU. But let’s face it: there’s no lack of regulations issued by the European Union legislature, and they’re not exactly known for keeping things light and easy.

IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

Get our newsletter