It can occur in applications, frameworks, identities, cloud services, networks, hosts, containers, databases, devices, or management systems, and may expose data or functions, weaken another control, or create a condition that a threat can exploit.
Examples include unchanged default credentials, public storage, excessive permissions, enabled sample or debug features, verbose errors, missing security directives, exposed management interfaces, disabled logging, and inconsistent settings between environments. The correct configuration depends on architecture, purpose, data, threats, and operational constraints.
Key points
Establish intentDefine tested, version-specific baselines and policy for each environment, including required services, interfaces, permissions, logging, encryption, error handling, and approved exceptions.
Control changeUse accountable review, repeatable deployment, least-privilege administration, protected configuration stores, and separation between development, test, and production credentials.
Verify stateAssess effective settings and resource relationships, compare them with intended baselines, detect drift, prioritize by exposure and consequence, remediate safely, and confirm the correction persists.
Important limitationNot every vulnerability is a misconfiguration; correctly configured software can contain design or implementation weaknesses. A failed configuration check is also not proof of exploitability, while incomplete visibility or an unsuitable baseline can miss material risk.