Disabling Directory Listing on Your Web Server – And Why It Matters

Article arrow_drop_down

[ad_1]

By default, some web servers allow directory listing, which means that if no default index file (such as index.html or index.php) is present, the server will display a list of all files and directories in that folder. This can expose sensitive files, scripts, and configurations, making it easier for attackers to identify vulnerabilities.

Understanding Directory Listing

Directory listing is a web server feature that, when enabled, displays the contents of a directory if no default index file (such as index.html or index.php) is present. When a request is made to such a directory, the server automatically generates and returns a list of all files and subdirectories within it. This can pose a security risk by exposing sensitive files related to a web application, potentially revealing critical information.

If attackers gain access to directory listings, they can analyze file structures, discover hidden scripts, or identify outdated components—information that could be used to launch targeted attacks, including cross-site scripting (XSS) and other exploits. To prevent information leakage, it is crucial to disable directory listing and restrict unnecessary access to server files.

Why You Should Disable Directory Listing

Leaving directory listing enabled can expose critical information, such as hidden scripts, backups, or configuration files, which could be used in cyberattacks. Disabling it adds an extra layer of security, ensuring that unauthorized users cannot easily browse and analyze your server’s structure.

What Information Can Be Exposed Through Directory Listing – And Why It’s a Risk

When directory listing is enabled, unauthorized users can gain access to sensitive files that should remain hidden. For example, if a backup copy of a configuration file (such as config.php) is stored in a directory where listing hasn’t been disabled, an attacker could discover and access it simply by navigating to:

http://www.example.com/secret/

If this file contains database credentials, API keys, or other confidential details, an attacker can extract this information, gaining unauthorized access to the database. This could lead to data breaches, unauthorized modifications, further exploits, or even complete application compromise.

Beyond direct data theft, exposed directories may also reveal outdated scripts, log files, or debugging information that can be leveraged for cross-site scripting (XSS), SQL injection, or remote code execution (RCE) attacks.

How to Mitigate This Risk

To prevent information leakage, it’s essential to:

  • Disable directory listing on your web server.
  • Restrict access to sensitive directories using proper file permissions.
  • Avoid storing backup or configuration files in publicly accessible locations.

By taking these precautions, you can significantly reduce the attack surface and protect critical data from unauthorized access.

How to Disable Directory Listing

To prevent unauthorized access to your file structure, you can disable directory listing based on your web server:

  • Apache: Modify the .htaccess file or main configuration file by adding:

Options -Indexes

  • Nginx: In the server configuration file, set:

autoindex off;

  • IIS (Windows Server): Disable directory browsing through the IIS Manager by navigating to Features View > Directory Browsing and selecting Disable.

How to Disable Directory Listing on Tomcat

In Apache Tomcat, directory listing is disabled by default starting from version 5.0. However, if it has been re-enabled due to configuration changes or regressions, it’s important to manually disable it to prevent unauthorized access to directory contents.

Tomcat allows you to configure directory listing at two levels:

  1. Globally – Applies to all web applications running on the server.
  2. Per Application – Disables directory listing for a specific website only.

Disabling Directory Listing for All Tomcat Web Applications

To disable directory listing across all Tomcat-hosted applications:

  1. Locate the web.xml configuration file in the Tomcat installation directory. On Windows 10, this is typically:

C:\Program Files (x86)\Apache Software Foundation\Tomcat 9.0\conf\web.xml

  1. Open the web.xml file in a text editor.
  2. Find the following section related to directory listings under the default servlet configuration:

<init-param>

    <param-name>listings</param-name>

    <param-value>true</param-value>

</init-param>

  1. Change true to false to disable directory listing:

<init-param>

    <param-name>listings</param-name>

    <param-value>false</param-value>

</init-param>

  1. Save the file and restart Tomcat for the changes to take effect.

By applying this setting, directory listings will be disabled for all web applications running on the Tomcat server, reducing the risk of information exposure and unauthorized access.

Disabling Directory Listing for a Specific Tomcat Web Application

If you need to disable directory listing for a single web application rather than for all projects on the Tomcat server, you can configure this setting at the application level by modifying the web.xml file specific to that project.

Steps to Disable Directory Listing for a Specific Web Project

1. Locate the web.xml file for the web application you want to configure. This file is typically found in:

<TOMCAT_HOME>/webapps/<your_project>/WEB-INF/web.xml


2. Open the web.xml file in a text editor.

