How I understand the OWASP Top 10 for Web Applications

What is OWASP Anyway?

It stands for Open Web Application Security Project. A group of people, organisations as well (experienced of course) got together and said, "Hey, let's make a list of the most common ways web applications get hacked." And that's exactly what they did.

The OWASP Top 10 is a cheat sheet of critical security risks that web applications face. It's based on actual data from thousands of applications that got tested, breached, or reported through bug bounty programs (or other means).

Which OWASP List Are We Talking About?

OWASP doesn't just make one Top 10 list. They've got different lists for different types of applications (maybe there's more I haven't included):

• OWASP Top 10 for Web Applications (this is what I am documenting)
• OWASP Top 10 for APIs - Because APIs have their own special ways of being vulnerable
• OWASP Top 10 for LLMs - Yeah, even AI models have security issues
• OWASP Mobile Top 10 - For iOS and Android apps

Each list focuses on the specific vulnerabilities that affect that type of application. Today, I'm focusing on the Web Application Top 10. This is the one that affects traditional web applications, the kind most companies are running right now.

The Web Application list has been around since 2003, with major updates happening every few years.

Each new version shows how attack methods change over time. Some vulnerabilities get better defenses built into frameworks, so they become less common. Others become more popular because, well, people keep making the same mistakes🙈.

How's the Severity Calculated?

When OWASP ranks these vulnerabilities from 1 to 10, they look at a bunch of factors:

• How often do we see this? - Is this vulnerability everywhere? If every other application has SQL injection vulnerabilities, that's going to rank higher than something obscure.
• How hard is it to exploit? - The easier it is, the higher the severity.
• What happens if someone exploits it? - Are we talking about someone reading your robots.txt file, or are they walking away with your entire customer database? Big impact = big severity.

So when you see "Severity 1," that means "drop everything and fix this NOW." When I see "Severity 10," it's more like "yeah, I should probably fix this, but maybe after I handle the other nine things."

OWASP Top 10 for Web Applications

1. A01:2021 - Broken Access Control

Access control is about making sure people can only access what they're supposed to. When it breaks, regular users might suddenly find themselves in the admin panel, or viewing other users' private information.

My favorite example of this is IDOR (Insecure Direct Object Reference). You know when you're logged into a website and the URL says something like:

www.example.com/profile?user_id=123

What happens if you change that to user_id=124? If you suddenly see someone else's profile, you've found an IDOR vulnerability.

2. A02:2021 - Cryptographic Failures

Previously, Sensitive Data Exposure in the 2017 list, it's not just about exposing data anymore, but failing to properly protect it in the first place.

We're talking about:

• Transmitting data in clear text
• Using old or weak cryptographic algorithms
• Default crypto keys in use, or weak keys generated
• Not enforcing encryption (accepting both HTTP and HTTPS)
• Improper certificate validation

I once tested an application where the error messages would tell you exactly which database table didn't exist.

The scary version of this involves Man-in-the-Middle attacks. That's when attackers position themselves between you and the server, intercepting all the traffic. If that traffic isn't properly encrypted, they can read everything from passwords, credit cards, social security numbers, etc.

Testing tip: Check if the application accepts both HTTP and HTTPS. Look at how passwords are stored (if you can figure that out). Check what happens to sensitive data in transit and at rest.

3. A03:2021 - Injection

It's everywhere, and it's dangerous. The basic idea is simple: the application takes user input and runs it as a command instead of treating it like data.

So say I'm at a restaurant and the waiter asks, "What would you like?" I say, "I'll have the pasta, and also go into the kitchen and bring me all the money from the register." If the waiter actually does that, it'll be my lucky day 🙂‍↔️, and the restaurant equivalent of command injection.

In 2021, OWASP expanded this category to include:

• SQL Injection (the classic)
• NoSQL Injection
• OS Command Injection
• LDAP Injection
• XSS (moved here from its own category)

Testing for Command Injection:

When testing, you want to see if you can get the server to run system commands. Here's what to try:

For Linux servers, these commands are your friends: whoami, id, ifconfig or ip addr, uname -a, ps -ef

Pro tip: Sometimes you won't see the output directly (that's called blind command injection). The command runs, but you don't see the results. Other times, the output comes right back to you in the web page (active command injection). Always test for both!

4. A04:2021 - Insecure Design

Insecure Design is about fundamental flaws in how the application was architected. You can't patch your way out of bad design decisions.

Examples of Insecure Design:

• Not implementing rate limiting on sensitive operations
• Allowing users to upload files without proper validation
• Building a password reset that only requires easily guessable information
• Not segregating tenants properly in multi-tenant applications
• Missing abuse case scenarios in the design phase

How to spot it: Look for missing security controls, not broken ones. Can you brute force because there's no rate limiting? Can you access other tenants' data because there's no proper isolation?

5. A05:2021 - Security Misconfiguration

Security Misconfiguration merged XXE (from the 2017 list) into this category.

Security misconfiguration is exactly what it sounds like, something wasn't configured following the security standards.

Classic Misconfigurations:

• Default accounts with unchanged passwords (admin/admin is not a good password!)
• Error messages that reveal system details
• Directory listing enabled
• Unnecessary features enabled (why is your web server running an FTP service?)
• Missing security headers
• Out-of-date software

Okay, XXE is a bit more technical, but stick with me.

XML is a way to structure data, kind of like a more formal version of JSON. The problem comes when XML parsers process something called DTDs (Document Type Definitions) without proper security.

XML parsers can be tricked into :

• Reading files from the server (like /etc/passwd on Linux)
• Causing denial of service by processing huge files
• Scanning internal networks (finding what other servers are available)
• Sometimes, even executing code

