Objective
Verify that only services, interfaces and application functionality required for the intended operation of the system are exposed and that unnecessary or default components are disabled or appropriately restricted.
Web applications frequently depend on multiple layers: web servers, reverse proxies, application servers, management interfaces, monitoring components, debugging tools and third-party services.
Every externally reachable component increases the system's attack surface. Components that are installed by default, no longer required or unintentionally exposed may introduce additional vulnerabilities or disclose information about the environment.
A service is not automatically insecure merely because it is reachable. The assessment must establish whether the service is required, authorized, appropriately protected and consistent with the documented system architecture.
Scope
Review externally reachable and application-accessible components including:
Prerequisites
| Authorization | Confirm authorization to assess the application's exposed services and interfaces. |
|---|---|
| Architecture | Obtain the relevant application and infrastructure architecture where available. |
| Service inventory | Identify expected web servers, proxies, application services and management interfaces. |
| Environment information | Determine whether the target represents development, testing, staging or production infrastructure. |
Methodology
Establish the intended service baseline and compare it with the services and interfaces actually exposed by the deployed system.
| Review | Purpose |
|---|---|
| Service inventory review | Identify expected services and determine whether exposed components have a documented business or technical purpose. |
| Endpoint discovery | Identify publicly reachable application, administrative and diagnostic interfaces. |
| Default-content review | Identify vendor default pages, sample applications and installation artifacts. |
| Configuration review | Determine whether unnecessary services and modules are disabled or restricted. |
| Access-control review | Verify that required management and diagnostic services are appropriately protected. |
Test procedure
Service and functionality categories
| Category | Review focus |
|---|---|
| Default pages | Vendor installation pages, welcome pages and sample applications should not remain unintentionally accessible. |
| Debug functionality | Development and debugging features should not be unnecessarily enabled in production. |
| Administration | Management interfaces should be restricted to authorized users and appropriate networks. |
| Diagnostics | Diagnostic endpoints should expose only information required for their operational purpose. |
| Monitoring | Monitoring interfaces should not be unnecessarily exposed to public users. |
| Legacy components | Deprecated modules, old application paths and unused services should be removed or disabled. |
| Network-facing services | Services should be exposed only where required by the documented architecture. |
Example default-content finding
HTTP/1.1 200 OK
Content-Type: text/html
Server installation / default welcome page
Application functionality: not requiredThe presence of a default page is evidence of unnecessary deployed content only when the page is not intentionally required. Confirm the deployment baseline before raising a finding.
Assessment
| Condition | Assessment consideration |
|---|---|
| Required and appropriately restricted | No finding solely because the service exists. |
| Required but unnecessarily exposed | Assess whether network or access-control restrictions are insufficient. |
| Unnecessary service | Recommend removal or disabling where operationally feasible. |
| Default component | Determine whether it is an installation artifact or intentionally deployed. |
| Debug/development feature in production | Determine whether it exposes sensitive information or unnecessary functionality. |
Expected result
The deployed environment exposes only services, interfaces and functionality required by its documented architecture, and required administrative, diagnostic or operational services are appropriately restricted.
Production deployments should not unnecessarily expose installation artifacts, sample applications, development functionality, debugging interfaces or unused management services.
Failure criteria
A production web deployment exposes a management interface that is not required for public application operation and is reachable from an untrusted network. The interface should be removed from public exposure or restricted to authorized management networks.
Remediation
Reduce the deployed attack surface by removing unnecessary components and restricting services that are required for administration or operations.
Recommended approach
- Maintain an authoritative inventory of deployed services and application components.
- Identify the business or operational purpose of each externally reachable component.
- Remove unused services, modules and applications.
- Disable default sample content and installation interfaces after deployment.
- Disable development and debugging functionality in production unless explicitly required.
- Restrict administrative and management interfaces to authorized users and appropriate networks.
- Restrict diagnostic and monitoring endpoints to their intended consumers.
- Remove obsolete application paths and legacy components.
- Apply infrastructure configuration consistently across production instances.
- Re-test service exposure after deployment changes.
Example deployment baseline
Public application
├── Required web service
└── Required application endpoints
Management
├── Restricted network access
└── Strong authentication
Diagnostics
├── Restricted access
└── Minimum required information
Development
├── Debug features disabled
└── Sample applications removed
Legacy
└── Unused components removedHiding an unnecessary service behind an obscure URL does not remove the underlying attack surface. When a component is not required, removal or complete disabling is generally preferable to relying on obscurity.
Verification
Only required services are exposed and management or diagnostic functionality is appropriately restricted.
An unnecessary or inadequately restricted service remains exposed.
The effective service exposure or configuration could not be adequately determined.
Evidence requirements
Remove credentials, private network addresses, internal hostnames, management URLs, access tokens and other sensitive infrastructure information before publishing or sharing assessment evidence.
Classification
| WebOTG procedure | WebOTG-SM-016 |
|---|---|
| OWASP category | A02:2025 — Security Misconfiguration |
| Procedure type | Service and deployment exposure review |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine from the exposed service, accessibility, authentication controls, information or functionality exposed, exploitability and resulting security impact. |
WebOTG-SM-016 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.
References
| Source | Relevance |
|---|---|
| OWASP Top 10:2025 — A02 | Security Misconfiguration category. |
| OWASP Web Security Testing Guide | Web application security testing methodology and configuration review. |
| OWASP Application Security Verification Standard | Application security verification requirements relevant to secure configuration and deployment. |
| Application architecture documentation | Defines services and components intentionally required by the deployment. |
| Infrastructure security baseline | Defines organizational requirements for service exposure and management access. |
WebOTG should maintain official source URLs, source versions and review dates through its content-management system so references can be updated independently of the procedure template.