3. Add the following servlet configuration to explicitly disable directory listing for this specific project:

<servlet>

    <servlet-name>default</servlet-name>

    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>

    <init-param>

        <param-name>listings</param-name>

        <param-value>false</param-value>

    </init-param>

</servlet>

4. Save the file and restart Tomcat for the changes to take effect.

By implementing this configuration, directory listing will be disabled only for the specified web application, ensuring that other projects running on the same Tomcat server remain unaffected.

Disabling Directory Listing on Nginx

In Nginx, directory listing is managed by the ngx_http_index_module, with the autoindex directive controlling whether files in a directory are displayed when no index file (such as index.html) is present. By default, directory listing is disabled, but if it has been re-enabled due to configuration changes or a regression, you can manually disable it.

Locating the Nginx Configuration File

The primary configuration file for an Nginx server is typically named nginx.conf and is commonly found in one of the following locations:

  • /usr/local/nginx/conf/nginx.conf
  • /etc/nginx/nginx.conf
  • /usr/local/etc/nginx/nginx.conf

Disabling Directory Listing in Nginx

If directory listing has been enabled, you will see a configuration similar to:

location / {

    autoindex on;

}

To disable directory listing, modify the autoindex setting as follows:

location / {

    autoindex off;

}

After making this change, save the configuration file and restart Nginx to apply the update:

sudo systemctl restart nginx

By setting autoindex off, Nginx will no longer display directory listings, ensuring that unauthorized users cannot browse file structures and potentially access sensitive data.

Disabling Directory Listing on LiteSpeed

Like other web servers, LiteSpeed allows you to disable directory listing at both the server level and individual website level. This ensures that unauthorized users cannot browse directories without an index file, reducing the risk of exposing sensitive information.

Disabling Directory Listing at the Server Level

To disable directory listing for all websites on the LiteSpeed server, you can manually edit the configuration file or use the LiteSpeed WebAdmin Console.

Method 1: Editing the Configuration File
  1. Locate and open the httpd_config.xml file. The exact location depends on your installation, but it is commonly found in:

/usr/local/lsws/conf/httpd_config.xml

  1. Find the <autoIndex> setting under the <serverConfig> section. If directory listing is enabled, you’ll see:

<autoIndex>1</autoIndex>

  1. Change the value from 1 to 0 to disable directory listing:

<autoIndex>0</autoIndex>

  1. Save the file and restart the LiteSpeed server for the changes to take effect:

sudo systemctl restart lsws

Method 2: Using the LiteSpeed WebAdmin Console
  1. Log in to the LiteSpeed WebAdmin Console.
  2. Navigate to Configuration > Server > General.
  3. Locate the Auto Index setting.
  4. Change the value to Off.
  5. Save the settings and restart LiteSpeed.

By applying this change, directory listing will be disabled across all websites hosted on the LiteSpeed server, preventing unintended exposure of files and directories.

Disabling Directory Listing on Lighttpd

In Lighttpd, directory listing is disabled by default, but if it has been enabled due to configuration changes or a regression, you can manually turn it off by modifying the dirlisting.conf file. This file controls settings for the mod_dirlisting module, which is responsible for generating directory listings.

Locating and Editing the Directory Listing Configuration

1. Open the dirlisting.conf file, typically found at:

/etc/lighttpd/conf.d/dirlisting.conf

2. Look for the following configuration:

dir-listing.activate = "enable"

3. Change “enable” to “disable” to turn off directory listing:

dir-listing.activate = "disable"

4. Save the file and restart Lighttpd for the changes to take effect:

sudo systemctl restart lighttpd

Once directory listing is disabled, users will no longer be able to view the contents of directories without an index file, reducing the risk of exposing sensitive files on the server.

Disabling Directory Listing on IIS

By default, directory listing is disabled on Microsoft IIS (Internet Information Services). However, if it has been enabled due to configuration changes or a regression, you can manually turn it off using the IIS Manager Console.

Disabling Directory Listing in IIS 7 and Later

  1. Open IIS Manager
    • Press Win + R, type inetmgr, and press Enter to open IIS Manager.
  2. Select the Website or Server
    • In the Connections panel on the left, expand the server node and select either:
      • The entire server (to apply the change globally).
      • A specific site (to disable directory listing for only that website).
  3. Open Directory Browsing Settings
    • In the Features View, find and click on Directory Browsing.
  4. Disable Directory Listing
    • In the Actions panel on the right, click Disable to turn off directory browsing.
  5. Apply Changes and Restart IIS
    • Click Apply (if needed) and restart IIS to ensure the settings take effect:  iisreset

