OWASP Top 10: The Most Common Web Security Vulnerabilities and How to Prevent Them

What is the OWASP Top 10 and which risks does it cover?

The OWASP Top 10 is a free, open awareness document that ranks the ten most critical security risk categories for web applications. The nonprofit OWASP Foundation builds it from real testing data and a community survey. In other words, it is a prioritisation guide, not a formal standard.

I have worked on corporate websites and e-commerce projects since 2012. In that time, almost none of the hacked sites I saw fell to an exotic attack. Usually a permission check was missing, a plugin was out of date, or an admin panel still used a default password. That is why I use the OWASP Top 10 as a review framework on every project.

This guide walks through the ten categories of the current list, one by one. For each, I explain what it means, how it looks in real projects and which safeguards you can put in place. Specifically, my primary source is the official OWASP Top 10:2025 page; the category names and their order come from there.

Note that this is not a penetration testing manual. My goal is simple. I want the person who owns the website to understand the categories and to ask the development team the right questions. So instead of code listings, each section ends with concrete checks you can run.

How did the OWASP Top 10 change in the latest edition?

The current edition is called OWASP Top 10:2025. Compared with the 2021 edition, the biggest shift is that software supply chain failures now have their own category in third place. In addition, mishandling of exceptional conditions enters the list as a brand new tenth category.

Some categories merged, too. For example, server side request forgery (SSRF) no longer stands alone; OWASP now groups it under broken access control. Moreover, security misconfiguration climbed from fifth to second place. In short, the list now reflects how modern sites actually break.

• A01: Broken Access Control.
• A02: Security Misconfiguration.
• A03: Software Supply Chain Failures.
• A04: Cryptographic Failures.
• A05: Injection.
• A06: Insecure Design.
• A07: Authentication Failures.
• A08: Software or Data Integrity Failures.
• A09: Security Logging and Alerting Failures.
• A10: Mishandling of Exceptional Conditions.

Do not read the order as a league table. A tenth place risk can still be the biggest threat on your own site. Therefore, treat the list as a map that you adapt to your application.

One more practical point. If you have audit reports based on the older edition, the codes no longer match. For instance, the old A05 misconfiguration item is now A02. So compare reports by category name, not by code.

What is broken access control (A01) and how do you prevent it?

Broken access control means a user can reach data or actions they should not. For example, the classic case: you change the order number in the address bar and suddenly see another customer's invoice. Security teams call this IDOR, an insecure direct object reference.

The mistake I see most often is a permission check that lives only in the interface. For example, the site hides the admin button from normal users, yet the API endpoint behind it stays open. In practice, an attacker never needs the button. They simply send the request by hand. That is why every check must run on the server, on every request.

• Make "deny" the default rule and grant access explicitly.
• On every record lookup, confirm the record belongs to the current user.
• Use unpredictable identifiers instead of sequential ones, but never rely on that alone.
• Protect the admin area with a separate path, an IP allowlist or extra verification.
• Limit outbound requests from your server to an allowlist; SSRF now sits in this category.

Also add role changes to your test cases. If a demoted user's old session still carries admin rights, the bug lives in session handling, not in the page code.

In practice, one shared authorisation layer makes life much easier. When every page carries its own permission code, someone eventually forgets one. A central check, by contrast, covers each new endpoint automatically.

Why is security misconfiguration (A02) so common?

Security misconfiguration means the code may be fine, but the server, framework or cloud settings leave a door open. Verbose error pages, default accounts, directory listing and unused services all belong here. OWASP moved this category up to second place.

The reason it spreads is simple, because configuration lives outside the code, and nobody owns it. The developer says hosting is the provider's job; the provider says the application is yours. Meanwhile, a forgotten backup file sits in the web root for anyone to download. I have caught exactly that on my own projects at least once.

• Turn off detailed error output in production and show a generic message.
• Disable directory listing and remove backups, .env and .git folders from the web root.
• Add security headers such as Content-Security-Policy, HSTS and X-Content-Type-Options.
• Remove services, ports and sample pages you do not use.
• Build environments from a repeatable template instead of manual setup.

Redirect chains are a quiet configuration issue too. You can check in seconds whether HTTP goes straight to HTTPS with the redirect checker.

Pay special attention to cloud storage settings as well. Otherwise, a public storage bucket can expose invoices and ID documents within minutes. I recommend a short monthly checklist for these settings.

How do software supply chain failures (A03) affect your site?

Software supply chain failures cover risk in code you did not write but still run. Libraries, plugins, themes, package dependencies and build tools all form links in that chain. The old "vulnerable and outdated components" item has grown into this broader category.

For example, a WordPress site may run thirty plugins. Moreover, each one has its own developer and its own update schedule. If one of them goes unmaintained, it leaves your door open. As a result, a compromised package can land on your server through a routine update.

• Keep an inventory of every component and version; this list is a software bill of materials (SBOM).
• Add dependency scanning to your build and stop the build on critical findings.
• Commit lock files such as package-lock or composer.lock and pin versions.
• Replace plugins and packages that have not seen updates for a long time.

In short, "if it works, do not touch it" fails in security. Regular maintenance also helps search visibility, which I cover in my article on keeping content fresh.

Keep in mind that updates carry their own risk. So test them on a staging copy first, then release to production. That way you close the hole without breaking the live site.

Which data do cryptographic failures (A04) expose?

Cryptographic failures happen when sensitive data travels or rests without encryption, or with weak encryption. Passwords, card details, national ID numbers and health records carry the highest risk. Usually the problem is not missing encryption. Instead, teams apply it in the wrong place or with an outdated algorithm.

The example I meet most often: passwords stored with unsalted MD5 or SHA1. Those algorithms are fast; however, fast is bad for password storage. After a leak, an attacker can try billions of guesses per second. Use Argon2, bcrypt or scrypt instead, because they are slow by design.

• Serve all traffic over TLS and switch on HSTS.
• Store passwords only with Argon2, bcrypt or scrypt.
• Keep keys out of source code and inside a secrets vault.
• Do not keep sensitive data you do not need; data you never store cannot leak.

Encouraging strong passwords is part of the job too. For example, ask your team to create panel passwords with the password generator. I also explain SPF, DKIM and DMARC for company mail in my business email guide.

Retention is a cryptography topic as well. Holding old customer records for years simply enlarges the blast radius of a breach. Consequently, define a deletion policy from day one.

How do you close injection flaws such as SQL injection and XSS (A05)?

Injection happens when an application treats user input as a command. SQL injection targets database queries, while cross site scripting (XSS) targets the page inside the browser. OS command and LDAP injection fall into the same group. The current edition places this category fifth.

The core rule: never mix data and commands. In other words, do not build a query by pasting user text into the query string. Use parameterised queries instead, so the driver carries data separately from the command. Modern ORMs do this by default, but stay careful wherever you write raw queries.

For XSS, escape output according to context. That is because rules differ inside HTML, inside attributes and inside JavaScript. So never switch off your template engine's automatic escaping. On top of that, a Content-Security-Policy header limits the damage of any XSS bug you miss.

1. Move all database access to parameterised queries.
2. Validate input against an allowlist; do not trust blocklists.
3. Escape output for the right context.
4. Give the database user only the rights it needs.

File upload fields are another injection door. Check the file name and type again on the server. Also store uploads in a folder without execute rights, so a script disguised as an image cannot run. For detailed patterns, the OWASP Cheat Sheet Series is a solid starting point.

Can you fix insecure design (A06) with better code?

Insecure design means the logic itself is flawed, however clean the code looks. Suppose your password reset flow relies only on a "mother's maiden name" question. Perfect code cannot rescue that weakness. So this category concerns decisions you make before anyone writes a line.

In real projects, I see it most often in business rules. A discount coupon that applies ten times to one order is a good example. A cart that accepts a negative quantity is another. Still, no scanner will flag these, because technically everything "works".

