Why is OWASP Top 10 So Important for AppSec Engineers?

What is OWASP?

The Open Web Application Security Project, or OWASP, is a non-profit organisation founded in 2001 by Mark Curphey. Over the years, they've dedicated themselves to improving the state of application security through research and numerous projects.

Anyone can become a member of OWASP by making a donation and take part in research and development, adding to their growing body of knowledge. All of their resources are free to access as part of their drive to make application security knowledge available to everyone.

Some of their most well-known projects include the OWASP Top 10, Juice Shop, Cheat Sheet series, ZAP, and WebGoat.

What is the OWASP Top 10?

The OWASP Top 10 is a list of the 10 most common and critical security vulnerabilities, ranked according to the severity of the threat they each pose. The list is based on a consensus of security experts from around the world, and is one of the most useful resources in a budding security professional's toolkit.

Why is the OWASP Top 10 such a big deal?

The OWASP Top 10 is perhaps the most ubiquitous and well-known security resources out there, and is recognised even outside application security circles. It's usually the first tool in a security engineer's toolkit, because it highlights the most common vulnerabilities in software.

Technology and development methods evolve at a rapid pace, and so must our methods to mitigate security risks. The annually updated list ensures both developers and security professionals are aware of the vulnerabilities they're most likely to encounter.

In addition, the OWASP Top 10 offers a way for security engineers to gauge the severity of a vulnerability — the higher up it is on the list, the more critical it is. This is the simplest benchmark to determine which vulnerabilities need to be remediated first.

The OWASP Top 10 rankings for 2021

1. Broken Access Control

According to OWASP, over 94% of applications tested suffer from some form of broken access control. When you think about it, it makes sense why it's at the top of this list. Nearly all apps we use today feature some kind of access control mechanism (like login credentials) to stop users from gaining privileges they shouldn't have. When these access control mechanisms fail, it can lead to the exposure of sensitive user data to malicious actors, and in some cases, gives them access to modify or destroy the data.

How to prevent Broken Access Control

For the full list of security measures, check the OWASP page linked above.

• Except for public resources, deny access to users by default.
• Implement access control mechanisms once and re-use them throughout the application, including minimising Cross-Origin Resource Sharing (CORS) usage.
• Log access control failures, alert admins when appropriate (e.g., repeated failures).
• Rate limit API and controller access to minimise the harm from automated attack tooling (brute forcing).

2. Cryptographic Failures

Cryptography is one of most common ways to secure sensitive data that needs to be transported or stored. In fact, cryptography as a technique has existed in many forms for thousands of years, often involving complex mechanical locks and ciphers. The modern kind we deal with today are used to protect secrets like passwords, credit card information, etc.

However, even encryption can fail when an old or weak cryptographic algorithms or keys are used, or when encryption keys themselves are not properly managed or stored.

How to prevent Cryptographic Failures

For the full list of security measures, check the OWASP page linked above.

• Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenisation or even truncation.
• Make sure to encrypt all sensitive data at rest.
• Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
• Always use authenticated encryption instead of just encryption.

3. Injection

Injection had been number one on the OWASP Top 10 for several years in a row, owing to how overwhelmingly common and easy it was to exploit. Injection—as the name suggests—happens when the attacker enters malicious code in a user input field. If this user input data isn't validated, filtered, or sanitised by the application, the hostile code could end up giving the attacker access to the database.

How to prevent Injection

For the full list of security measures, check the OWASP page linked above.

• The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterised interface, or migrates to Object Relational Mapping Tools (ORMs).
• Use positive server-side input validation. This is not a complete defence as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

Want some beginner-friendly courses in AppSec? Check out our Application Security Essentials courses.

4. Insecure Design

This is a new category for 2021 concerned with security issues that appear in the very design and architecture of your applications. It helps to recognise that there's a difference between insecure design and insecure implementation. The former is a flaw in the very foundation of the app, while the latter is a result of insecure coding practices.

A secure design, when properly implemented, will result in a more secure application. However, an insecure design cannot be 'saved' by good implementation, because the very blueprint of the app has a flaw in it. That's why it's so vital for us to go even beyond 'shifting security left' and implement security right at the planning and design phases.

How to prevent Insecure Design

For the full list of security measures, check the OWASP page linked above.

• Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls.
• Use threat modeling for critical authentication, access control, business logic, and key flows.
• Limit resource consumption by user or service.
• Integrate security language and controls into user stories.

5. Security Misconfiguration

Security misconfiguration, just like insecure design, is an umbrella term referring to a number of exploits and security flaws. Most applications you build will have a whole host of buttons and levers to push—configurations, in this case—and sometimes, one of those elements could be improperly configured.

This can be anything from enabling unnecessary features, to leaving unsecure default settings unchanged, to not properly setting the security settings in the application servers or frameworks.

How to prevent Security Misconfiguration

For the full list of security measures, check the OWASP page linked above.

• A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
• Review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process
• A segmented application architecture provides effective and secure separation between components or tenants, with segmentation, containerisation, or cloud security groups (ACLs).
• Sending security directives to clients, e.g., Security Headers.

6. Vulnerable and Outdated Components

While this one might seem obvious, it's more common than you might think. A lot of networks and systems run on legacy software and hardware that haven't been updated in years for fear of breaking something.