Alternative: Disabling Directory Listing via Web.config

If you prefer to modify the configuration file directly, you can disable directory listing for a specific site by adding the following setting to the Web.config file in the site’s root directory:

<configuration>

    <system.webServer>

        <directoryBrowse enabled="false"/>

    </system.webServer>

</configuration>

Result

With directory listing disabled, IIS will no longer display a file index when users access a directory without an index file (e.g., index.html). Instead, they will receive a 403 Forbidden error, improving security by preventing unauthorized access to server file structures.

Disabling Directory Listing on Apache

On an Apache web server, directory listing allows users to view the contents of a directory if no default index file (e.g., index.html or index.php) is present. To enhance security and prevent unauthorized access to files, directory listing should be disabled.

Method 1: Using .htaccess (Per-Directory Configuration)

If you want to disable directory listing for a specific application or directory, create or edit a .htaccess file in the target directory and add the following line:

Options -Indexes

This ensures that users cannot view the directory contents when an index file is missing. Instead, they will receive a 403 Forbidden error.

Method 2: Editing the Apache Configuration (httpd.conf)

To disable directory listing globally for all websites hosted on Apache, modify the main Apache configuration file (httpd.conf):

1. Open the Apache configuration file, typically located at:

/etc/apache2/apache2.conf  (Ubuntu/Debian)

/etc/httpd/conf/httpd.conf  (CentOS/RHEL)

2. Locate the <Directory> section for the root directory (/var/www/html or equivalent) and ensure that Indexes is removed from the Options directive. Modify it as follows:

<Directory /var/www/html>

    Options -Indexes

    AllowOverride All

    Require all granted

</Directory>

3. Save the file and restart Apache to apply the changes:

sudo systemctl restart apache2  # Ubuntu/Debian

sudo systemctl restart httpd    # CentOS/RHEL

Result

Once directory listing is disabled, users will no longer be able to browse directories without an index file. Instead, they will receive a 403 Forbidden error, ensuring sensitive files and application structures remain hidden from unauthorized access.

Final Thoughts on Disabling Directory Listing

Disabling directory listing is a fundamental yet often overlooked step in securing a web server. Allowing unauthorized users to browse directories can expose sensitive files, configuration details, or outdated scripts, increasing the risk of data breaches and cyberattacks. Whether you’re using Apache, Nginx, IIS, Tomcat, LiteSpeed, or Lighttpd, ensuring that directory listing is turned off helps protect server infrastructure, sensitive data, and overall web application security.

By implementing the correct settings at the server or application level, you can eliminate unnecessary exposure, reduce attack surfaces, and prevent attackers from gathering intelligence about your server environment. Security is an ongoing process, so regular security audits, proper access controls, and automated vulnerability scanning should complement these measures to ensure comprehensive protection.

THE AUTHOR

Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

[ad_2]

Source link

About the author

trending_flat
JSON Web Token Attacks And Vulnerabilities

[ad_1] JSON Web Tokens (JWTs) are a widely used method for securely exchanging data in JSON format. Due to their ability to be digitally signed and verified, they are commonly used for authorization and authentication. However, their security depends entirely on proper implementation—when misconfigured, JWTs can introduce serious vulnerabilities. This guide explores common JWT attacks and security flaws, providing a technical deep dive into how these weaknesses can be exploited and how to mitigate them. The Structure of a JSON Web Token (JWT) A JSON Web Token (JWT) is composed of three parts: a header, payload, and signature, all encoded using Base64URLand separated by dots. The format follows this structure: HEADER.PAYLOAD.SIGNATURE Here is an example of a real JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJuYW1lIjoiSm9obiBEb2UiLCJ1c2VyX25hbWUiOiJqb2huLmRvZSIsImlzX2FkbWluIjpmYWxzZX0. fSppjHFaqlNcpK1Q8VudRD84YIuhqFfA67XkLam0_aY Breaking Down the JWT Header The header contains metadata that defines the token’s properties, including: The algorithm (alg) […]

trending_flat
Mitigating Fragmented SQL Injection Attacks: Effective Solutions

