OWASP Top 10 Explained for Website Owners

The OWASP Top 10 is a widely used awareness document listing the most critical security risks to web applications, published by the Open Worldwide Application Security Project (OWASP). The current edition, OWASP Top 10:2025, was finalised in early 2026 and puts Broken Access Control at number one, as in the previous edition, with two new categories: Software Supply Chain Failures and Mishandling of Exceptional Conditions.

You do not need to be a developer to use it: it is a practical checklist of questions to ask whoever builds or maintains your website or application.

The 2025 list in plain language

A01: Broken Access Control

Users can do or see things they should not, such as viewing another customer's order by changing a number in the URL, or reaching admin pages without admin rights. Server-side request forgery (SSRF) is now included here.

Ask: "Does every request check that this user may access this specific record?" See API security basics.

A02: Security Misconfiguration

Insecure settings: debug mode left on, default passwords, unnecessary features enabled, missing security headers, overly permissive cloud storage.

Ask: "How do we check production configuration before release?" See HTTP security headers explained.

A03: Software Supply Chain Failures

Risks from the components and tools you depend on: vulnerable or abandoned libraries and plugins, compromised packages, insecure build and deployment pipelines.

Ask: "How do we track dependencies and apply security updates? Who can change the build and deployment process?"

A04: Cryptographic Failures

Sensitive data not properly protected: no HTTPS, weak password hashing, sensitive data stored unencrypted, or poor key management.

Ask: "Is all traffic over HTTPS? How are passwords and sensitive fields stored?" See what is SSL/TLS and how does HTTPS work.

A05: Injection

Untrusted input interpreted as code or commands: SQL injection, command injection and cross-site scripting (XSS).

Ask: "Do we use parameterised queries everywhere and escape output by default?" See database security best practices.

A06: Insecure Design

Security problems built into the design itself, such as a password reset flow that can be abused, or no limits on actions that should be limited.

Ask: "Did we think through how features could be abused before building them?"

A07: Authentication Failures

Weak login and session handling: allowing weak or breached passwords, no protection against brute force, sessions that never expire, missing 2FA for privileged users.

Ask: "Do we rate-limit logins, support 2FA and invalidate sessions properly?" See brute-force attack prevention and secure cookies explained.

A08: Software or Data Integrity Failures

Trusting code or data without verifying it: updates without signature checks, unsafe deserialisation, or accepting critical data (such as payment status) from the browser without verification.

Ask: "Do we verify webhooks and payment confirmations with the provider?"

A09: Security Logging and Alerting Failures

Attacks go unnoticed because important events are not logged, or nobody is alerted when they happen.

Ask: "Would we notice a burst of failed logins or a new admin account? Who gets the alert?"

A10: Mishandling of Exceptional Conditions

Applications that fail unsafely when something unexpected happens: errors that reveal internal details, failures that leave the system in an insecure state, or error paths that skip security checks.

Ask: "What happens when a dependency fails or input is unexpected? Do errors fail closed and stay generic?"

Example: one flaw, several categories

Real vulnerabilities often touch several categories at once. Consider a customer portal where:

• invoice PDFs are served from /invoices/download?file=INV-1043.pdf with no check that the invoice belongs to the logged-in customer (A01 Broken Access Control);
• the file parameter is passed straight to the filesystem, so ../../.env downloads the application's configuration (A05 Injection, path traversal);
• the .env file contains database passwords and API keys (A02 Security Misconfiguration and A04 Cryptographic Failures in handling secrets);
• nobody notices for months because downloads are not logged or alerted on (A09 Security Logging and Alerting Failures).

The fixes map to the same list: look up invoices by ID within the customer's own records, never pass user input to file paths, keep secrets out of the web root, and alert on unusual download patterns.

A short checklist for a website review

• Every page and API checks the user's permission for the specific record
• Production configuration reviewed (debug off, default accounts removed, security headers set)
• Dependencies, plugins and themes up to date, with a process to keep them so
• HTTPS everywhere; passwords stored with strong hashing
• Parameterised queries and escaped output by default
• Abuse cases considered for sensitive features (password reset, coupons, checkout)
• Login protected with rate limits and 2FA for staff
• Payment confirmations and webhooks verified server-side
• Security events logged, with alerts someone acts on
• Errors fail safely and show generic messages

How to use the list

• Business owners: use the questions above when hiring developers or reviewing a project.
• Developers: treat it as a minimum baseline, alongside OWASP's more detailed verification standard and cheat sheets.
• Everyone: combine it with basics like updates, backups and monitoring; see website security basics.

Frequently Asked Questions

Is the OWASP Top 10 a compliance standard?

No. It is an awareness document. Some standards reference it, but it is not a complete checklist of everything secure software needs.

Does a WordPress site need to worry about the OWASP Top 10?

Yes. Plugins and themes can contain any of these flaws, which is why keeping them updated and choosing them carefully matters. See the WordPress security checklist.

How often is the list updated?

Roughly every few years, based on data from many organisations. The 2025 edition followed the 2021 edition.

Related reading

For framework-specific advice, see the Laravel security checklist. For applications built with security in mind, see ServerNeed custom web development.

Sources

• OWASP Top 10:2025
• OWASP Cheat Sheet Series