• Run threat modelling at the design stage and ask: "How could someone abuse this flow?"
• Write abuse cases as test cases.
• Add rate limits and replay checks to critical actions.
• Pick security requirements from a verification standard such as OWASP ASVS.

That is why I put security at the start of a project, not the end. You can see how I document architecture decisions in my article on enterprise web architecture.

Put simply, design flaws are the most expensive flaws to fix. Rebuilding a live flow takes far more effort than asking one extra question during the wireframe stage.

How do you prevent authentication failures (A07)?

Authentication failures let an attacker sign in as someone else. Login forms open to brute force, credential stuffing with leaked password lists and weak session handling all belong here.

The strongest single safeguard is multi factor authentication. I require two step verification on every admin panel I manage. Still, it does not work alone. You also need secure session cookies and limits on failed attempts.

• Require multi factor authentication on admin accounts.
• Rate limit failed logins per IP and per account.
• Check new passwords against known breach lists.
• Set Secure, HttpOnly and SameSite flags on session cookies.
• Invalidate all sessions on logout and on password change.

In addition, error messages leak information. "This email is not registered" tells an attacker which accounts exist. Instead, choose a neutral message such as "Email or password is incorrect".

Follow current password guidance as well. Long passphrases plus a breach check work better than complex character rules. As a result, users stop writing passwords on sticky notes.

What are software or data integrity failures (A08)?

Software or data integrity failures happen when an application trusts code or data it never verified. Auto updates without signature checks, third party scripts without integrity checks and unsafe deserialisation all fit here.

It overlaps with the supply chain category, so here is the difference. A03 looks at the risk inside a component itself. A08, by contrast, asks whether code or data changed on the way to you. For example, if your page loads a JavaScript file from an outside server, your visitors suffer the moment that server falls.

• Use Subresource Integrity (the integrity attribute) on external scripts.
• Require signed packages and protected branches in your build pipeline.
• Never deserialise objects that come straight from users.

So take care when you add marketing tags. Every new tracking script is foreign code with the power to run on your page. Review who has access to your tag manager on a regular basis.

A case I see often: a tracking tag from an old campaign that nobody remembers. When the vendor shuts down, its domain can change hands. At that point your page keeps running a stranger's code.

Why do logging and alerting failures (A09) make attacks last longer?

Security logging and alerting failures mean an attack leaves no record, or the record never reaches a human. The current edition added the word "alerting" on purpose. After all, a log nobody reads is not much better than no log.

On one client project, an attack ran for weeks while the logs captured everything. However, nobody looked at them. What finally raised the alarm was an odd customer complaint, not a security tool. Since then, I always set up instant notifications for critical events.

• Log failed logins, denied access and admin actions.
• Store logs outside the application in a tamper resistant place.
• Send email or chat alerts for critical events.
• Never write passwords or card numbers into logs.

Watch Google's signals as well. Search Console flags malware and hacked content in its Security Issues report. I explain the setup in my Google Search Console guide.

Decide on log retention in advance too. Some attacks surface only weeks later. If logs vanish after a few days, you cannot trace how the incident began.

What does mishandling of exceptional conditions (A10) mean?

Mishandling of exceptional conditions means an application behaves unsafely when something unexpected happens. This new category covers uncaught errors, detailed error messages shown to users and error paths that "fail open".

For instance, picture code that marks an order as paid when the payment verification service times out. Under normal load, nothing goes wrong, so nobody notices. Yet if an attacker can slow that service down, they get free orders. The safer pattern is "fail closed": when in doubt, reject the action.

• Fall back to a safe default in uncertain states: reject or hold the action.
• Show users a generic message and keep details in the log.
• Roll back half finished operations with database transactions.
• Trigger third party failures on purpose in your test environment.

This category matters most for payments, stock and permissions. In those flows, a half completed action means direct loss of money or data. Therefore, add the question "what if the service does not answer?" to your test plan.

In short, A10 asks not "what if everything goes right" but "what happens when things go wrong".

OWASP Top 10 categories and safeguards at a glance

The table below sums up the OWASP Top 10 with a typical example from my own work and a first safeguard for each. You can use it in a review meeting with your team.