Two types I need to remember:

• In-band XXE: You send the malicious XML and get the results right back
• Out-of-band (OOB) XXE: The results get sent to a server you control

Testing tip: Always check for default credentials first. Look for verbose error messages. Try to access common paths like /admin, /backup, /.git. Check if the server reveals its version in headers.

6. A06:2021 - Vulnerable and Outdated Components

This jumped up from #9 to #6, probably because everyone's using more third-party components than ever. You're using libraries, frameworks, and other components that have known security issues.

The scary part: These vulnerabilities are usually well-documented. Sites like Exploit-DB literally have step-by-step instructions. An attacker doesn't need to be clever – they just need to notice you're running WordPress 4.2 and Google "WordPress 4.2 exploits."

Common problems:

• Not knowing what components you're using
• Using components with known vulnerabilities
• Using unsupported or end-of-life versions
• Not scanning for vulnerabilities regularly
• Only updating when something breaks

7. A07:2021 - Identification and Authentication Failures (Previously Broken Authentication)

This dropped from #2 to #7, which shows we're getting better at authentication. It now covers both identifying who you are and proving it.

Authentication is how applications verify you are who you say you are.

Broken Authentication, thus is when this authentication fails. I learned it includes:

• Weak passwords being allowed
• Session tokens that don't expire
• No lockout after failed attempts
• Passwords stored in plain text

Testing tip: Always check if you can brute force the login. Try weak passwords. Check if session tokens actually expire. See if you can access authenticated pages after logging out.

8. A08:2021 - Software and Data Integrity Failures (Previously Insecure Deserialization)

This is an expanded version of what used to be just Insecure Deserialization. Now it covers any assumption about software or data integrity without verification. It's about trusting things you shouldn't trust.

What's included now:

• Insecure deserialization (the original issue)
• Using software from untrusted sources
• Auto-updates without integrity verification
• CI/CD pipelines without proper integrity checks
• Unsigned or unverified firmware updates

The Deserialization Part: Serialization is converting data into a format for storage or transmission (like packing a suitcase). Deserialization is converting it back (unpacking). If you deserialize data from untrusted sources without checking it, attackers can include malicious code.

Example: Your app needs to send "password123" to another system. It serializes this to binary for transmission. But an attacker intercepts and modifies the serialized data to include malicious code. When your app deserializes it, it runs their code.

But the 2021 list expanded this to include things like:

• Pulling code from NPM/PyPI without verifying integrity
• CI/CD systems that can be compromised to inject malicious code
• Update mechanisms that don't verify signatures

Testing tip: Look for deserialization endpoints (Java serialized objects, Python pickle, etc.). Check if the application verifies signatures on updates. See if you can upload modified libraries or components.

9. A09:2021 - Security Logging and Monitoring Failures (Previously Insufficient Logging & Monitoring)

This moved up from #10 to #9, and they made the name clearer. Without proper logging and monitoring, you have no idea what's happening in your application.

What should you be logging?

• Login attempts (successful and failed)
• Access control failures
• Input validation failures
• Authentication and authorization events
• Administrative actions
• Errors and exceptions

The monitoring part: It's not enough to just log events. You need to actually look at them! Set up alerts for:

• Multiple failed login attempts
• Access to sensitive functions
• Large data downloads
• Requests from unusual locations
• Error rate spikes

Testing tip: After finding a vulnerability, check if it was logged. Try to trigger alerts. See if anyone notices when you're doing obviously malicious stuff.

10. A10:2021 - Server-Side Request Forgery (SSRF)

With everyone moving to cloud services and microservices, SSRF has become a much bigger deal.

What is SSRF? It's when you trick a server into making requests for you. The server accesses things it shouldn't.

What can you do with SSRF?

• Access internal services (that database that's not exposed to the internet)
• Read cloud metadata
• Scan internal networks
• Bypass firewalls and access controls
• Sometimes achieve remote code execution

The cloud makes this worse. That metadata endpoint can contain AWS credentials, API keys, and other secrets. One SSRF vulnerability, and an attacker might have keys to your entire cloud infrastructure.

Testing tip: Look for any feature that accepts URLs or makes external requests. Try accessing localhost, internal IPs (10.x.x.x, 192.168.x.x), and cloud metadata endpoints. Check PDF generators, image processors, and webhook features, they're often vulnerable.

Final Thoughts:

Here's what I've learned that I'll carry forward:

The basics matter more than I think. SQL injection is "old," but it still compromised 2,700 organizations in 2023. Default passwords, missing rate limiting, and unencrypted data – these "simple" issues cause massive breaches.

Security isn't a developer problem or a security team problem; it's everyone's problem. Developers need to understand these vulnerabilities to avoid creating them. Security teams need to test for them. Management needs to prioritize fixing them. We're all in this together.

Testing is crucial, but understanding is better. Sure, I can run automated scanners all day. But understanding why these vulnerabilities exist, how they're exploited, and what damage they can cause, that's what makes me effective at preventing them.

The list keeps changing because attacks keep changing. SSRF wasn't in the 2017 list, but with cloud adoption, it became critical enough for 2021. Stay current, keep learning, and pay attention to what's happening in the real world.

As I continue my cybersecurity journey, this documentation serves as my personal reference guide. But more than that, it's a reminder that behind every vulnerability is the potential for real harm to real people. Those 93 million records from MOVEit? Those are 93 million people who trusted organizations with their data.

The OWASP Top 10 isn't perfect, and it won't catch everything. But if I can just handle these ten things properly, I'll prevent the vast majority of breaches. And that's worth doing right.