WebOTG Security Testing Library ● Public reference
WebOTG
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-004 — Directory Listing and Indexing

A structured procedure for identifying unintended directory listing, directory indexing and file enumeration exposure in publicly accessible web application paths.

WebOTG ID SM-004 OWASP A02:2025 Type Information Exposure Method HTTP / Configuration Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that web server directory indexing is not unintentionally enabled for directories where listing their contents could disclose unnecessary files or information.

Directory indexing occurs when a web server generates a response containing a listing of files and directories because an index resource is absent and directory browsing is permitted.

Directory listings can expose deployment artifacts, backup files, uploaded content, application resources, documentation or other information that was not intended to form part of the public interface.

Directory listing is not always a vulnerability

Some applications intentionally expose directory listings. Report the condition when the listing is unnecessary and creates a meaningful security or information-disclosure risk.

02 / SCOPE

Scope

Review publicly accessible directories including, where applicable:

Static asset directories
Upload directories
Documentation directories
Temporary or generated resource directories
Public download directories
Legacy application directories
Framework or CMS resource directories
Any other publicly routable directory
03 / PREREQUISITES

Prerequisites

Authorization Confirm explicit authorization to test the target application.
Application inventory Identify known public directories and application resource locations.
Web server Identify the web server or reverse proxy responsible for serving resources.
Expected behavior Establish whether any directory listing is intentionally required.
04 / METHODOLOGY

Methodology

The assessment should combine direct HTTP observation with configuration review. A successful directory response alone does not establish that the exposure is a security finding.

Method Purpose
Application mapping Identify directories intended to be publicly accessible.
HTTP request Determine whether a directory produces a generated listing.
Response inspection Identify files and metadata disclosed by the listing.
Configuration review Determine whether directory indexing is intentionally enabled.
05 / PROCEDURE

Test procedure

Authorized testing only

Perform directory discovery only against systems for which testing authorization has been granted. Keep request volume proportionate to the assessment.

01
Identify candidate directories Use application mapping, documentation, source review and authorized discovery to identify publicly routable directories.
02
Request the directory path Make a normal HTTP request to the directory without specifying a particular file.
03
Inspect the response Determine whether the response is an application page, redirect, access denial, not-found response or generated directory listing.
04
Review disclosed entries Identify whether the listing reveals unnecessary files, directories, metadata or deployment information.
05
Determine intended exposure Confirm with the application owner or deployment documentation whether the listing is required.
06
Assess security impact Determine whether the exposed information materially increases security risk.
06 / DISCOVERY

Directory discovery

Example HTTP request

HTTP request EXAMPLE
GET /assets/ HTTP/1.1
Host: example.test
Accept: text/html

Potential response indicators

Observation Interpretation
Application-generated page Directory may not be directly indexed. Continue evaluating application behavior.
403 / access denied Directory access is restricted.
404 / not found Directory may not be publicly routable.
Generated file listing Directory indexing is potentially enabled and requires further assessment.
Redirect to index resource Review the final destination and determine whether it represents intentional behavior.
Do not rely solely on HTTP status codes

A 200 response does not necessarily indicate directory indexing, and a 403 response does not prove that sensitive files are inaccessible through every route. Review the actual application behavior.

07 / ASSESSMENT

Exposure assessment

The security significance of directory indexing depends primarily on what the listing exposes and whether those resources are intended to be public.

Exposure Assessment consideration
Public static assets Usually expected when required by the application's frontend.
User uploads Review whether filenames and metadata are intended to be enumerable.
Backup files Potentially significant if source, configuration or sensitive data is exposed.
Internal documentation Determine whether the information is intended for public users.
Temporary files Usually unnecessary in the public application and should be reviewed.
Configuration artifacts Treat as potentially sensitive and investigate immediately.
08 / EXPECTED RESULT

Expected result

Pass condition

Directory contents are not unnecessarily enumerated through public HTTP requests, and resources that require public listing are intentionally documented and contain only information approved for public exposure.

The preferred default for most application directories is to serve known resources rather than expose an automatically generated directory index.

09 / FAILURE CRITERIA

Failure criteria

Consider the procedure failed when directory indexing is unintentionally enabled and the resulting exposure creates a meaningful security or information-disclosure risk.

Internal or unnecessary files are exposed through an automatically generated directory listing.
Backup, temporary or deployment artifacts are publicly enumerated.
Directory contents reveal sensitive application structure or implementation information.
Upload or generated-content directories allow unnecessary enumeration.
Directory indexing is enabled without a documented business or technical requirement.
Example finding REVIEW REQUIRED

An application directory generates a public file listing containing deployment and temporary resources that are not required for normal application operation.

10 / REMEDIATION

Remediation

Disable automatic directory indexing for directories where listing is not required. Remove unnecessary files from the public web root wherever possible.

Recommended approach

  1. Disable directory indexing by default.
  2. Remove unnecessary files from public directories.
  3. Move internal resources outside the public web root.
  4. Restrict directories that must remain accessible.
  5. Ensure upload directories expose only intended resources.
  6. Review deployment pipelines for accidental publication of temporary or backup files.
  7. Document any intentional public directory listing.

Apache example

Illustrative configuration APACHE
<Directory "/var/www/public">

    Options -Indexes

</Directory>

Nginx example

Illustrative configuration NGINX
location / {
    autoindex off;
}
Configuration depends on deployment

The examples are illustrative. Apply the setting at the correct server, virtual host, location or application layer and confirm that inherited configuration does not override the intended behavior.

11 / VERIFICATION

Verification

01
Repeat the original request Request the directory path that previously generated the directory listing.
02
Confirm listing removal Verify that an automatic directory listing is no longer returned.
03
Verify legitimate resources Request known files that must remain publicly accessible and confirm normal functionality.
04
Verify deployment persistence Confirm that subsequent deployments do not re-enable directory indexing or republish unnecessary files.
PASS

Unnecessary directory listing is no longer publicly available.

FAIL

The identified directory exposure remains after remediation.

NOT TESTED

The required directory or verification condition could not be evaluated.

12 / EVIDENCE

Evidence requirements

Target application and environment
Directory path tested
HTTP request method
Original response
Files or information exposed
Security impact assessment
Remediation evidence
Post-remediation response
Evidence must be sanitized

Do not publish credentials, tokens, private configuration, personal data or other sensitive information that may have been exposed during testing.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-004
OWASP category A02:2025 — Security Misconfiguration
Procedure type Directory listing and indexing review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from the nature and sensitivity of the exposed resources and their resulting security impact.
WebOTG classification notice

WebOTG-SM-004 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.

14 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Web server and configuration testing methodology.
OWASP ASVS Application security verification requirements.
Web server documentation Platform-specific directory indexing configuration and behavior.

WebOTG should maintain source URLs, document versions and review dates centrally through its content-management system so that references can be updated without modifying the procedure template.