[ad_1] This blog post breaks down Fragmented SQL Injection, a method hackers use to bypass authentication by manipulating two different input fields at the same time. Our security expert explains why single quotes matter in SQL injection attacks and how using Prepared Statements (also called Parameterized Queries) can effectively prevent these types of exploits. LEARN MORE: How to prevent SQL Injection If you ask someone how to check for an SQL injection vulnerability in a web application, their first suggestion might be to enter a single quote (‘) into an input field. If the application responds with an error, it could indicate that the input is interfering with the database query—a classic sign of SQL injection. In fact, some people even refer to SQL injection as “Single Quote Injection” because of how often this method is used to test for […]

trending_flat
Preventing CSRF Attacks with Anti-CSRF Tokens: Best Practices and Implementation

[ad_1] The most widely used method to prevent cross-site request forgery (CSRF) attacks is the implementation of anti-CSRF tokens. These are unique values generated by a web application and validated with each request to ensure authenticity. CSRF attacks exploit a user’s active session to execute unauthorized actions, such as redirecting them to a malicious website or accessing sensitive session data. To effectively mitigate these risks, it is essential to generate, manage, and validate CSRF tokens correctly, ensuring robust protection against unauthorized requests. What Is an Anti-CSRF Token? An anti-CSRF token (also known as a CSRF token) is a security mechanism designed to verify the legitimacy of a user’s request. It works by assigning a unique, unpredictable token to the user’s browser, which must be included in subsequent requests. This ensures that the request originates from the authenticated user and not […]

trending_flat
XSS Filter Evasion: How Attackers Bypass XSS Filters – And Why Filtering Alone Isn’t Enough

[ad_1] XSS filter evasion techniques allow attackers to bypass cross-site scripting (XSS) protections designed to block malicious scripts. This article explores some of the most common filter bypass strategies, explains why relying solely on filtering is ineffective, and outlines the best practices for preventing XSS attacks. Attackers have developed hundreds of methods to evade XSS filters, making it clear that filtering alone is not a foolproof defense. For an XSS attack to succeed, two conditions must be met: The application must have an XSS vulnerability that allows user-controlled input to be injected into web pages. The attacker must find a way to execute malicious JavaScript within the victim’s browser. XSS filtering aims to stop these attacks by detecting and removing suspicious code before it reaches the browser. However, because attackers continuously develop new techniques to disguise or encode their payloads, […]

trending_flat
Disabling Directory Listing on Your Web Server – And Why It Matters

[ad_1] By default, some web servers allow directory listing, which means that if no default index file (such as index.html or index.php) is present, the server will display a list of all files and directories in that folder. This can expose sensitive files, scripts, and configurations, making it easier for attackers to identify vulnerabilities. Understanding Directory Listing Directory listing is a web server feature that, when enabled, displays the contents of a directory if no default index file (such as index.html or index.php) is present. When a request is made to such a directory, the server automatically generates and returns a list of all files and subdirectories within it. This can pose a security risk by exposing sensitive files related to a web application, potentially revealing critical information. If attackers gain access to directory listings, they can analyze file structures, […]

trending_flat
Strengthen Your Web Applications with HTTP Security Headers | Acunetix

[ad_1] What is a HTTP security header? An HTTP security header is a response header that helps protect web applications by providing browsers with specific instructions on how to handle website content securely. These headers play a crucial role in mitigating various cyber threats, such as cross-site scripting (XSS), clickjacking, and data injection attacks. By configuring HTTP security headers correctly, organizations can enforce stricter security policies, restrict unauthorized resource loading, and reduce the risk of malicious exploitation. Common HTTP security headers include Content Security Policy (CSP) to prevent injection attacks, Strict-Transport-Security (HSTS) to enforce secure HTTPS connections, and X-Frame-Options to prevent clickjacking. Implementing these headers is a fundamental and effective way to enhance web application security, providing an additional layer of defense against cyber threats. Enhancing Your Web Application’s Security with HTTP Security Headers In web application security testing, vulnerabilities […]

Related

trending_flat
Defend the Airport

[ad_1] Every day, millions of passengers depend on a vast, complex airport ecosystem to get from Point A to Point B. From airline check-ins and baggage handling to air traffic control and terminal operations, the aviation sector is an intricate web of interconnected third-party providers, technologies, and stakeholders. In this high-stakes environment, a cybersecurity breach is not a single point of failure, it’s a ripple effect waiting to happen. Cyber Threats Aren’t Just IT Problems – They’re Operational Crises When people think about airport cybersecurity, they often picture network firewalls at airline headquarters or secure software for booking systems. But the real threat landscape is far broader and far more vulnerable. If a catering supplier is hit with ransomware, the aircraft turnaround slows. If the baggage conveyor system is compromised, luggage piles up, delaying departures. If the security contractor experiences […]

