7 Common App Security Misconfigurations

Feb 7, 2024

Everyone makes mistakes at work. That’s human nature. People get distracted and forget things. Most of the time, it’s no big deal. For one Pentagon staffer, however, a simple oversight led to a data leak that exposed U.S. military emails to the entire internet. This app security misconfiguration left a Department of Defense server without password protection. Anyone who knew the server’s IP address could access the sensitive but not classified data, which included emails about military special operations. 

To be fair to the developer, their mistake was only one in a series of oversights that led to the two-week data leak in February of this year. And, probably much to their relief, it was not even the worst breach of Pentagon emails this year. Russian hackers later exploited the MOVEit vulnerability to access the emails of multiple high-level employees at the Defense Department. 

App security misconfigurations are to blame for many other expensive data breaches, including the 2022 Microsoft BlueBleed data leak that exposed the data of over 150,000 companies spanning 123 countries. According to OWASP, 90% of applications they tested included some form of security misconfiguration. CISA reports this is a significant issue across all industries, even among organizations with a mature security posture. 

📌 7 Most Common Application Security Misconfigurations 

An application security misconfiguration is a vulnerability caused by how developers set up an app or environment. It is not a flaw inherent to the application itself. Some of the most common types of app security misconfigurations include the following. 

1. Default Configurations 

With so many applications touting out-of-the-box functionality, it should be no surprise that one significant configuration risk is the failure to change the default settings. This mistake is one explanation for the fact that the most common password — even in 2023 — is still 123456. 

Development environments, particularly before deployment, often have weak security configurations to facilitate fast iteration or broad debugging. To prevent leaking, settings should be tightened up before deployment as part of late-stage app hardening. 

2. Poor Access Control

The only thing worse than having an insecure password is having no password. As the Pentagon and Microsoft data leaks illustrate, this is a fairly common misconfiguration. Poor access control includes any weak or missing credentials that could allow unauthorized access to the system or application. DevSecOps teams should incorporate strong privilege access management protocols — ideally zero trust — throughout the development pipeline. With so many system components now cloud-based, perimeter security is no longer sufficient. 

3. Unpatched Components 

Almost all software applications contain open-source code, which means their weaknesses and vulnerabilities are often public knowledge. Nearly 60% of data breaches in the past two years could have been avoided by patching known vulnerabilities. Once an open-source vulnerability is discovered, hackers can easily exploit them. It’s not uncommon for attacks to occur months or years after a patch has been released. This should be a no-brainer for development teams, but tracking all open-source components in large codebases can be difficult, particularly if they’re hidden in dependencies. DevSecOps teams can use an automated software composition analysis (SCA) tool to scan their codebase for all incidents of open-source code so that it can be updated and patched appropriately. 

4. Oversharing During Error Handling 

Developers naturally want as much information as possible when they get an error to be able to fix it quickly. However, displaying too much error data to users can reveal potentially exploitable flaws to malicious actors. 

Even error messages that don’t seem to reveal information on their own may do so when combined with other error messages. For example, If a user searches for a file and receives the error message, ‘File not found,” and then later searches for a different file and receives, “Access denied,” they can logically conclude that the second file exists on the server. DevOps teams should create standards for error handling that return useful but generic messages to the user while transmitting diagnostic information to engineers. 

5. Weak or Missing Security Headers

HTTP security headers can protect against cross-site scripting (XSS) and clickjacking attacks. Setting up secure headers on web applications is one of the simplest ways developers can harden applications. Although there are multiple security headers engineers can implement, the following are the most important for unilaterally blocking entire classes of attacks: 

  • HTTP Strict Transport Security Header (HSTS) to force the use of encrypted connections
  • Content Secure Policy (CSP) for granular control over content parameters
  • X Frame Options to prevent pages from being loaded into iframes 

6. Unnecessary Features 

In a more-is-better, feature-creep environment, disabling features can seem downright wasteful. However, leaving unused ports, services, accounts, privileges, or pages active provides the opportunity to inject malicious code into an application. If features are not being used, there is no point in enabling them. In addition to increasing the attack surface, they waste resources. 

7. Lack of Network Segmentation 

Although an unsegmented network is not in and of itself an exploitable flaw, having a monolithic network allows easy privilege escalation when a hacker gains access. DevOps teams can implement strong security controls over a segmented network. Subnetworks can be secured based on the type of data and applications they contain. With limited connections between networks, a hacker who gains access to one network through a security flaw will not have the keys to the kingdom. 

Best Practices for Avoiding App Security Misconfigurations 

Securing applications is a multilayered process that teams must incorporate into the development process from the earliest stages. It is significantly more difficult — if not impossible — to adequately address security at the end of the software development lifecycle (SDLC). As part of a comprehensive DevSecOps approach to development, teams should implement standard protocols to prevent security misconfigurations, including automated processes to detect and mitigate vulnerabilities during the development phase. 

Static application security testing (SAST) tools can detect common app security misconfigurations so they can be fixed before deployment. SCA tools can find open-source code so organizations can install patches and updates as soon as these fixes become available. 

🚀 Improve Your Security Strategy With Kiuwan

Kiuwan produces a comprehensive suite of powerful security automation tools that empower developers at all phases of the SDLC. Our end-to-end application security platform aligns with industry-standard security frameworks and works with all major programming languages. Contact us today for a free trial, or click the link below to request a demo.

Get Your FREE Demo of Kiuwan Application Security Today!

Identify and remediate vulnerabilities with fast and efficient scanning and reporting. We are compliant with all security standards and offer tailored packages to mitigate your cyber risk within the SDLC.

Related Posts