WebOTG Security Testing Library ● Public reference
W WebOTG
Search
WebOTG
Standards Countries Topics Resources About
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-002 — Default and Known Files

A structured procedure for identifying default, sample, installation, documentation, test and other known files that may be unnecessarily exposed by a web application or its supporting web server.

WebOTG ID SM-002 OWASP A02:2025 Type Resource Exposure Method Manual / Automated Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that default, sample, installation, documentation and other known files that are not required for normal production operation are not unnecessarily accessible through the web application.

Web applications are frequently deployed from frameworks, application servers, CMS packages, development templates or vendor distributions that contain files which are useful during installation or development but unnecessary after deployment.

If these files remain accessible, they may disclose implementation details, configuration information, application versions or other information useful to an attacker.

02 / SCOPE

Scope

Consider the following resource classes during the review:

Default application pages
Framework sample files
Installation and setup resources
Example configuration files
Default documentation or help resources
Test and demonstration resources
Default administrative resources
Vendor or framework metadata resources
03 / PREREQUISITES

Prerequisites

Authorization Confirm that the target is authorized for security testing.
Application inventory Identify the application, framework, server and major components.
Deployment information Understand the intended public web root and application resource structure.
Test environment Prefer a controlled environment where potentially sensitive files can be safely examined.
04 / METHODOLOGY

Methodology

Use multiple discovery sources rather than relying on a single list of filenames. Known files vary according to the framework, server, application version and deployment process.

Discovery source Purpose
Application documentation Identify files supplied by the framework or application.
Deployment package Identify resources that were installed with the application.
Public application behavior Identify resources exposed through normal HTTP requests.
Source and configuration review Determine whether files are intended to be publicly accessible.
Automated discovery Efficiently identify candidate resources for manual validation.
Do not treat every unknown file as a vulnerability

A file becomes a security concern when it is unnecessarily exposed and creates meaningful information disclosure, functionality exposure or another security impact.

05 / PROCEDURE

Test procedure

Authorized testing only

Perform resource discovery only against systems for which you have explicit authorization. Keep request volume appropriate for the target and avoid unnecessary stress on production systems.

01
Identify the technology stack Determine the application framework, CMS, web server and other technologies relevant to the deployment.
02
Establish the intended public resource set Determine which directories and files are intentionally part of the public application.
03
Build a candidate file inventory Use application documentation, deployment artifacts, source review and approved discovery tooling to identify candidate default resources.
04
Request candidate resources Request identified candidates using normal HTTP methods and record the resulting status, content type and response behavior.
05
Determine whether exposure is intentional Establish whether each accessible resource is required for normal application operation or is an unnecessary deployment artifact.
06
Assess security impact Determine whether the resource discloses sensitive information, exposes unnecessary functionality or provides useful information about the target environment.
06 / DISCOVERY

Controlled discovery

Discovery should begin with low-impact methods. Escalate only when necessary and when the testing authorization permits it.

Example request

HTTP request EXAMPLE 
GET /example-resource HTTP/1.1
Host: example.test
Accept: */*

Candidate resources

Depending on the technology stack, candidates may include resources such as:

Candidate classes EXAMPLES 
/installation/
/install/
/setup/
/examples/
/samples/
/demo/
/docs/
/documentation/
/test/
/tests/

These paths are examples only. Do not assume that a resource exists on every application or that its presence automatically constitutes a vulnerability.

Response assessment

Observation Interpretation
404 / equivalent Resource was not found or is not exposed.
403 / equivalent Resource may exist but direct access is restricted.
Successful response Resource requires further review to determine whether exposure is intended.
Redirect Follow the intended application flow and determine the final resource exposure.
07 / EXPECTED RESULT

Expected result

Pass condition

Default, sample, installation and other unnecessary resources are either removed from the deployment, located outside the public web root or appropriately restricted from unauthorized access.

Resources that are intentionally public and required for application operation should not be reported merely because they originated from a framework or vendor distribution.

08 / FAILURE CRITERIA

Failure criteria

Consider the procedure failed when an unnecessary resource is publicly accessible and creates a meaningful security exposure.

Example finding REVIEW REQUIRED

A default or installation resource is accessible from the public application and discloses implementation or configuration information that is not required for normal application operation.

Unnecessary installation functionality remains accessible.
Sample or demonstration resources expose implementation information.
Default administrative or diagnostic resources are unnecessarily exposed.
Documentation or metadata exposes sensitive deployment information.
A known resource provides unnecessary information that materially assists further attack activity.
09 / REMEDIATION

Remediation

Remove unnecessary resources from production wherever possible. If a resource is required for operational reasons, restrict access to the smallest appropriate audience.

Preferred remediation order

  1. Remove unnecessary files from the production deployment.
  2. Place internal resources outside the public web root.
  3. Restrict required administrative resources through authentication and authorization controls.
  4. Apply network restrictions where appropriate.
  5. Ensure deployment pipelines do not reintroduce removed resources.
  6. Document intentionally exposed resources.

Example deployment structure

Recommended separation EXAMPLE 
/var/www/
├── public/
│   ├── index.php
│   ├── assets/
│   └── uploads/
│
└── application/
    ├── config/
    ├── storage/
    ├── logs/
    └── internal/

The exact directory structure depends on the technology stack. The security principle is to separate publicly served resources from internal application resources.

10 / VERIFICATION

Verification

After remediation, repeat the requests that previously demonstrated exposure. Verification should confirm both the security control and continued availability of legitimate application resources.

01
Repeat the original request Request the resource that was previously identified as unnecessarily exposed.
02
Confirm restricted behavior Verify that the resource is removed or that appropriate access controls now prevent unauthorized access.
03
Verify legitimate functionality Confirm that required application functionality remains operational after the change.
04
Review deployment output Confirm that the removed resource is not automatically restored during the next deployment.
PASS

The unnecessary resource is no longer publicly accessible.

FAIL

The resource remains unnecessarily exposed after remediation.

NOT TESTED

The required resource or verification condition could not be evaluated.

11 / EVIDENCE

Evidence requirements

Capture enough information to establish what resource was tested, why it was considered unnecessary and what happened after remediation.

Target URL or resource identifier
HTTP method used
Relevant response status
Relevant response headers
Sanitized response content where necessary
Explanation of why the resource is unnecessary
Remediation evidence
Post-remediation retest
Never publish sensitive contents

Evidence must not expose credentials, secrets, private keys, session tokens or other sensitive information. Redact sensitive values before publishing or sharing evidence.

12 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-002
OWASP category A02:2025 — Security Misconfiguration
Procedure type Default and known resource exposure
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine based on the information disclosed, exposed functionality and resulting security impact.
WebOTG classification notice

WebOTG-SM-002 is a WebOTG-defined verification procedure. It is not an OWASP-defined test identifier.

13 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Configuration and Deployment Management Testing.
OWASP ASVS Application security verification requirements.
CWE Weakness classification and supporting security references.

Reference links and source versions should be maintained centrally through the WebOTG content-management system so that published procedures can be updated without modifying the page template.