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

WebOTG-SM-009 — Unnecessary Features and Services

A structured procedure for identifying unnecessary features, services, components, interfaces and functionality that increase the attack surface of a web application or its supporting environment.

WebOTG ID SM-009 OWASP A02:2025 Type Attack Surface Review Method Configuration & Service Review Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that the application and its supporting environment expose only the features, services, components and interfaces required for legitimate business or operational purposes.

Every enabled service or application feature can increase the attack surface. Components that are not required for normal operation should generally be disabled, removed or isolated.

The review should consider not only visible application functionality but also administrative interfaces, diagnostic endpoints, legacy components and unnecessary network services.

"Unused" must be established, not assumed

Do not disable a component solely because it appears unused during a short test. Confirm its business or operational requirement with the system owner before removing it from a production environment.

02 / SCOPE

Scope

Review the following application and infrastructure surfaces where they are within the assessment scope:

Public application functionality
Administrative interfaces
Debug and diagnostic endpoints
Legacy application modules
Unused API endpoints
Optional framework modules
Web-server modules
Network-facing services
Sample, demo and test content
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to review and test application functionality and exposed services.
Architecture information Obtain an appropriate architecture or deployment overview where available.
Service inventory Obtain an authorized inventory of application and supporting services.
Business owner Identify an owner who can confirm whether potentially unused functionality is operationally required.
04 / METHODOLOGY

Methodology

Establish an inventory of exposed functionality and compare it with documented application requirements. Investigate components that cannot be justified by an identified business or operational need.

Method Purpose
Application mapping Identify publicly accessible and authenticated functionality.
Configuration review Identify enabled modules, features and services.
Endpoint review Identify legacy, diagnostic and administrative interfaces.
Service inventory comparison Determine whether exposed services have documented requirements.
05 / PROCEDURE

Test procedure

01
Establish the application baseline Document the application's intended functions, supported interfaces and required services.
02
Inventory enabled features Review application configuration, enabled modules and optional components.
03
Map accessible endpoints Identify administrative, diagnostic, legacy, test and other non-essential interfaces within the authorized scope.
04
Review supporting services Compare exposed network and application services with the documented architecture.
05
Identify unnecessary functionality Mark features or services that have no current documented business or technical requirement.
06
Assess exposure Determine whether the unnecessary functionality is externally reachable, authenticated or privileged.
06 / FEATURE CATEGORIES

Review categories

Category Examples
Diagnostic features Debug pages, diagnostic consoles, profiling interfaces and verbose status endpoints.
Development functionality Test pages, development utilities, sample controllers and development APIs.
Legacy functionality Deprecated endpoints, old application modules and previous API versions.
Administrative interfaces Management consoles and configuration interfaces not required for normal users.
Optional services Services enabled by default but not required by the deployed application.
Sample content Demo pages, sample files, documentation examples and installation content.

Example inventory

Illustrative service inventory EXAMPLE 
Component              Required     Exposure
------------------------------------------------
Web application        Yes          Public
Application API        Yes          Public
Admin console          Yes          Restricted
Debug endpoint         No           Public
Demo content            No           Public
Legacy API v1          No           Public
Monitoring endpoint    Yes          Internal

An inventory should explicitly identify why each externally reachable component exists. An undocumented service should not automatically be treated as a vulnerability; it should be investigated and justified.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Required feature Retain and apply appropriate access controls and configuration.
Unnecessary feature disabled Generally appropriate.
Development feature in production Assess as a configuration weakness, especially if externally accessible.
Legacy endpoint exposed Determine whether it remains required and whether it introduces avoidable attack surface.
Administrative interface exposed Verify that exposure is intentional and protected by appropriate authentication, authorization and network controls.
Sample/demo content exposed Remove when not required and assess whether it discloses implementation information.
08 / EXPECTED RESULT

Expected result

Pass condition

The deployed application exposes only functionality and services required for legitimate operation. Development, testing, legacy and unnecessary components are disabled, removed or appropriately isolated.

Administrative and operational interfaces that must remain enabled should have clearly defined access restrictions and should not be unnecessarily exposed to untrusted networks.

09 / FAILURE CRITERIA

Failure criteria

Development or debugging functionality remains unnecessarily enabled in production.
Deprecated application endpoints remain publicly accessible without a documented requirement.
Unnecessary administrative interfaces are exposed to untrusted networks.
Unused services remain network-accessible without an operational requirement.
Sample or demonstration functionality remains deployed unnecessarily.
Legacy components increase attack surface without a documented business justification.
Example finding ATTACK SURFACE

A production deployment contains a development diagnostic interface that is not required for normal operation and is reachable from an untrusted network. The interface should be removed, disabled or appropriately restricted.

10 / REMEDIATION

Remediation

Reduce the deployed attack surface by removing or disabling functionality that is not required for the application's intended operation.

Recommended approach

  1. Maintain an inventory of enabled application features and supporting services.
  2. Document the business or technical purpose of externally reachable functionality.
  3. Disable development and debugging functionality before production deployment.
  4. Remove sample, demo and installation content when it is no longer required.
  5. Retire deprecated APIs and legacy endpoints.
  6. Disable unnecessary framework and server modules.
  7. Restrict administrative interfaces to authorized networks and users.
  8. Remove unnecessary network-facing services.
  9. Include attack-surface review in deployment processes.
  10. Periodically revalidate the inventory after upgrades and architecture changes.

Example deployment configuration

Illustrative configuration EXAMPLE 
Environment: production

Debug mode:              disabled
Demo content:             removed
Test endpoints:           disabled
Legacy API:               disabled
Admin interface:          restricted
Required API:             enabled
Required monitoring:      internal only
Minimize without breaking required functionality

Attack-surface reduction must not become an excuse for undocumented production changes. Record approved exceptions and verify application dependencies before disabling services.

11 / VERIFICATION

Verification

01
Repeat application mapping Re-check the application and compare the accessible functionality with the original inventory.
02
Re-test identified interfaces Confirm that disabled development, diagnostic, legacy or unnecessary interfaces are no longer accessible.
03
Review service exposure Confirm that unnecessary network-facing services are no longer exposed.
04
Verify required functionality Confirm that legitimate application functions, integrations and monitoring continue to operate.
05
Verify persistence Confirm that disabled components do not become enabled again after application restart, deployment or configuration reload.
PASS

Only required features and services remain available and appropriately restricted.

FAIL

Unnecessary functionality or services remain exposed without adequate justification or controls.

NOT TESTED

The relevant feature, service or deployment configuration could not be adequately verified.

12 / EVIDENCE

Evidence requirements

Application and environment tested
Feature and service inventory
Documented requirement for retained services
Evidence of unnecessary functionality
Configuration before remediation
Remediation evidence
Post-remediation verification
Final PASS / FAIL determination
Sanitize infrastructure evidence

Remove credentials, private network addresses, internal hostnames, tokens, configuration secrets and other sensitive operational information before publishing evidence.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-009
OWASP category A02:2025 — Security Misconfiguration
Procedure type Feature, component and service attack-surface review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from exposure, privileges, exploitability and the security impact of the unnecessary component.
WebOTG classification notice

WebOTG-SM-009 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 application security testing methodology.
OWASP Application Security Verification Standard Application security verification requirements related to secure configuration and attack-surface reduction.
Vendor deployment documentation Required services, modules and secure production deployment configuration.
Organizational architecture standards Approved application components, services and network exposure.

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.