Security Misconfiguration

Most vulnerabilities are a bug in the code. Misconfiguration is different: the code may be fine, but the system was set up in a way that leaves the door open. An admin console mounted without a login, a default password nobody changed, debug mode left on in production — none of these need a clever payload. The attacker just walks in.

What is the vulnerability?

Three of the most common forms:

• Exposed interfaces. An admin console, a monitoring dashboard or a /backup is served to anyone who knows the path. “Nobody links to it” is not protection.
• Default credentials. Software ships with a known account like admin / changeme, documented publicly, and the install step to change it is skipped.
• Verbose errors. Debug mode is left on in production, so an unexpected input returns a stack trace with file paths and environment variables — including secrets.

Why does it happen?

Defaults favour getting started quickly, not safety. Hardening — removing default accounts, locking down admin paths, turning off debug — is a separate, easily-skipped step, and a system that “works” in testing hides all three until someone looks.

How do you stop it?

Treat configuration as part of the attack surface. Require authentication and authorization on every admin path. Never ship a usable default password; force one to be set on first run and block known defaults. Disable debug output in production and return a generic error to the user while logging the detail internally. Review the deployed configuration, not just the code.

The three labs below are exactly these: an admin console with no auth, a login that still accepts the shipped default, and a tool whose debug error dumps the environment.