Top 5 application security misconfigurations

As part of Cybersecurity Awareness Month, CISA has published a list of the top 10 network security misconfigurations found during red and blue team assessments and in actual incident responses. To make sure application security doesn’t get left out, we’ve decided to follow up with our own list of common application security misconfigurations – but since top 10 lists have received some bad press for being little more than clickbait, we’ll stick to just five of the most important categories.

In broad terms, an application security misconfiguration is any security flaw directly caused by the way an application or its environment is set up, not by any vulnerability in the application itself. For example, if an application is not vulnerable in a development environment but becomes vulnerable once deployed to production, you most likely have a security misconfiguration on your hands. With that definition in place and keeping in mind there is plenty of overlap between the categories, let’s dive into the top 5 application security misconfigurations.

Misconfiguration #1: Vulnerable tech stack components

Any web application is merely the outermost layer of a technology stack that goes right down to the operating system. Depending on its vintage and architecture, a web tech stack may include a web server, application server, database server, web framework, dynamic dependencies, and more. Unless all the runtime components are properly maintained, a missing patch or security update may provide attackers with an opening to exploit a known vulnerable product version and potentially compromise your system without touching the application itself (for instance, via remote code execution by the application server).

Read more about the dangers of outdated web technologies

Misconfiguration #2: Missing or insufficient access controls

Many data breaches happen not because an attacker broke in but because they found something out in the open – exposed cloud storage buckets, sensitive files, and forgotten APIs are all fair game. While ensuring proper access control at multiple levels is a major requirement for secure application development, it must also be a part of deployment and operations, especially as application components become more and more distributed. For example, a misconfigured web server may allow attackers to download the application source code, revealing intellectual property and making it easier to find vulnerabilities by directly analyzing the code.

Read more about the dangers of unauthenticated APIs

Misconfiguration #3: Default or development configurations

Development environments have very different requirements compared to production. Getting as much error information as possible is crucial, and security measures will often be disabled for debugging (or they simply won’t exist yet). With this in mind, many components default to less secure but more verbose settings intended to ease development, and locking them down should be a routine part of the deployment process. Unless properly hardened to minimize the attack surface and data exposure, components may leak excessive information to attackers or expose resources or user accounts that shouldn’t be accessible at all.

Read more about web application hardening

Misconfiguration #4: Missing or incorrect HTTP security headers

We’ve written a lot about HTTP security headers in the past, and with good reason, as they are one of the easiest ways to stop entire classes of web attacks without touching a single line of application code. Among several common headers, the two definite must-haves are Content Security Policy (CSP) headers to minimize exposure to cross-site scripting and the HTTP Strict Transport Security (HSTS) header to enforce encrypted communications and thus prevent man-in-the-middle attacks. While setting them is a fundamental best practice, misconfiguring your security headers can be a risk in itself – from a false sense of security when your CSP rules don’t do what you expected, to making your entire domain inaccessible due to a bad HSTS header.

Read our technical white paper about HTTP security headers

Misconfiguration #5: Excessive process privileges

Privilege escalation is usually the first goal of any attacker who manages to gain an initial foothold on your server. In order to minimize the options available to malicious actors, application hardening should include making sure that all the processes in your stack are running with the minimum necessary privileges and (if possible and appropriate) are separated to reduce the risk of lateral movement. For example, for development on a local machine, it might be quick and easy to run all your servers as root with full file system access – but if done in a production environment, it would allow total system compromise from a single successful command injection.

Read more about privilege escalation

Raising awareness of application security fundamentals

Preventing application security misconfigurations might not get the same attention as chasing down the latest media-friendly vulnerabilities, yet it is a fundamental part of secure development and operations. If you want to run secure software, you must start with an application that leaves development without known vulnerabilities and then put it in a hardened and tested runtime environment. Having only one or the other won’t work – you need to have both and test both.

Read more about the scope of different approaches to application security testing