Slide 6 of 28
Part 1 · What Is It?Slide 6
Slide 6 · Why It Happens
Configuration is invisible until it breaks — or until an attacker finds it.
Five root causes that turn misconfiguration from a risk into a breach.
Insecure defaults ship and stay
Software defaults prioritize usability over security. Kubernetes dashboard: no auth by default. Firebase: open read/write by default. MongoDB: no auth on the local interface by default. Developers install, get it working, and move on — defaults never changed.
Development config leaks to production
Debug mode, verbose logging, permissive CORS, and test credentials are set for local development. The same configuration deploys to production because there’s no environment-specific override, no deployment check, and no one noticed.
Configuration is not reviewed like code
Every line of application code gets reviewed, tested, and version-controlled. CORS headers, TLS settings, and HTTP method permissions often live in server config, infrastructure files, or environment variables that don’t go through the same review process.
The “it’s internal” assumption
Admin panels, debug endpoints, and management interfaces are deployed without auth because “only internal teams use them.” Then the service gets a public IP, a misconfigured firewall rule, or an SSRF vulnerability — and the “internal-only” assumption collapses.
No ongoing configuration validation
Configuration is set once at deployment and never re-checked. Security requirements evolve, new endpoints are added, infrastructure changes — but no automated process re-validates that security configuration is still correct and complete.
← Back What’s at stake? →