6. Security misconfiguration
Manual, ad hoc, insecure, absence of security configurations enable unauthorized access.
What it is
Security misconfiguration is when vulnerabilities are left exposed during development, deployment, and support of an application (e.g., using default credentials, leaving files unprotected on public servers, having known but unpatched flaws, and more, and at any layer of the software stack).
How it works
Frameworks and IDEs become bigger and more complex. Engineering teams may start using them with default flaws. Once teams get into the daily routine, initial checklists and safeguards stop, things get missed, prioritization decisions are made, and vulnerabilities are left unaddressed. Luckily, most of these types of vulnerabilities are easy to find and fix.
Why it’s bad
It makes it easy for even novice attackers to find and access valuable systems and data.
Countermeasures
Development, QA, and production environments should all be configured identically, with different credentials used in each environment. The process should be automated to minimize the effort required to set up a new secure environment.
Secure by default. Remove or do not install unused features, frameworks, and libraries.
For multi-tenant applications, use segmentation where different tenants are separated via containerization, cloud security groups, physical databases, file system folders, etc.
Remediate all vulnerabilities reported by SAST and DAST tools.
Utilize HTTP security headers.
Security misconfiguration example
Engineering or DevOps teams misconfigure an application or container unknowingly expose them by allowing users access to a parent directory.
As seen here, using simple search and index shows a parent directory access.