trending_flat
Securing LLMs Against Prompt Injection Attacks

[ad_1] Introduction Large Language Models (LLMs) have rapidly become integral to applications, but they come with some very interesting security pitfalls. Chief among these is prompt injection, where cleverly crafted inputs make an LLM bypass its instructions or leak secrets. Prompt injection in fact is so wildly popular that, OWASP now ranks prompt injection as the #1 AI security risk for modern LLM applications as shown in their OWASP GenAI top 10. We’ve provided a higher-level overview about Prompt Injection in our other blog, so in this one we’ll focus on the concept with the technical audience in mind. Here we’ll explore how LLMs can be vulnerable at the architectural level and the sophisticated ways attackers exploit them. We’ll also examine effective defenses, from system prompt design to “sandwich” prompting techniques. We’ll also discuss a few tools that can help […]

trending_flat
LLM Prompt Injection – What’s the Business Risk, and What to Do About It

[ad_1] The rise of generative AI offers incredible opportunities for businesses. Large Language Models can automate customer service, generate insightful analytics, and accelerate content creation. But alongside these benefits comes a new category of security risk that business leaders must understand: Prompt Injection Attacks. In simple terms, a prompt injection is when someone feeds an AI model malicious or deceptive input that causes it to behave in an unintended, and often harmful way. This isn’t just a technical glitch, it’s a serious threat that can lead to brand embarrassment, data leaks, or compliance violations if not addressed. As organizations rush to adopt AI capabilities, ensuring the security of those AI systems is now a board-level concern. In this post we’ll provide a high-level overview of prompt injection risks, why they matter to your business, and how Security Innovation’s GenAI Penetration […]

trending_flat
Setting Up a Pentesting Environment for the Meta Quest 2

[ad_1] With the advent of commercially available virtual reality headsets, such as the Meta Quest, the integration of virtual and augmented reality into our daily lives feels closer than ever before. As these devices become more common, so too will the need to secure and protect the data collected and stored by them. The intention of this blog post is to establish a baseline security testing environment for Meta Quest 2 applications and is split into three sections: Enabling Developer Mode, Establishing an Intercepting Proxy, and Injecting Frida Gadget. The Quest 2 runs on a modified version of the Android Open Source Project (AOSP) in addition to proprietary software developed by Meta, allowing the adoption of many established Android testing methods.   Enabling Developer Mode The first step of setting up a security testing environment on the Quest is to […]

trending_flat
Kiren Rijiju: Why Earth Sciences minister Rijiju is upset with this European IT company |

[ad_1] Earth Sciences Minister Kiren Rijiju is reportedly upset with the French IT company Atos. Reason is said to be delay in the delivery of two supercomputers by the French company to Indian weather forecasting institutes. According to a report in news agency PTI, the Earth Sciences Ministry had ordered two supercomputers worth $100 million from French firm Eviden, of the Atos Group, last year to enhance the computing capabilities of its institutions -- the National Centre for Medium Range Weather Forecasting (NCMRWF) and the Indian Institute of Tropical Meteorology (IITM)."I am more upset because the target we set was December. The Union Cabinet had already approved purchasing the supercomputer. We have only four petaflop capacity. We want to install up to 18 petaflop capacity," Rijiju told PTI in a video interview.He said that the French company ran into some […]

trending_flat
Former Activision boss reportedly wants to buy TikTok

[ad_1] Bobby Kotick, the former head of Activision Blizzard, is reportedly considering buying TikTok, as the app could be banned in the United States. The Wall Street Journal reports that Kotick has talked to ByteDance, the company that owns TikTok, about buying the app, which could cost hundreds of billions of dollars.This comes as US lawmakers introduce a new bill that would make ByteDance sell TikTok within six months or stop it from being available in US app stores.President Joe Biden has said he would approve the bill if it passes in Congress.The Wall Street Journal report adds that Kotick, the head of OpenAI, Sam Altman, discussed teaming up to buy TikTok at a dinner last week. Kotick's interest in TikTok follows a rough end to his 30 years leading Activision Blizzard, which Microsoft acquired last year. The company faced […]

Be the first to leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *