Security Misconfiguration: The Settings That Shape Application Security

Security Misconfiguration moves from number five in the OWASP Top 10:2021 to number two in the 2025 edition.

As I worked through the material, this category connected application security to a wide range of settings: web servers, frameworks, databases, cloud services, and deployment environments.

An application depends on all of those layers behaving as intended. Configuration choices can expose information or functionality even when the application's main features appear to work correctly.

What can be misconfigured?

The examples in OWASP's guidance include unnecessary features, unchanged default accounts, overly detailed error messages, insecure permissions, and missing or ineffective security settings.

Consider a hypothetical application deployed with a sample administration tool still enabled. If that tool is reachable and retains a default account, it creates an additional route into the environment.

Or consider an application that returns a full stack trace whenever a request fails. That response may reveal internal paths, component details, or other information that an ordinary user does not need.

Cloud storage permissions are another example. A private application feature can still expose data if the underlying storage is configured for public access.

A successful deployment leaves questions to check

“Does the application work?” and “Is the environment configured appropriately?” need separate attention.

A deployment can serve pages successfully while also exposing a management interface, leaving unused services enabled, or returning sensitive debugging information.

The same applies after an upgrade. New settings may be introduced, old behavior may change, or security features may remain disabled for compatibility. Reviewing configuration needs to be part of maintaining the system.

Making secure configuration repeatable

The prevention guidance emphasizes a repeatable hardening process. A documented baseline makes it easier to understand what should be present in an environment and what should be disabled or restricted.

Automation can help create environments consistently and check whether their settings still match the intended baseline. A check is more useful when it evaluates the actual deployed state rather than assuming that a configuration file was applied successfully.

Development, testing, and production should follow consistent security principles, with deliberate differences where needed. Credentials and sensitive data should remain separated, and production should not inherit unnecessary debugging or testing features.

A manageable set of review questions

For my notes, I grouped the topic into five areas:

What is exposed? Review public endpoints, storage permissions, administrative interfaces, and network access.
What is unnecessary? Remove sample applications, unused services, default accounts, and features that are not needed.
What information reaches the user? Keep useful diagnostic detail in protected logs while returning appropriate error responses.
How are credentials handled? Prefer the platform's supported identity and short-lived credential mechanisms where appropriate, rather than embedding long-lived secrets in code or configuration.
How are changes checked? Review relevant security settings during deployment, upgrades, and ongoing maintenance.

Security headers are part of this picture too. They need to match the application and be checked for their intended effect. Adding headers without understanding or validating the settings can leave gaps.

Why this belongs in application security

The source code is one part of the deployed application. Configuration determines which features are enabled, how services communicate, what is reachable, and what information is exposed when a request fails.

My main takeaway is that secure configuration needs an owner and a way to stay consistent over time. A one-time setup gives limited assurance if later changes are not reviewed.

The next category, Software Supply Chain Failures, extends the reading to the tools and components involved in building and delivering the application.

Sources and further reading