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

WebOTG-SM-022 — Insecure Default Configuration

A structured procedure for identifying vendor defaults, default accounts, sample content, unnecessary services, development features and other preconfigured settings that unnecessarily increase the application's attack surface.

WebOTG ID SM-022 OWASP A02:2025 Type Configuration Review Method Manual Verification Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that the application and its supporting web infrastructure do not retain insecure vendor defaults, development configurations, sample functionality, unnecessary services or default credentials that increase the exposed attack surface.

Modern applications frequently depend on web servers, frameworks, CMS platforms, databases, containers, reverse proxies, identity providers and third-party components. These components may ship with convenient defaults intended for installation or development rather than secure production operation.

The assessment should therefore examine the effective deployed configuration rather than relying only on the application's source-code configuration.

Default does not automatically mean vulnerable

A default setting should be treated as a security concern when it creates unnecessary exposure, privileges, functionality or trust. Do not report harmless defaults merely because they were supplied by a vendor.

02 / SCOPE

Scope

Review applicable defaults across:

Application configuration
Web-server configuration
Reverse proxy and gateway configuration
Framework configuration
CMS and administration interfaces
Default or sample accounts
Sample applications and documentation
Development and debugging functionality
Unnecessary exposed services and interfaces
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to test the application and its exposed interfaces.
Deployment model Understand whether the target is self-hosted, cloud-hosted, containerized or managed by a platform provider.
Component inventory Obtain an authorized inventory of major application, framework, server and infrastructure components where possible.
Configuration baseline Identify the organization's approved production configuration baseline.
04 / METHODOLOGY

Methodology

Identify the effective configuration of the deployed application and compare it with the organization's approved security baseline and the vendor's documented secure-production guidance.

Review Purpose
Default credentials Determine whether vendor or installer credentials remain active.
Default interfaces Identify administration, diagnostics, examples or management functionality unnecessarily exposed.
Development configuration Determine whether debugging, verbose errors or development features remain enabled.
Sample content Identify demonstration pages, applications, accounts and files that are not required in production.
Service exposure Determine whether unnecessary services or management endpoints are reachable.
05 / PROCEDURE

Test procedure

01
Establish the component inventory Identify the major technologies, application components and infrastructure layers within the authorized assessment scope.
02
Identify vendor defaults Review official deployment documentation and approved configuration baselines for known default accounts, interfaces and settings.
03
Enumerate exposed interfaces Review the application's authorized URL space for administrative, diagnostic, sample and management interfaces.
04
Review configuration state Compare the effective production configuration against the organization's approved baseline.
05
Test default authentication safely Where explicitly authorized, verify whether documented vendor or installer credentials remain active. Avoid unnecessary account lockouts.
06
Determine actual security impact Establish whether the default creates meaningful unauthorized access, unnecessary exposure, excessive privilege or another security weakness.
06 / DEFAULT CONDITIONS

Default conditions to review

DEFAULT ACCOUNTS

Vendor, installer, administrator or demonstration accounts that remain enabled after deployment.

DEFAULT PASSWORDS

Credentials supplied during installation or documented by the vendor that have not been changed or disabled.

DEBUG MODE

Development diagnostics, verbose exceptions or debugging functionality exposed in production.

SAMPLE CONTENT

Demonstration pages, sample applications, installation files or example resources.

ADMIN INTERFACES

Management interfaces exposed more broadly than required by the application's operational model.

UNNECESSARY SERVICES

Services or modules enabled by default but not required for the deployed application.

DEFAULT FILES

Installation artifacts, test files, documentation or configuration examples accessible to clients.

PERMISSIVE DEFAULTS

Broad access controls, trust relationships or security settings inherited from installation defaults.

Example: default installation page

HTTP response EXAMPLE 
HTTP/1.1 200 OK
Content-Type: text/html

Welcome to the default application installation.

Application version: 4.x
Installation status: incomplete

/admin/
/setup/
/examples/
Do not assume that an unlinked resource is inaccessible

