What are we verifying?
Verify that the application and its supporting infrastructure use secure configurations appropriate to their intended function and deployment environment, and that unnecessary functionality or information is not exposed.
Security misconfiguration occurs when security controls are missing, incorrectly implemented, unnecessarily enabled, inconsistently configured or left in an insecure default state.
The assessment can extend beyond application source code to web servers, application servers, frameworks, databases, cloud services, containers, operating systems and administrative interfaces.
An application can contain secure code and still be vulnerable because its deployed environment is incorrectly configured.
What should be tested?
The scope should include configuration controls that can expose information, functionality, credentials, services or infrastructure.
| Component | Areas to review |
|---|---|
| Application | Debug mode, error handling, environment configuration and insecure defaults. |
| Web server | Directory listing, HTTP methods, exposed files and server configuration. |
| Framework | Development features, default routes, middleware and security settings. |
| Database | Network exposure, accounts, privileges and unnecessary services. |
| Cloud services | Storage permissions, public resources, network policies and service configuration. |
| Containers | Privileges, exposed ports, secrets and runtime configuration. |
| Administration | Management interfaces, default accounts and administrative access paths. |
How to identify misconfiguration
Start with the intended security baseline for the environment. Compare the deployed configuration and externally observable behavior against that baseline.
Configuration review
- Identify development-only functionality exposed in production.
- Review error responses for unnecessary internal information.
- Identify unnecessary services, features and administrative interfaces.
- Review exposed files, directories and resources.
- Review default accounts and credentials.
- Review file and directory permissions.
- Compare security configuration between environments.
- Review cloud and infrastructure permissions.
Configuration baseline
| Baseline item | Expected state |
|---|---|
| Debugging | Disabled in production |
| Default credentials | Removed or securely changed |
| Directory indexing | Disabled unless explicitly required |
| Administrative interfaces | Restricted to authorized access |
| Unnecessary services | Disabled or removed |
| Error disclosure | No unnecessary sensitive details |
WebOTG verification procedures
The following procedures are WebOTG testing procedures mapped to the OWASP Top 10:2025 A02 category. They are not OWASP-defined test identifiers.
Review application platform configuration
Procedure
- Identify the application framework and runtime environment.
- Obtain the approved configuration baseline.
- Review security-relevant configuration values.
- Compare deployed configuration against the approved baseline.
- Record deviations that introduce security exposure.
Expected result
Security-relevant platform settings conform to the approved configuration baseline.
Failure criteria
A security-relevant configuration is missing, insecure, unnecessarily enabled or inconsistent with the approved baseline.
Check for default and known files
Procedure
- Identify files installed by the application or framework that are not required in production.
- Determine whether those files are accessible through the web server.
- Review accessible files for information that should not be publicly available.
- Remove unnecessary files or restrict access where required.
Expected result
Unnecessary sample, test, installation or default files are not publicly accessible.
Verify debugging functionality
Procedure
- Confirm the environment under test.
- Review the application's production configuration.
- Trigger a controlled, harmless application error.
- Review the response for stack traces, internal paths, configuration details, credentials or other sensitive information.
Expected result
Production error handling does not expose unnecessary implementation or configuration details.
Verify error information disclosure
Procedure
- Identify controlled error conditions.
- Trigger each condition in the authorized test environment.
- Capture the resulting response.
- Review the response for internal paths, framework details, database information, stack traces or secrets.
Expected result
Error responses provide useful user-facing information without unnecessary internal implementation details.
Verify directory indexing
Procedure
- Identify directories intended to be web-accessible.
- Determine whether directory indexing is enabled by the web server.
- In an authorized environment, request a test directory without an index resource.
- Review the server response.
Expected result
Directory contents are not listed unless directory indexing is explicitly required and controlled.
Review sensitive file handling
Procedure
- Identify application configuration, backup and source-related file types.
- Determine whether any are located inside web-accessible directories.
- Verify server behavior for authorized test files.
- Confirm that protected files are not returned as downloadable content.
Expected result
Sensitive configuration, source, backup and internal files are not unintentionally served by the web server.
Review backup and unreferenced files
Procedure
- Review deployment directories.
- Identify backup and temporary artifacts.
- Determine whether those artifacts are accessible through the web server.
- Remove unnecessary artifacts or move them outside the public web root.
Expected result
Backup and temporary files are not publicly accessible unless explicitly required.
Verify administrative interface exposure
Procedure
- Inventory documented administrative interfaces.
- Determine which interfaces must be externally accessible.
- Verify authentication and authorization requirements.
- Review network-level restrictions where applicable.
Expected result
Administrative functionality is accessible only through authorized paths and appropriate security controls.
Review HTTP method configuration
Procedure
- Document the HTTP methods required by the application.
- Review web server and application configuration.
- Test the approved endpoints using the methods defined by the application design.
- Verify that unnecessary methods are rejected or appropriately controlled.
Expected result
HTTP methods are limited and configured according to application requirements.
Verify HTTP security headers
Procedure
- Establish the application's approved security-header baseline.
- Capture representative responses from public and authenticated endpoints.
- Compare observed headers with the baseline.
- Review missing, contradictory or unsafe configuration.
Expected result
Required security headers are present and configured consistently with the application's security requirements.
Review filesystem permissions
Procedure
- Identify sensitive application files and directories.
- Review owner, group and permission settings.
- Compare them against the deployment security baseline.
- Verify that the web process has only the access it requires.
Expected result
Files and directories follow least-privilege permissions appropriate to their function.
Verify cloud storage permissions
Procedure
- Inventory storage resources associated with the application.
- Document intended public and private access.
- Review access policies and permissions.
- Verify that private resources cannot be accessed without appropriate authorization.
Expected result
Cloud storage permissions match the intended access model and least-privilege requirements.
Review cross-domain configuration
Procedure
- Identify endpoints that support cross-origin requests.
- Document the approved origins.
- Review server-side cross-origin configuration.
- Test authorized and unauthorized origins in the approved environment.
Expected result
Cross-origin access is limited to explicitly approved origins and application requirements.
Review application path configuration
Procedure
- Identify filesystem paths used by the application.
- Determine which paths are intentionally exposed through the web server.
- Review aliases, mounts and application routing configuration.
- Verify that internal paths cannot be unintentionally reached through public application routes.
Expected result
Public routing exposes only intended application resources.
Review network exposure
Procedure
- Inventory services required by the application.
- Identify intended network exposure.
- Review firewall, security-group and network policy configuration.
- Verify that internal services are not unnecessarily exposed.
Expected result
Network exposure matches the documented architecture and least-privilege requirements.
Verify configuration consistency
Procedure
- Establish the approved configuration baseline.
- Compare development, staging and production security-relevant settings.
- Identify unexplained differences.
- Determine whether differences are intentional and documented.
- Correct unauthorized configuration drift.
Expected result
Security-relevant configuration differences are intentional, documented and approved.
Why does it happen?
Security misconfiguration commonly results from insecure defaults, incomplete hardening, configuration drift, inconsistent environments or insufficient review of infrastructure changes.
Common causes
- Development configuration deployed to production.
- Default accounts or credentials left enabled.
- Unnecessary features or services remaining active.
- Detailed error handling enabled in production.
- Security settings differing between environments.
- Manual configuration changes without change control.
- Excessive filesystem or cloud permissions.
- Missing configuration review during deployment.
A configuration can become insecure after deployment when individual settings are changed without maintaining the approved security baseline.
How to fix it
Remediation should establish a secure baseline and enforce it consistently across development, deployment and production environments.
Production debugging
// Development
$debug = true;
// Production
$debug = false;The exact implementation depends on the framework and deployment architecture. The security requirement is that production debugging functionality must not expose sensitive implementation details.
Disable unnecessary directory indexing
<Directory "/var/www/html/uploads">
Options -Indexes
</Directory>General remediation principles
- Establish documented secure configuration baselines.
- Remove unnecessary functionality and services.
- Disable development and debugging functionality in production.
- Remove or securely change default credentials.
- Restrict administrative interfaces.
- Apply least-privilege permissions.
- Protect sensitive files from public access.
- Review cloud resource permissions.
- Automate configuration validation where practical.
- Monitor and correct configuration drift.
How to verify the fix
Verification must repeat the relevant test after remediation. A configuration change or scanner result alone should not be considered proof that the issue has been resolved.
| Verification test | Expected result | Status |
|---|---|---|
| Debugging | Production debugging disabled | PASS |
| Error handling | No unnecessary sensitive details | PASS |
| Directory listing | Directory contents not exposed | PASS |
| Administrative access | Appropriate controls enforced | PASS |
| Sensitive files | Files not publicly accessible | PASS |
Assessment result
The tested configuration satisfied the defined security requirement.
The tested configuration did not satisfy the defined security requirement.
The required test condition could not be evaluated.
Not Tested must not be recorded as Pass. The assessment result should accurately reflect what was actually verified.
What should be recorded?
Evidence should demonstrate the original condition, the remediation performed and the result of the subsequent verification.
Standards and references
| Framework | Reference / relationship |
|---|---|
| OWASP Top 10 | A02:2025 — Security Misconfiguration |
| OWASP WSTG | Configuration and Deployment Management Testing |
| OWASP ASVS | Configuration, deployment and security control verification |
| CWE | Configuration-related weakness classifications |
The WebOTG-SM identifiers on this page are WebOTG-defined procedures. They should not be interpreted as OWASP test identifiers.