WebOTG-SM-001 — Application Platform Configuration

01 / OBJECTIVE

Objective

What are we verifying?

Verify that security-relevant application platform configuration is explicitly defined, appropriately hardened and consistent with the approved security baseline for the target environment.

Application platforms include the runtime, framework, application server and other platform components on which the application operates.

The objective is not to determine whether a particular vendor or framework is inherently secure. The objective is to identify configuration conditions that create unnecessary security exposure.

02 / SCOPE

Scope

Include the following where applicable:

Application runtime configuration

Framework security configuration

Application server configuration

Production and development configuration differences

Security-related environment variables

Default or unnecessary platform functionality

Platform security logging and error configuration

03 / PREREQUISITES

Prerequisites

Before beginning the assessment, the tester should establish the following information.

Authorization	Confirm explicit authorization to assess the target environment.
Environment	Identify whether the target is development, staging, production or another environment.
Platform	Identify the relevant runtime, framework and application server.
Baseline	Obtain the approved configuration or security baseline where available.
Access	Obtain the minimum access required to perform the review.

04 / METHODOLOGY

Methodology

Use a combination of configuration review and controlled behavioral verification. Do not rely exclusively on automated scanners because a scanner cannot determine whether every configuration value is appropriate for the application's intended design.

Method	Purpose
Documentation review	Establish intended security configuration.
Configuration inspection	Identify insecure or unnecessary settings.
Runtime verification	Confirm the effective configuration.
Baseline comparison	Identify unexplained deviations.

05 / PROCEDURE

Test procedure

Authorized testing only

Perform this procedure only on systems for which you have explicit authorization. Prefer a controlled staging environment when production access is not necessary.

01

Identify the application platform Record the relevant application runtime, framework, application server and major platform components.

02

Establish the intended configuration Review approved security documentation, deployment standards and environment-specific configuration requirements.

03

Inspect security-relevant settings Review settings affecting debugging, errors, authentication integration, session handling, logging, exposed services and other security controls.

04

Identify unnecessary functionality Determine whether development tools, diagnostic interfaces, sample functionality or unnecessary services remain enabled.

05

Compare against the baseline Record each security-relevant deviation and determine whether it is intentional, documented and approved.

06

Verify effective behavior Where appropriate, confirm that the effective runtime behavior corresponds with the expected configuration.

Example configuration review

Example production configuration REVIEW

environment = production

debug = false

directory_indexing = false

detailed_errors = false

development_tools = disabled

default_accounts = disabled

unnecessary_services = disabled

The values above are illustrative. The actual secure configuration must be determined from the platform, application architecture and approved security requirements.

06 / EXPECTED RESULT

Expected result

Pass condition

Security-relevant platform configuration conforms to the approved baseline, unnecessary functionality is disabled or appropriately restricted, and the effective runtime behavior matches the intended configuration.

Minor differences that are intentional, documented and approved should not automatically be classified as security findings.

07 / FAILURE CRITERIA

Failure criteria

Consider the test failed when one or more of the following conditions are confirmed:

Security-relevant settings use insecure values without an approved justification.

Development or diagnostic functionality is unnecessarily enabled in production.

Default security configuration remains unchanged where hardening is required.

Configuration exposes unnecessary functionality or information.

Effective runtime behavior differs from the approved security configuration.

Do not classify undocumented differences automatically

A configuration difference is not necessarily a vulnerability. Establish whether the difference creates a security exposure and whether it is intentional and approved.

08 / REMEDIATION

Remediation

Correct the identified configuration according to the platform's supported security configuration mechanisms.

Recommended approach

Establish the required secure configuration.
Remove unnecessary functionality.
Disable development and diagnostic functionality in production.
Remove or securely change default configuration and accounts.
Apply least privilege to platform services.
Store environment-specific configuration securely.
Implement configuration validation during deployment.
Document approved exceptions.

Avoid configuration changes without a baseline

Changing settings individually without documenting the intended final state can create configuration drift and make future verification difficult.

09 / VERIFICATION

Verification

Repeat the original test after remediation. Verification should establish that the insecure condition no longer exists and that legitimate application functionality continues to operate.

Verification procedure

01

Reinspect the configuration Confirm that the corrected configuration matches the approved baseline.

02

Verify effective behavior Confirm that the runtime behavior now reflects the corrected configuration.

03

Confirm functionality Verify that required application functionality remains available and operates as intended.

PASS

The configuration and effective behavior satisfy the defined requirement.

FAIL

The security condition remains present after remediation.

NOT TESTED

The required evidence or test condition could not be evaluated.

10 / EVIDENCE

Evidence requirements

Evidence should be sufficient for another qualified reviewer to understand what was tested, what was observed and how the result was determined.

Target application and environment

Platform and relevant version information

Applicable configuration baseline

Original configuration or observed behavior

Remediation performed

Post-remediation configuration

Retest result

Verification date and tester

Evidence handling

Do not publish credentials, secrets, session tokens, private keys or other sensitive information as evidence. Redact sensitive values while retaining enough contextual information to demonstrate the result.

11 / CLASSIFICATION

Classification

WebOTG procedure	WebOTG-SM-001
OWASP category	A02:2025 — Security Misconfiguration
Procedure type	Configuration and deployment review
Assessment result	PASS / FAIL / NOT TESTED
Finding severity	Determine separately based on the confirmed impact and affected scope.

WebOTG classification notice

WebOTG-SM-001 is a WebOTG-defined verification procedure. The identifier is not an OWASP test identifier.

12 / REFERENCES

References

Source	Relevance
OWASP Top 10:2025 — A02	Primary category reference for Security Misconfiguration.
OWASP WSTG	Configuration and Deployment Management Testing methodology.
OWASP ASVS	Application security verification requirements.
CWE	Weakness classification reference.

WebOTG should maintain the source URLs and version information in its content-management system so references can be updated without modifying page templates.