A management or installation resource does not need to appear in the application's navigation to be reachable. Authorized testing should consider documented administrative and deployment paths as part of the exposure review.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Default exists but is disabled Normally acceptable if the component is otherwise configured according to the approved baseline.
Default account remains active Determine its privileges, authentication requirements and exposure.
Sample content exposed Assess whether it reveals information, enables functionality or increases the attack surface.
Debug mode enabled Determine whether diagnostics or other development functionality are exposed to untrusted clients.
Unnecessary service enabled Determine whether the service creates an avoidable externally reachable attack surface.
Default configuration differs from policy Record the deviation and determine whether it creates an actual security weakness.
08 / EXPECTED RESULT

Expected result

Pass condition

Production systems use an approved security configuration in which unnecessary defaults, default credentials, sample functionality, development features and unnecessary services are disabled, removed or appropriately restricted.

Every enabled component should have an identified operational purpose and an appropriate security configuration.

09 / FAILURE CRITERIA

Failure criteria

A known default credential remains usable in a production environment.
A default administrative account remains enabled without a documented operational requirement.
Installation, setup or sample functionality is accessible to unauthorized users.
Development or debug functionality is exposed in production.
An unnecessary service or module is externally reachable and materially increases attack surface.
A permissive vendor default creates unauthorized access or another material security weakness.
Example finding INSECURE DEFAULT

A production deployment retains a vendor-provided administrative interface that is not required for normal application operation. The interface is reachable by untrusted clients and exposes management functionality beyond the application's intended public attack surface.

10 / REMEDIATION

Remediation

Replace installation defaults with an explicit, documented production security baseline.

Recommended approach

  1. Inventory all deployed application and infrastructure components.
  2. Review the vendor's current secure-production configuration guidance.
  3. Disable or remove default accounts that are not required.
  4. Replace vendor or installer credentials with organization-controlled authentication.
  5. Disable production debug and development modes.
  6. Remove sample applications, demonstration content, installation files and unnecessary documentation.
  7. Disable unnecessary modules and services.
  8. Restrict management interfaces to authorized administrative networks or identities.
  9. Apply explicit access-control and security settings rather than relying on permissive defaults.
  10. Document approved deviations where a default must remain enabled for a legitimate operational reason.
  11. Re-test the effective deployed configuration after remediation.

Example configuration principle

Production baseline CONCEPTUAL 
Default account       -> Disabled / replaced
Default password      -> Changed / removed
Debug mode            -> Disabled
Sample application    -> Removed
Installation endpoint -> Disabled
Unused module         -> Disabled
Admin interface       -> Restricted
Production policy     -> Explicitly defined
Do not change production defaults blindly

Configuration changes can break authentication, integrations or application functionality. Establish the intended production state first, apply changes through controlled deployment processes, and then verify both security and functionality.

11 / VERIFICATION

Verification

01
Repeat the original test Re-test the default configuration or exposed interface that caused the original finding.
02
Verify default credentials Where authorized, confirm that previously active vendor or installer credentials can no longer authenticate.
03
Verify administrative exposure Confirm that unnecessary management and installation interfaces are no longer publicly reachable.
04
Verify development features Confirm that debug pages, sample functionality and verbose development behavior are disabled.
05
Verify service exposure Confirm that unnecessary modules and services are disabled or appropriately restricted.
06
Verify application functionality Confirm that required business functions and authorized administrative operations continue to work normally.
PASS

Insecure defaults have been removed, disabled or appropriately restricted and the intended application functionality remains operational.

FAIL

A material insecure default remains exploitable or unnecessarily exposed.

NOT TESTED

The relevant configuration or default behavior could not be adequately evaluated.

12 / EVIDENCE

Evidence requirements

Component or service assessed
Default configuration or behavior identified
Endpoint, interface or configuration evidence
Security impact
Before-remediation evidence
Approved baseline or configuration requirement
Remediation evidence
Post-remediation verification
Functional verification
Final PASS / FAIL determination
Protect configuration evidence

Configuration files and screenshots can contain credentials, tokens, internal addresses and other sensitive information. Sanitize evidence before publication or inclusion in a public report.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-022
OWASP category A02:2025 — Security Misconfiguration
Procedure type Default configuration and attack-surface review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from the privilege, exposure, exploitability and security impact of the insecure default.
WebOTG classification notice

WebOTG-SM-022 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 testing methodology relevant to configuration and deployment security.
OWASP Application Security Verification Standard Verification requirements relevant to secure configuration and deployment.
Vendor secure deployment documentation Defines component-specific production configuration requirements.
Organization security baseline Defines approved configuration, authentication and service-exposure 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.