---
{
  "title": "Security misconfiguration",
  "summary": "Maintain verified configuration baselines across environments, exposed interfaces, effective permissions, and deployment drift so fixes survive future releases.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Web Security Testing Guide",
      "url": "https://owasp.org/www-project-web-security-testing-guide/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

Misconfiguration includes excessive permissions, exposed management services, unsafe defaults, missing protections, and inconsistent deployment settings. Secure configuration needs a maintained baseline, automated or repeatable deployment, verification, and change control. Error output and debugging features can also expose information. Review both application and infrastructure layers, and do not assume a managed provider chooses the correct settings for every customer use.

## In practice

A production service accidentally exposes a debugging interface intended for local development. The team removes it and adds a deployment check.

## A common misunderstanding

Patching alone does not fix permissions or exposure that remain misconfigured.

## Check your understanding

What prevents a fix from disappearing on the next deployment?

**Think it through:** Update the authoritative configuration and tests rather than changing only a running instance manually.

## Compare intention with delivered behavior

Imagine a fictional academy enables a diagnostic interface for local development. The production deployment accidentally includes the same setting. The software may be fully patched while exposing information or operations never intended for public use.

Start with an inventory of services, environment settings, management paths, and effective permissions. The authoritative configuration should describe the intended baseline, while observations verify what is actually running.

## Defaults need contextual review

A product's default can be reasonable for one installation and unsuitable for another. Optional features, example accounts, public listeners, detailed error messages, and inherited permissions deserve a decision based on the workload.

Suppose a managed service supports strong controls but the customer selects broad access for convenience. The provider operating its platform correctly does not make that customer configuration appropriate. Review each responsibility at the correct layer.

## Fix the source of the setting

A manual correction on one instance can disappear when automation recreates it. Update the maintained deployment definition and include a meaningful verification step. Investigate other environments or replicas that inherited the same setting.

Drift can also occur after a reviewed deployment. Emergency changes need ownership and reconciliation so the repository and actual environment do not silently diverge.

For a safe exercise, draw development, staging, and production versions of one application. Mark a diagnostic setting that belongs only in development and define how each deployment's actual exposure is checked. Add an unauthorized broad permission and explain its correction at both the running resource and configuration source. The result should demonstrate repeatable maintenance and evidence, rather than a one-time screenshot claiming that a setting has been fixed forever.

## Keep exploring

- [[cloud-security-architecture]]
- [[change-control]]
- [[owasp-top-10]]