Objective
Verify that only required application functionality, services, modules and protocols are enabled and exposed in the production environment.
Every enabled component adds potential attack surface. A feature that is not required by the application's business function provides little security value while potentially introducing additional code paths, configuration requirements, vulnerabilities and administrative complexity.
This procedure therefore evaluates whether the deployed system follows the principle of least functionality: enable what is required, restrict what must remain, and remove what has no legitimate operational purpose.
A feature should not be disabled solely because it appears unused during testing. Confirm its operational purpose with the system owner or approved architecture documentation before removing it from production.
Scope
Review applicable functionality across:
Prerequisites
| Authorization | Confirm authorization to inspect and test the application's exposed functionality. |
|---|---|
| Architecture | Understand the intended application architecture and major functional components. |
| Service inventory | Obtain an inventory of enabled services, modules, endpoints and externally reachable interfaces where possible. |
| Business requirements | Identify which features are required for normal business operations. |
Methodology
Build a functional inventory of the application and supporting web stack. For each exposed capability, determine its purpose, intended users, exposure boundary and security necessity.
| Review | Purpose |
|---|---|
| Enabled functionality | Identify features that are active in the deployed environment. |
| External exposure | Determine which functionality is reachable by untrusted clients. |
| Business necessity | Determine whether each feature has a legitimate operational requirement. |
| Access boundary | Determine whether administrative or sensitive functionality is restricted appropriately. |
| Component dependencies | Identify whether disabling a feature could affect required application functionality. |
Test procedure
Features and services to review
Debug consoles, profilers, development toolbars, trace endpoints and verbose diagnostic interfaces.
Management panels and administrative endpoints that are not required to be publicly reachable.
Older or insecure protocols retained despite having no current business requirement.
Directory browsing, file-management interfaces or transfer functionality not required by the application.
Demonstration applications, test routes, examples and vendor-provided sample functionality.
Plugins, modules or extensions installed but not required for the application's operation.
Health, metrics, tracing or diagnostic endpoints whose exposure is broader than required.
Legacy API versions or endpoints retained after their intended functionality has been retired.
Example exposure
GET /debug/ HTTP/1.1
Host: application.example
HTTP/1.1 200 OK
Content-Type: text/html
Development Debug Console
[Request]
[Environment]
[Database]
[Configuration]The existence of an endpoint alone is insufficient to establish a security finding. Determine whether the functionality is required, who can access it, what it exposes or permits, and whether its exposure violates the approved security configuration.
Assessment
| Condition | Assessment consideration |
|---|---|
| Required feature | No finding solely because the feature is enabled, provided it is securely configured and appropriately exposed. |
| Required but unnecessarily exposed | Assess whether the access boundary can be reduced to the intended users or networks. |
| Unused feature | Determine whether it can be disabled without affecting required functionality. |
| Legacy feature | Determine whether the feature remains necessary and whether a supported replacement exists. |
| Debug functionality | Determine whether development-only functionality is accessible in production. |
| Administrative feature | Verify that access is restricted to authorized administrators. |
Expected result
Production deployments expose only functionality required for legitimate business and operational purposes, with administrative and sensitive functionality restricted to its intended access boundary.
Unnecessary modules, services, endpoints and development features should be disabled or removed where technically and operationally appropriate.
Failure criteria
A production application exposes a development diagnostics interface that is not required for normal application operation. The interface provides additional functionality and diagnostic information to clients beyond the application's intended public feature set.
Remediation
Reduce the deployed attack surface to the minimum functionality required by the application's approved architecture and business requirements.
Recommended approach
- Maintain an inventory of enabled application and infrastructure functionality.
- Document the business or operational purpose of each exposed feature.
- Disable development-only and testing functionality in production.
- Remove unused modules, plugins and extensions.
- Disable unnecessary services and protocols.
- Remove obsolete or retired API versions where operationally possible.
- Restrict administrative and diagnostic interfaces to authorized users or trusted network boundaries.
- Apply the minimum required privileges to services that must remain enabled.
- Include feature and service minimization in the standard deployment baseline.
- Re-test application functionality after changes.
Example production baseline
Required application feature -> ENABLED
Required admin feature -> RESTRICTED
Development feature -> DISABLED
Debug endpoint -> DISABLED
Sample application -> REMOVED
Unused plugin -> REMOVED
Legacy API -> RETIRED
Unused protocol -> DISABLED
Diagnostic interface -> RESTRICTEDDo not treat "disable everything possible" as a security strategy. Features required by the business must remain available and should instead be securely configured and appropriately restricted.
Verification
Unnecessary functionality has been removed, disabled or appropriately restricted while required services remain operational.
Unnecessary functionality remains exposed or creates material additional security risk.
The relevant feature, service or configuration could not be adequately evaluated.
Evidence requirements
Screenshots, configuration files and response captures may contain internal hostnames, credentials, tokens, personal information or other sensitive data. Remove such information before publishing evidence publicly.
Classification
| WebOTG procedure | WebOTG-SM-023 |
|---|---|
| OWASP category | A02:2025 — Security Misconfiguration |
| Procedure type | Feature, service and attack-surface minimization review |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine from the exposure, privileges, affected functionality, exploitability and resulting security impact. |
WebOTG-SM-023 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 | Testing methodology relevant to configuration and exposed functionality. |
| OWASP Application Security Verification Standard | Verification requirements relevant to secure configuration and deployment. |
| Vendor secure deployment documentation | Component-specific guidance for production feature and service configuration. |
| Organization security baseline | Defines approved enabled functionality, service exposure and administrative access requirements. |
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.