But the longer this goes on, the easier it becomes for attackers to exploit old, outdated systems like the OS, web/application server, APIs, etc. Neglecting to scan and update your systems is a risk that can far outweigh any costs you'll save by leaving it as is.

How to prevent Vulnerable and Outdated Components

For the full list of security measures, check the OWASP page linked above.

• Remove unused dependencies, unnecessary features, components, files, and documentation.
• Continuously inventory the versions of both client-side and server-side components (e.g., frameworks, libraries).
• Only obtain components from official sources over secure links.
• Monitor for libraries and components that are unmaintained or do not create security patches for older versions.

7. Identification and Authentication Failures

As with broken access control, this vulnerability can allow an attacker to impersonate a legitimate user to steal, modify, or destroy valuable data. Attackers most commonly use automated credential stuffing and brute force attacks to get through.

Websites often neglect basic measures like not allowing weak passwords like 'admin' or 'password', or exposing the session identifier in the URL. Many of the common security issues centred around authentication failures tend to be simple and easily avoidable with some careful attention to detail.

How to prevent Identification and Authentication Failures

For the full list of security measures, check the OWASP page linked above.

• Where possible, implement multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks.
• Do not ship or deploy with any default credentials, particularly for admin users.
• Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list.
• Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session identifier should not be in the URL, be securely stored, and invalidated after logout, idle, and absolute timeouts.

8. Software and Data Integrity Failures

Nearly all software developed today is a combination of existing libraries, APIs, plugins, and modules, many of which are open source. While this is convenient for development and can vastly speed up build times, it also introduces a risk factor in the form of software components outside of the developers' control.

An insecure CI/CD pipeline can open up your applications to unauthorised access, malicious code, and system compromise.

How to prevent Software and Data Integrity Failures

For the full list of security measures, check the OWASP page linked above.

• Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.
• Ensure libraries and dependencies, such as npm or Maven, are consuming trusted repositories.
• Ensure that a software supply chain security tool, such as OWASP Dependency Check or OWASP CycloneDX, is used to verify that components do not contain known vulnerabilities.
• Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline.

9. Security Logging and Monitoring Failures

Much like how we use surveillance systems to monitor physical locations, applications need to be constantly scanned and checked for security. But unlike a physical location, an attacker can access and steal data from your system without you ever finding out.

If you never monitored your software, there would be no way to know if a breach even happened in the first place. Security logging and monitoring are constant, ongoing activities to detect security breaches, and if possible, fix them before they cause serious damage.

How to prevent Security Logging and Monitoring Failures

For the full list of security measures, check the OWASP page linked above.

• Ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.
• Ensure that logs are generated in a format that log management solutions can easily consume.
• Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.
• DevSecOps teams should establish effective monitoring and alerting such that suspicious activities are detected and responded to quickly.

10. Server-Side Request Forgery (SSRF)

An SSRF attack happens when a web application makes a request for a remote resource without validating URL supplied by the user. The attacker induces the app to make requests to a domain of their choosing, thereby putting the application at serious risk.

A successful SSRF attack can allow the malicious actor to access data within the organisation, and in certain cases, even execute commands.

How to prevent Server-Side Request Forgery

For the full list of security measures, check the OWASP page linked above.

• Sanitize and validate all client-supplied input data.
• Enforce the URL schema, port, and destination with a positive allow list.
• Do not send raw responses to clients.
• Disable HTTP redirections.

Our favourite OWASP projects for non-security roles

OWASP isn't just useful for application security engineers! They've got all kinds of security-related projects that span nearly every discipline in product development. If you're in any way involved in building software, there's an OWASP project relevant to you.

Here's a few of our favourite projects for people not specialising in security.

For Beginners: OWASP WebGoat

Besides the OWASP Top 10, we think WebGoat is one of the most useful projects for beginners. WebGoat is an application made deliberately insecure so you can try out various methods of exploiting it.

Remember all those vulnerabilities in the OWASP Top 10? You can learn how to use each of them to exploit WebGoat, giving you a more practical view of how these security flaws work in the real world.

They even have lessons for the Top 10 vulnerabilities, so it's the best place to start your AppSec journey for free.

For Developers: OWASP Security Knowledge Framework (SKF)

Given how dizzyingly many programming languages and components developers work with, it becomes rather difficult to not just build an app, but build it securely. That's where the Security Knowledge Framework (SKF) comes in.

OWASP SKF is an open source web application that teaches secure coding practices in multiple programming languages. If you're a developer building apps, you owe it to yourself to learn the best practices for how to code securely.

The framework is extremely detailed, featuring code examples, lab exercises, and a knowledge base. It even lets you manage users, so you can use it to train your whole team in secure coding.

For Team Leaders: OWASP Software Assurance Maturity Model (SAMM)

The OWASP SAMM project is aimed at helping organisations analyse and improve their security posture. It's a model the organisation can use to assess itself and identify areas where they could do better security-wise.

SAMM is meant to integrate into the software development lifecycle (SDLC) while remaining agnostic to technology or process. It's a great way to raise awareness on how to implement security right from the design phase, all the way to deployment.

Organisations small or large can customise and adapt the model to suit their needs, making it incredibly flexible. It's a step-by-step process to help you achieve security maturity at every step of the SDLC.