Reference

The OWASP Top 10, and how we build against it.

What OWASP is, the ten most critical risks to web applications and the ten for anything built on AI, what we do about each one, and how our ISO 27001 certified development controls make sure it happens on every project. Checked 14 November 2026.

What OWASP is

Free, open and independent.

OWASP, the Open Worldwide Application Security Project, is a not-for-profit foundation. Its guides, standards and tools are written by the security community, free to use and tied to no vendor.

  • Open and independent

    Written in the open by security practitioners worldwide and based on data about real weaknesses, which is why buyers, auditors and developers all refer to it.

  • The Top 10 for web applications

    The ten most critical security risks to web applications. The current edition is 2025, the first update since 2021, with supply chain failures and the handling of unexpected conditions new to the list.

  • The Top 10 for LLM applications

    The ten most critical risks for anything built on a large language model, from chat assistants to agents. The current edition is 2026, the first shaped partly by data from real incidents.

A standard to build against, not a certificate.

The Top 10 lists are awareness documents: a shared, prioritised view of what goes wrong most often and does the most damage. There's no such thing as being "OWASP certified" or "OWASP compliant", and the lists aren't everything a secure system needs.

That's why we use them in two ways. They set the minimum every system we build is designed, coded and tested against, and they give you and us a common language when we review a system someone else built. The controls that make sure it happens on every project come from our ISO 27001 certified secure development policy, below.

OWASP Top 10:2025, A01 to A10

The ten web application risks, and what we do.

For storefronts, customer portals, apps and the integrations behind them.

  • Broken access control

    People reaching data or actions they shouldn't, such as another customer's orders, another account's prices or an admin page. We deny by default, check permissions on the server for every request, and test as each role, including one customer trying to see another's records.

  • Security misconfiguration

    Default settings, open admin areas, detailed error pages and missing security headers. We use hardened, repeatable configuration for each environment, restrict admin areas, set security headers and review configuration before go-live.

  • Software supply chain failures

    Vulnerable or compromised libraries, extensions, build tools and third-party scripts. We use approved components only, scan dependencies for known vulnerabilities, apply updates on a schedule and keep track of every script on payment pages.

  • Cryptographic failures

    Data sent or stored without proper encryption, weak algorithms and badly kept keys. We use HTTPS throughout, encrypt sensitive data at rest, hash passwords with modern algorithms and keep keys and secrets out of the code.

  • Injection

    Untrusted input run as a command or query, as in SQL injection and cross-site scripting. We validate every input, use parameterised queries and output encoding, and run automated code analysis to catch what slips through.

  • Insecure design

    Flaws in the design itself that good code can't fix, such as a quote or credit process with no limits. Every project starts with security requirements and threat modelling, and significant work has a design review.

  • Authentication failures

    Weak sign-in that lets attackers take over accounts with stolen passwords or hijacked sessions. We use multi-factor sign-in where it matters, rate limits on sign-in, and sessions that expire and can't be reused.

  • Software or data integrity failures

    Trusting code, updates or data that haven't been checked. Code reaches production only through version control and an approved release between separate environments, with integrity checks on scripts that shouldn't change.

  • Security logging and alerting failures

    Attacks that go unnoticed because nothing was logged or nobody was told. We log security events, monitor around the clock, alert on what matters and follow a tested incident process.

  • Mishandling of exceptional conditions

    Systems that fail open or give away internal details when something unexpected happens, like an integration timing out. We design systems to fail safe, show errors without revealing internals, and test what happens when the systems they depend on go wrong.

OWASP Top 10 for LLM Applications 2026, LLM01 to LLM10

The ten AI risks, and what we do.

For assistants, agents, search and anything else built on a large language model. OWASP also publishes a companion Top 10 for Agentic Applications (December 2025), which we use for agents that act on your systems.

  • Prompt injection

    Instructions hidden in what the model reads, such as an email, a web page or a product description, that steer what it does. We treat everything the model reads as data, not instructions, enforce its limits in code rather than in the prompt, and test with injection attempts.

  • Sensitive information disclosure

    The model revealing personal, commercial or account data it shouldn't. It's given only the data the job and the person asking are allowed to see, so there's nothing else for it to give away.

  • Excessive agency

    An AI with more access or freedom than its job needs. Each one has its own identity with the least access that works, and anything that commits money, stock or a promise is approved by a person first.

  • Supply chain

    Models, plugins, tools and datasets from other companies. We use approved providers and components, reviewed like any other supplier under our ISO 27001 controls.

  • Data and model poisoning

    Tampered training or reference data that changes what the model says or does. The sources an assistant draws on have owners, controlled changes and a record of what was added.

  • Unbounded consumption

    Runaway costs, or a service brought down by too many requests. Every system has limits on requests, steps, time and spend, and a stop condition the model doesn't control.

  • Misinformation

    Confident answers that are wrong. Answers are grounded in your own sources, confidence is shown, and the assistant hands over to a person when it isn't sure.

  • Hidden context exposure

    Instructions and background the model is given (formerly called system prompt leakage) being drawn out by users. We keep secrets and access rules out of prompts altogether and enforce them in code.

  • Vector and embedding weaknesses

    Weaknesses in the search behind an assistant that leak information between users or let it be manipulated. Permissions are checked on every search, so people only get answers from what they're allowed to see.

  • Improper output handling

    Passing what the model writes straight into pages, queries or other systems. We treat its output as untrusted input, validating and encoding it before anything uses it.

How our ISO 27001 controls make it happen.

Knowing the risks isn't the hard part. Making sure every project deals with them, every time, is. That's what our secure development policy does. It's part of our information security management system, certified to ISO/IEC 27001:2022 and independently audited every year, and it puts the standard's secure development controls (Annex A 8.25 to 8.31, with 8.8 for technical vulnerabilities) into daily practice.

  • A secure development lifecycle. Security is part of every stage: requirements, design, build, testing, release and support.
  • Security requirements from the start. Set for each project from the sensitivity of the data, the law and regulations that apply, industry standards such as the OWASP Top 10, and the risk involved.
  • Threat modelling and design reviews. We work out how a system could be attacked before it's built, and significant projects have a security design review.
  • Secure coding standards, and training. Our developers are trained in secure coding for the languages they use, to standards covering input validation, authentication and sessions, access control, cryptography, error handling and logging, and injection.
  • Testing throughout. Automated code analysis while we build, security testing of the running application, and independent penetration testing of completed systems.
  • Nothing known goes live. Vulnerabilities we find are fixed before release, unless a director accepts the risk after a documented risk assessment.
  • Separate environments. Development, testing and production are kept apart with their own access controls, live personal data isn't used in testing unless it's been anonymised or masked, and code moves between environments only through version control and approval.
  • Third-party code kept in check. Libraries and components are approved before use and regularly reviewed for known vulnerabilities.

Our annual ISO 27001 audits check that this happens in practice, not just on paper.

Questions

What people ask us.

Can a website be OWASP certified or OWASP compliant?

No. OWASP doesn't certify anything, and the Top 10 lists are guidance rather than a standard you pass. What you can show is that a system was built and tested against them, and an independent penetration test is the usual evidence.

Is the Top 10 enough on its own?

No. It covers the most common and most damaging risks, not every one. For detailed requirements OWASP publishes the Application Security Verification Standard (ASVS), and payments, personal data and your sector may bring their own rules, such as PCI DSS.

We're on Shopify Plus or BigCommerce. Does this still apply?

Yes, to your side of it. The platform provider looks after the platform, but your apps, theme code, scripts, staff accounts and integrations are yours, and most of the Top 10 applies to them.

Can you check a system someone else built?

Yes. We review storefronts, portals, apps and AI built by others against both lists, rank what we find by impact and fix what matters most first. Independent penetration testing is part of it where you need proof.

How often do the lists change?

Every few years. The web list was updated in 2025 for the first time since 2021, and the LLM list in 2025 and again in 2026 as AI moves faster. We keep this page up to date when they change.

Sources.

Checked 14 November 2026. The lists themselves, from OWASP: