Objective
Verify that the application, web server, framework, platform and deployment environment expose only the configuration, functionality and information required for their intended operation.
Security misconfiguration occurs when security-relevant settings are missing, incorrectly applied, unnecessarily enabled or inconsistent across environments.
The assessment must consider configuration as a complete security control rather than focusing only on visible HTTP responses. A secure application can still be exposed by an unsafe server setting, verbose error configuration, unnecessary service or insecure deployment default.
Scope
Review security-relevant configuration across the complete application delivery stack.
Server modules, directory access, methods, default files, version disclosure and TLS settings.
Debug mode, framework settings, error handling, session configuration and security defaults.
Operating-system services, permissions, exposed ports, packages and runtime configuration.
Storage exposure, network controls, identity configuration and externally accessible services.
Stack traces, internal paths, database errors, framework diagnostics and verbose responses.
Browser security controls and response headers appropriate to the application's architecture.
Prerequisites
| Authorization | Confirm authorization to perform configuration and security testing. |
|---|---|
| Architecture | Obtain an application architecture or deployment diagram where available. |
| Technology inventory | Identify operating system, web server, application framework, runtime, database, reverse proxy and hosting platform. |
| Configuration access | Where authorized, obtain read-only access to relevant configuration files and administrative settings. |
| Environment information | Distinguish production, staging, development and test configuration. |
Methodology
Security configuration should be evaluated using both external observation and authorized configuration review. External testing identifies what is actually exposed; configuration review identifies why it is exposed.
| Review stage | Primary question |
|---|---|
| Discovery | What technologies, services and interfaces are exposed? |
| Baseline | What configuration is required for normal business operation? |
| Hardening | Which unnecessary features, services or permissions remain enabled? |
| Exposure | Does configuration disclose information or expose functionality unnecessarily? |
| Verification | Does the hardened configuration remain functional and secure? |
Test procedure
Attack surface review
Identify unnecessary exposure before attempting deeper exploitation.
HTTP security header review
Review response headers according to the application's actual browser-facing security requirements. Do not add headers blindly; each control must be compatible with the application's architecture.
| Control | Review focus |
|---|---|
| Content-Security-Policy | Determine whether an appropriate CSP is implemented and whether it meaningfully reduces browser-side attack surface. |
| Strict-Transport-Security | Verify HTTPS enforcement where applicable and appropriate. |
| X-Content-Type-Options | Verify MIME-type sniffing protection where applicable. |
| Referrer-Policy | Verify that referrer information is appropriately restricted. |
| Permissions-Policy | Restrict browser capabilities that the application does not require. |
Error handling and information disclosure
Trigger controlled application errors and determine whether responses reveal implementation details that should remain internal.
Production systems should hide sensitive diagnostic information from external users, but security teams still require sufficient internal logging to investigate failures and security events.
Web server and platform configuration
Verify that only intended directories and resources are accessible through the web server.
Remove sample applications, default pages, test files and unnecessary documentation.
Disable methods that the application does not require.
Minimize unnecessary disclosure of server, framework and runtime information.
Verify that application files, configuration files and secrets have appropriate permissions.
Disable services and network listeners that are not required for the application.
Application and framework configuration
Deployment configuration
Configuration drift is a common source of security misconfiguration. The secure state must therefore be reproducible rather than manually maintained on individual servers.
| Area | Verification requirement |
|---|---|
| Environment parity | Security-relevant configuration should be consistently applied across deployment environments. |
| Configuration management | Security configuration should be version-controlled or otherwise reproducibly managed. |
| Secrets | Secrets should not be embedded in source code or publicly accessible configuration. |
| Unused components | Development packages, sample files, diagnostic endpoints and unused services should not be deployed unnecessarily. |
| Change control | Security configuration changes should be reviewed, tested and traceable. |
Controlled reproduction
Example: verbose error response
GET /application/resource?value=<invalid-test-value> HTTP/1.1
Host: application.exampleRecord the response and determine whether it exposes stack traces, internal paths, framework diagnostics, database details, source locations or other information that should not be disclosed to an untrusted requester.
Configuration evidence
environment = production
debug = false
verbose_errors = falseThe exact configuration syntax is technology-specific. The important requirement is that production behavior is explicitly hardened and independently verifiable.
Assessment
| Result | Interpretation |
|---|---|
| Secure | Required functionality is available while unnecessary security exposure is disabled. |
| Misconfigured | A security-relevant configuration deviates from the required secure baseline. |
| Exposed | The misconfiguration produces an observable security exposure. |
| Exploitable | The exposure can be used to obtain an unauthorized security-impacting result. |
Failure criteria
The production application exposes framework diagnostic information when an invalid request is processed. The response contains implementation details that are unnecessary for the requesting user and may assist further attack activity. Production error handling is therefore not configured according to the required security baseline.
Remediation
- Establish a documented secure configuration baseline for each supported technology.
- Remove unnecessary frameworks, modules, plugins, services and sample resources.
- Disable production debugging and verbose error output.
- Remove or disable default accounts and credentials.
- Restrict administrative and management interfaces using appropriate network and authentication controls.
- Disable directory browsing and unintended file access.
- Minimize unnecessary server and framework version disclosure.
- Store secrets outside source code and publicly accessible configuration files.
- Apply least privilege to operating-system processes, service accounts and application files.
- Manage security configuration through repeatable deployment processes rather than manual server changes.
- Continuously review configuration drift and newly introduced services.
Manually fixing one production server is not a complete remediation if the same insecure configuration can return during the next deployment. The secure baseline should be encoded into the organization's deployment and configuration-management process.
Post-remediation verification
The identified misconfiguration is removed and required functionality remains operational.
The original exposure or an equivalent insecure configuration remains present.
The configuration or resulting exposure could not be adequately verified.
Evidence requirements
Do not publish passwords, API keys, private keys, session tokens, internal hostnames or other secrets in assessment evidence. Retain only the minimum information required to demonstrate the finding.
Classification
| WebOTG procedure | WebOTG-A05-003 |
|---|---|
| OWASP category | A02:2025 — Security Misconfiguration |
| Procedure type | Application, server, platform and deployment configuration assessment |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine according to exposure, affected privileges, information disclosed, exploitability and business impact. |
WebOTG-A05-003 is a WebOTG-defined procedure identifier. It is not an OWASP-defined test identifier. The OWASP category reference should be maintained separately from the WebOTG procedure taxonomy.
References
| Source | Relevance |
|---|---|
| OWASP Top 10 | Security Misconfiguration category and associated application-security guidance. |
| OWASP Web Security Testing Guide | Web application testing methodology and configuration-testing guidance. |
| OWASP Secure Headers Project | Reference material for browser-facing HTTP security headers. |
| Vendor hardening documentation | Technology-specific secure configuration requirements. |
| CWE | Common weakness classifications related to insecure configuration and exposure. |
WebOTG should maintain source versions, publication dates, review dates and authoritative references through its content-management system. Procedures should be reviewed whenever the referenced security framework or underlying technology changes.