Blog - Is Your Code Secure? A 2021 OWASP Refresher

Programmers, developers, and architects like yourself have studied OWASP’s Top 10 throughout your career. But the roundup of the most common application vulnerabilities can be easy to lose sight of as you get settled into your normal work rhythm. Let’s not forget that cyber threats are constantly evolving—and the Top 10 frequently shift throughout the years.

It’s important to stay on top of the risks when designing and launching your source code, as well as the latest tips for fixing them and mitigating vulnerabilities. Since a few categories have changed between the 2017 update and now, we thought it was time for a refresher! 🆕 Some categories have taken dramatic leaps; Broken Access Control—as just one example—moved up from position one to five, with more than 318k occurrences of Common Weakness Enumerations (CWEs) in this risk category.

Let’s take a deep dive into the most common application vulnerabilities that made OWASP’s 2021 Top 10:

1. Broken Access Control

If your code isn’t airtight, unauthenticated, or unauthorized users can dig into sensitive files and systems, or even change user privilege settings. That’s why when developing your code, authentication and access restriction need to be properly implemented and tested. If a primary key can be changed to another user’s record, that user’s account can be viewed or modified. A huge danger to your security at large!

WHAT YOU CAN DO: This risk can be tricky since automated processes cannot always be tested without the aid of a professional penetration test. An ethical hacker can trial the success of unintended access controls, mimicking the attack vectors a cybercriminal could use without the true risk. Don’t underestimate the strength of tightly locked administrative accounts and leaning hard into multi-factor authentication methods for all permissions, across all users. 🔑

2. Cryptographic Failures

Previously referred to as “Sensitive Data Exposure” in the 2017 list, OWASP changed it to “Cryptographic Failures” because “Sensitive Data Exposure'' was a broad symptom rather than a root cause. The renewed name focuses on failures related to cryptography as it has been implicitly before. This category often leads to sensitive data exposure or system compromise.

If threat actors get their hands on sensitive data, it could mean big trouble for your company. Cybercriminals have a wealth of private information they can leverage for ransom from your brand or to sell on the dark web. When creating secure code, you want to include stronger features to protect sensitive and regulated data. APIs in particular often rely on insecure data transmission methods, which attackers can exploit to gain access to usernames, passwords, and other highly valuable info.

WHAT YOU CAN DO: Think of your sensitive data as your most treasured jewels. 💎 Barricade your strongest defenses with data encryption and tokenization. Remember that proper key management within your code is also crucial and that disabling response caching can drastically reduce the chance of it being accessed.

3. Injections

The most common application vulnerability of all is injection attacks. Injections happen when a malicious user inputs specially crafted text that interrupts the normal execution of a program, query, or OS command to steal and destroy data.

There are two common types of injection attacks: SQL and OS command. During a SQL injection, a user input changes the structure of a query, which changes how the database executes that query and what is returned by it. With an OS command, an attacker injects a command that runs on the operating system such as an LS script to list directory content or a Useradd script to create a new administrative user. 💉

WHAT YOU CAN DO: You want to make sure that user data never gets treated as a command that gets passed onto the operating system. A few high-level takeaways include always parameterizing your queries, decoupling user inputs from file system paths, sanitizing user input, and maintaining diligent code review—as we hope you already do!

4. Insecure Design

This category is brand new for 2021! OWASP worded it perfectly: “If we genuinely want to ‘move left’ as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation ... (if) needed security controls were never created to defend against specific attacks.” ⬅️

WHAT YOU CAN DO: In order to reduce the risk of an insecure application design, we need to diligently make security a priority within our initial design and application testing—not something we try to add or fix after launch. Don’t wait to find vulnerabilities during penetration tests; incorporate application scanning early and test the resiliency of the code from the start. Take a vow to always make radical changes to your source code before your web app is live and adopted.

5. Security Misconfiguration

According to OWASP, “90% of applications were tested for some form of misconfiguration, with an average incidence rate of 4.5%, and over 208k occurrences of CWEs mapped to this risk category. With more shifts into highly configurable software, it's not surprising to see this category move up.”

Previously, this category was called “XML External Entities (XXE),” and is now a part of this general bucket. Insecure code, integrations, or dependencies allow threat actors to upload or include malicious XML content to manipulate your code. If your application uses vulnerable component processing XMLs, it’s important to be on the lookout for configurations and dependencies that are vulnerable to uploads, commands, or content within an XML document.

WHAT YOU CAN DO: Static application security testing (SAST) is not a nice-to-have; it’s a must. This testing can help you detect XML in source code, inspecting third-party components with known vulnerabilities as well as application configuration and dependencies. 🔎 Let’s not forget the power of disabling XML external entity processing, which can go a long way in reducing the likelihood of XML entity attacks.

Don’t Forget the Rest!

Now that you’ve refreshed yourself on the new OWASP Top 5, take a breather.

We know it’s a lot to take in—with old categories evolving and moving up and down the list. 😅

But let’s not forget that there are five more web application risks to cover, including:

Vulnerable and Outdated Components
Identification & Authentication Failures
Software & Data Integrity Failures (NEW!)
Security Logging & Monitoring Failures
Server-Side Request Forgery (NEW!)

Head over to OWASP and familiarize yourself with the updated 2021 list!

Thanks again for all you do to keep code secure; you’re an important asset—that’s for sure!