Security misconfiguration
A safe system deployed with unsafe settings, such as debug mode, public storage, default passwords, open admin ports, or excess permissions.
See it
What it is
Security misconfiguration is exposure created by settings rather than the feature's core code: a public storage bucket, a default password, debug mode in production, an admin port open to the internet, verbose error pages, permissive CORS, or a container running as root. The software may work exactly as designed while the deployed combination is unsafe.
Look for it at every boundary between code and an environment: cloud resources, reverse proxies, containers, databases, CI, framework flags, and third-party dashboards. Configuration scanners such as Trivy catch known bad patterns, but the highest-value review is still a comparison between what the service needs and what the deployment actually exposes.
The common failure is fixing the live console and leaving the source of truth unchanged. The next Terraform apply or redeploy restores the bad setting. Make the correction in versioned configuration, add a test or policy that rejects it, and verify the deployed result. A green scanner also does not prove safety: custom authorization mistakes rarely look like a known configuration rule.
Ask AI for it
Audit this repository for security misconfiguration and apply the safe settings in the versioned source of truth. Run `trivy config .`, then inspect Dockerfiles, Docker Compose, Kubernetes, Terraform, Nginx, CORS, framework production flags, error handlers, storage access, and firewall rules. Remove default credentials and debug endpoints, run containers as a non-root `USER`, set Kubernetes `allowPrivilegeEscalation: false`, block public object storage, limit CORS to exact origins, hide stack traces from clients, and reject internet-wide access to database or admin ports. Add CI checks for the corrected settings and list anything that requires a manual console change.