The Vulnerabilities Hackers Find Over and Over Again

If you read enough penetration test reports, a strange pattern emerges. Despite decades of security research and billions spent on defences, the same handful of weaknesses appear in report after report, year after year. They aren’t exotic. Most of them have been well understood since the early 2000s. They persist because software is written by busy humans under deadline pressure, and these mistakes are easy to make.

The OWASP Top 10, a regularly updated list from the Open Worldwide Application Security Project, is the most widely used catalogue of these recurring flaws in web applications. This article walks through the most important categories in plain language, with no code required. Understanding why each one happens is the foundation of both finding and preventing them.

1. Injection

The idea: An application takes input from a user and passes it, unfiltered, into a command that gets executed somewhere else, such as a database query. The attacker crafts input that changes the meaning of that command.

A real-world analogy: Imagine a hotel where guests write their room number on a slip of paper and hand it to a porter, who reads it aloud to the front desk. Now imagine a guest writes “Room 204, and also give me the master key.” If the porter reads it word for word and the desk clerk obeys, the system has been injected.

SQL injection is the most famous type. A login form asks for a username; the attacker types in something that makes the database’s query return “true” for any password. Despite being one of the oldest known web vulnerabilities, it still appears in major breaches every year.

Why it happens: Developers build commands by gluing strings together instead of using safe methods (called parameterised queries) that keep data and instructions separate.

2. Broken authentication and access control

The idea: The application either fails to properly verify who you are (authentication) or fails to enforce what you’re allowed to do once it knows (access control, or authorisation).

Examples you’d recognise: A site that lets you view your invoice at /invoice?id=1042, and when you change it to 1041, shows you someone else’s. A password reset link that never expires. An admin panel that’s “hidden” but not actually protected. Login forms with no limit on guesses, allowing an attacker to try thousands of passwords a minute.

OWASP currently ranks broken access control as the single most common serious web vulnerability. It’s also one of the hardest for automated tools to find, because a scanner doesn’t know which user is supposed to see which invoice. A human tester does.

Why it happens: Access checks have to be written correctly on every single page and API endpoint. Miss one, and that’s the hole.

3. Cross-site scripting (XSS)

The idea: An attacker gets a website to display their own script in another user’s browser. The victim’s browser trusts the website, so it runs the script with all the permissions the victim has on that site.

What it looks like: A comment section that displays whatever you type without cleaning it. An attacker posts a “comment” that’s actually a small script. Everyone who views the page runs that script, which might silently steal their session cookie, redirect them to a fake login page, or perform actions as them.

Why it happens: The application treats user-supplied text as trusted content and inserts it directly into the page instead of encoding it so the browser displays it as plain text.

4. Security misconfiguration

The idea: The software itself might be fine, but it’s been set up insecurely. This is less a single bug than a whole family of oversights.

Common examples: Default admin passwords left unchanged on routers, databases, or web frameworks. Detailed error messages that reveal internal file paths, software versions, or database structure. Directory listings enabled so anyone can browse a server’s files. Cloud storage buckets set to “public” that were meant to be private. Unnecessary services left running and exposed to the internet.

Why it happens: Modern systems have hundreds of settings, and the defaults are often chosen for convenience during development rather than safety in production. Nobody goes back to lock them down.

5. Vulnerable and outdated components

The idea: Almost no software is written from scratch. Applications are assembled from libraries, frameworks, and third-party components, each of which can have its own security flaws. When a flaw is publicly disclosed and the organisation doesn’t update, attackers have a ready-made way in.

Why it matters so much: Once a vulnerability in a popular library is published, attackers scan the entire internet for anything running the affected version. Several of the largest breaches in history came down to a single unpatched component that had a fix available for weeks or months.

Why it happens: Updating can break things, so teams postpone it. Many organisations also don’t have an accurate inventory of what they’re running in the first place.

6. Cryptographic failures

The idea: Sensitive data is not protected properly, either in transit (as it travels over the network) or at rest (when stored).

Examples: Passwords stored in plain text, or with weak, outdated hashing. Websites that still allow unencrypted connections. Credit card numbers stored without encryption. Custom-built encryption schemes that turn out to be trivially breakable because cryptography is extraordinarily hard to get right.

Why it happens: Cryptography is difficult to get right, and developers either skip it, roll their own, or use it in a way that undermines the protection.

7. Server-side request forgery (SSRF)

The idea: An application fetches a URL supplied by the user, and the attacker supplies a URL pointing at something the server can reach but the attacker shouldn’t be able to, such as internal systems behind the firewall or cloud metadata services.

Analogy: You ask a receptionist to fetch a document from “the archive room,” and they do so without checking whether you’re allowed in there. The receptionist has the keys; you’re just borrowing them.

Why it matters: SSRF has become more prominent with cloud infrastructure, where an internal request can sometimes hand over credentials for the entire cloud account.

8. The human factor: social engineering

The OWASP list focuses on software, but any honest discussion of common vulnerabilities has to include people. Phishing (fraudulent emails or messages designed to steal credentials or deliver malware) remains one of the most effective ways into an organisation. So does simply calling the help desk and pretending to be a locked-out employee.

Technology can reduce the risk with multi-factor authentication and email filtering, but a well-crafted pretext against an untrained person still works far too often. That’s why many penetration tests include a social engineering component, and why security awareness training exists.

Why these keep coming back

You might wonder how flaws this well-known can still be so common. A few reasons:

Software is constantly being written. Every new application, feature, and developer is another chance to reintroduce an old mistake.

Security is invisible when it works. A feature that ships gets praised; a vulnerability that was prevented is never noticed. Incentives push towards speed.

Complexity keeps growing. Modern applications depend on dozens of services, hundreds of libraries, and cloud configurations that few people fully understand.

The basics are boring. Patching, access reviews, and input validation are unglamorous. Organisations are more excited to buy a new security product than to do the tedious fundamentals.

What to take from this as a beginner

Two things. First, you don’t need to chase exotic zero-day exploits to be a valuable ethical hacker. The overwhelming majority of real-world findings are variations on the list above, and learning to find them thoroughly and explain them clearly is a career in itself.

Second, every one of these vulnerabilities has a well-understood fix. When you eventually write your first report, the recommendations section will lean heavily on the same handful of principles: validate and encode input, enforce access control on every request, keep software updated, use proven cryptography, configure things deliberately, and train people.

If you want to see these flaws for yourself, the free PortSwigger Web Security Academy has hands-on labs for nearly every category here, and OWASP Juice Shop lets you find them all in a single deliberately broken application. Break them in a lab, understand why they work, and you’ll be well on your way.

---

This series is written for educational purposes and to encourage legal, authorised security testing. Only ever test systems you own or have explicit written permission to test.