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? →