A security misconfiguration is when incorrect security settings are applied to devices, applications, or data in your infrastructure.
Wiz Experts Team
6 minutes read
A security misconfiguration is when incorrect security settings are applied to devices, applications, or data in your infrastructure. Misconfigured security settings usually introduce vulnerabilities or cause sensitive resources and actions to be exposed to unprivileged users.
Misconfigs can occur for many different reasons, including technical errors, missing programming constraints, use of default settings, and simple human error by administrators. For example, applying an incorrect IAM policy to an AWS S3 bucket is a security misconfiguration that could expose your files to an unintentionally broad audience.
In this article, we'll examine different types of security misconfigurations and share some best practices for preventing them.
The latest edition of OWASP's Top 10 report, a study that analyzes common categories of security problems, found that security misconfigs are currently the fifth most serious risk to web applications. Accordingly, they’ve gained the OWASP classification A5:2021 (the categories are labeled A1–A10 by severity).
This means misconfigurations pose a bigger threat than outdated dependencies, data integrity failures, and staple attack techniques such as SSRF. OWASP reported that 4% of tested applications were found to be misconfigured for security in some way.
Types of security misconfigurations
Security misconfigurations can occur for several different reasons. Yet no matter the reason, the end result is that inappropriate settings or inaction on the part of development teams causes a weakening of your security posture.
Here are the most common kinds of misconfigurations:
Accepting default settings
Default settings seem convenient, but they're frequently a security risk. Not changing the default credentials for your apps, services, and infrastructure can allow attackers to gain access using predictable values, for example. Applications frequently provision accounts using default credentials that are publicly available in their documentation or open source code; as a result, attackers will target deployments of these apps as there’s a chance the known credentials will still be in use.
Similarly, systems should be properly configured with production-ready encryption, signing, and certificate keys before they're deployed into your environments. That’s why it’s a good idea to implement a solution that can detect misconfigurations in popular application components such as databases and secrets stores.
Pro tip
Wiz data shows that about 20% of all organizations have at least one misconfigured application that can lead to either RCE or information disclosure.
Even software that's billed as production-ready out of the box can benefit from additional hardening steps that close loopholes and reduce your attack surface. Kubernetes, for example, has been the subject of multiple hardening guides, such as this one from the NSA and CISA, and has dedicated security management strategies that you should implement to get the best protection.
Noisy logs and error reports
During development, engineers often configure apps to write extra information into their logs and error reports. Though it assists debugging efforts, including this low-level technical info can pose a security threat if the logging level isn't reduced prior to deployment.
Web applications are particularly vulnerable because logs and stack traces can end up being displayed in a user's browser. This information could be helpful to attackers wanting to understand how your system functions; it may also directly expose sensitive information, such as when user details are included in the logs.
Use of outdated systems isn't always a misconfiguration in its own right—OWASP recognizes it as a separate problem. However, staying on older versions that are known to have security issues—like if you rely on legacy SSL/TLS protocols or cryptographic ciphers—is a kind of misconfig because you’re missing out on available protections. In the same vein, upgrading to newer software but then failing to enable newer security features is a misconfiguration that will affect your security posture.
Enabling unused features
The extent of your potential attack surface ultimately depends on the number of apps, services, and features you use. Keeping unused features enabled increases your risk without contributing any value to your organization.
Apps that include optional network capabilities are especially susceptible to this problem. For instance, Docker can be configured to expose a daemon socket that allows remote interactions with your installation. If you don't actually need remote access to your Docker host, this option is best left disabled so it can't possibly be abused by attackers. Using host-level tools to enforce OS-level configuration requirements is one way to prevent your attack surface from being widened by unused features that have been left enabled.
Access control issues
Granting a user account too many permissions, forgetting to secure a resource, and implementing insecure authentication systems (such as not using MFA requirements) all create a risk that bad actors could manipulate your data or infrastructure. To mitigate this risk, use a CSPM solution that can enforce consistent access control requirements.
Think that security misconfigurations are just theoretical issues that nobody actually encounters? Then it's time to think again. As the following section demonstrates, several recent incidents were caused by a relatively simple misconfiguration:
BingBang: Compromising internal Microsoft apps
BingBang is the name for a common misconfiguration Wiz found in Microsoft's Azure Active Directory identity management system. We discovered that around 25% of multi-tenant Azure applications were affected by the problem, including many first-party Microsoft apps. The apps had incorrect multi-tenancy settings applied that allowed logins using a Microsoft account belonging to another Azure tenant.
Hell's Keychain: Unauthorized access to IBM PostgreSQL databases
In December 2022, we demonstrated how a privilege escalation vulnerability in popular database engine PostgreSQL could be used to gain internal access to IBM Cloud resources—which could include databases owned by other IBM customers.
Unauthorized access was possible due to the presence of three improperly exposed secrets, in addition to overly permissive access to IBM's build servers. A SQL injection vulnerability allowed researchers to escape their database instance and move into the Kubernetes cluster that hosted it. From there, an exposed Kubernetes service account token facilitated further jumps into private areas.
ChaosDB: Unrestricted access to Azure databases
Back in 2021, we shared an attack that allowed access to other customers’ Azure accounts and data. A series of misconfigurations in Microsoft's Cosmos DB managed database service revealed secret keys which could be used to effect a string of privilege escalations. Those keys, granting full admin access, should never have been directly exposed to customers but were accessible for months or possibly years.
Best practices for preventing security misconfigurations
Now that we've seen how misconfigurations can occur and the real-world consequences they've had, let's explore the best ways to prevent them. The following steps are relatively simple measures that will allow you to take control of your environments and reduce the risk of misconfigurations:
Regularly update software and review hardening guides
Keeping software updated helps ensure you're not unintentionally using outdated, insecure, or deprecated features that keep you at risk. But as we've discussed above, this isn't enough to ensure maximum protection. You must also make conscious efforts to harden your environment, such as by disabling unused features and adhering to any vendor-provided security guides.
Practice secure coding methods
Developers must utilize secure coding methods to prevent misconfiguration issues that stem from your source. Hardcoded secrets (such as passwords and API keys), excessively verbose logs, missing encryption for sensitive data, and convoluted software supply chains are all issues that developers can take ownership of.
Code should also be subject to static and dynamic security tests that are configured as part of automated CI/CD pipelines, preventing detectable vulnerabilities from ever being deployed.
Enforce stringent authentication and authorization policies
Correct use of access controls is vital to keep your data and infrastructure protected. You should follow best practices such as the principle of least privilege to avoid the dangers of over-privileged accounts. Similarly, access tokens should be scoped to specific resources and assigned short, non-renewable expiration times that make it harder for attackers to gain persistent control of your systems.
Over 90% of cloud security teams were not aware they gave high permissions to 3rd party vendors.
Wiz Research Team's study of 1,300 AWS accounts
Implement a threat awareness program
Educating developers, users, and executives about the threats posed by misconfigurations—and how easily they can occur—is one of the best long-term initiatives you can pursue. Creating a threat awareness program will support individuals in understanding what they should do to protect themselves and your organization. When people know to question the default settings, they'll be much more likely to actually harden new applications they deploy.
Use a CSPM solution
Get comprehensive long-term protection by selecting a dedicated cloud security posture management (CSPM) tool. CSPM comprises tools and processes that give you visibility into your organization's security, including the ability to detect and resolve dangerous misconfigurations. CSPM platforms support your security stance by automatically scanning for vulnerabilities, enforcing your policies, and providing alerts when new threats are detected.
Security misconfigurations occur when inappropriate or incorrect settings are applied to software systems and their environments. We've covered several different types of these misconfigurations above, as well as best practices you can use to prevent them from appearing in your own infrastructure.
For the greatest security protection, use a CSPM platform that detects, alerts, and prevents misconfigurations in real time, based on policies and rules you define. Here at Wiz, we provide contextual CSPM for your entire cloud infrastructure. Want complete visibility and control over your cloud security? Get a demo today.
Take Control of Your Cloud Misconfigurations
See how Wiz reduces alert fatigue by contextualizing your misconfigurations to focus on risks that actually matter.
Application detection and response (ADR) is an approach to application security that centers on identifying and mitigating threats at the application layer.
Secure coding is the practice of developing software that is resistant to security vulnerabilities by applying security best practices, techniques, and tools early in development.
Secure SDLC (SSDLC) is a framework for enhancing software security by integrating security designs, tools, and processes across the entire development lifecycle.
DAST, or dynamic application security testing, is a testing approach that involves testing an application for different runtime vulnerabilities that come up only when the application is fully functional.
Defense in depth (DiD)—also known as layered defense—is a cybersecurity strategy that aims to safeguard data, networks, systems, and IT assets by using multiple layers of security controls.