Treat the table as a starting point. Each row hides dozens of details, so keep going back to the official source.

You can also add a status column to each row: done, planned or unknown. Honestly, "unknown" is the most dangerous answer, because it shows that nobody owns that risk.

Where should a small team start with the OWASP Top 10?

Small teams cannot do everything at once. I usually start with steps that have high impact and low cost. The order below reflects my field experience, not a guarantee; your system may need a different priority.

1. Switch on multi factor authentication for admin accounts.
2. Update every plugin, framework and server package; delete unused ones.
3. Clean backup and config files out of the web root.
4. Hide error details in production and add security headers.
5. Rate limit login forms.
6. Set up instant alerts for critical events.
7. Move database access to parameterised queries.
8. Test permission checks on the server side.

On most small sites, these eight steps take a few working days. That said, the real effort depends on the age of the system and the quality of its code. After that, you can move on to deeper testing.

Do not finish the list once and forget it; repeat it with every major release. Also record the date and owner of each step in a shared sheet. Six months later, everyone can see what is done without a debate.

Which tools can you use to test for OWASP Top 10 issues?

Automated scanners quickly find technical issues such as misconfiguration and known injection patterns. ZAP, an open source scanner, is a good place to start. However, only run a scanner against your own site or systems you have written permission to test.

That said, tools have blind spots. Broken access control and insecure design are business logic flaws, and usually only a human tester finds them. So I recommend pairing automated scans with a manual review.

• Static analysis (SAST): reads code without running it and catches injection patterns early.
• Dynamic analysis (DAST): sends requests to the running site and finds misconfiguration.
• Software composition analysis (SCA): lists packages with known vulnerabilities.
• Manual testing: catches permission and business logic flaws.

For example, you could run automated scans on every release and plan a manual test once a year or after major changes.

Also, do not accept scan results blindly. After all, scanners produce false positives. Rank each finding by severity, fix the exploitable ones first and note false positives with a reason.

Can a site hacked through OWASP Top 10 flaws lose its rankings?

Yes, indirectly but seriously. Attackers who get in through injection or misconfiguration often add spam pages, hidden links or redirects. When Google detects such content, it may show warnings in search results, and user trust falls fast.

In my SEO consulting work, security is one of the first things I check after a sudden, unexplained traffic drop. For instance, thousands of unknown URLs in your sitemap point to a security problem, not a content problem. I list other technical checks in my technical SEO tips.

After the cleanup, you can request a review through Search Console. However, if you clean up without closing the hole, the attacker returns the same way. Therefore, find the entry point first and then remove the content.

So security and SEO may look like separate departments, yet they serve the same goal. I support recovery after a cleanup as part of my SEO consulting work.

How do you build security into the web design process?

The cheapest vulnerability is the one nobody ever writes. That is why, on my web design projects, I put security requirements into the proposal. Which data we collect, who can access what and which plugins we use all get settled at the start.

Next, I run a short checklist before handover: admin accounts, security headers, backups and an update plan. As a result, the client receives not only a design but a system with defined maintenance.

• List your data inventory and user roles in the proposal.
• Check maintenance history before you pick a plugin or package.
• Name the person responsible for updates at handover.

For the first month after launch, I like to run updates together with the client team, so they learn the routine in practice. Besides, security requirements do not limit the designer. A well planned login screen can be both safe and easy to use.

Remember that security is not a one time job. A site without a maintenance plan becomes an A03 candidate within months.

Final thoughts: the OWASP Top 10 is a review framework

The OWASP Top 10 does not make your site secure; it tells you where to look. Above all, its real strength is a shared language. When a developer, a designer and a manager hear "A01", they all picture the same risk.

My suggestion: take the table above, ask "what is our status?" for each row and assign a named owner to every answer. Review the list with your team at least once a year.

Good security, like good design, succeeds when nobody notices it. Your visitors see nothing unusual, while you know your data, rankings and reputation stay protected. If you want to tackle security and SEO together on your project, reach me through the contact page.