Back to Blog
8 min read

The OWASP Top 10 for 2026: what's changed and how to adapt your stack

The 2026 OWASP Top 10 release reflects three years of threat data collected from real-world incidents and security assessments. The list includes two new categories, one significant restructuring, and one entry that has held the top position for the third consecutive release. Here is what changed and what your team should do about it.

OWASP updates their Top 10 Web Application Security Risks list every three to four years, incorporating data from security assessments, bug bounty programmes, and incident response engagements. The 2026 edition reflects a threat landscape meaningfully shaped by two macro trends: the widespread integration of LLMs into web applications, and the maturation of supply chain attacks as a primary enterprise attack vector.

Important Note

This article discusses the 2026 OWASP Top 10 framework in the context of application security design. The specific list reflects our interpretation based on emerging threat trends as of the article publication date. Always refer to the official OWASP documentation for the authoritative current list.

The two new entries

LLM Integration Security (new)

The explosive adoption of LLM-powered features — chatbots, code assistants, document summarisation, automated email drafting — has introduced a new attack surface that simply did not exist at scale in previous OWASP cycles. The 2026 addition covers several distinct attack patterns under this category:

  • Prompt injection — Attackers embed malicious instructions in user-controlled content that is subsequently processed by an LLM, causing it to ignore system instructions, exfiltrate data, or perform unintended actions.
  • Indirect prompt injection — The injected instructions come not from the direct user input but from external content the LLM processes: web pages, documents, emails, database records.
  • LLM output trust — Applications that trust LLM output without validation, using it to construct SQL queries, shell commands, or HTML without sanitisation.
  • Excessive LLM agency — LLM agents granted too-broad access to internal tools and systems, enabling privilege escalation through prompt injection.

The key mitigation for all of these is the same: treat LLM output as untrusted user input. Apply the same sanitisation, parameterisation, and validation you would apply to any external data source before using it in any downstream operation.

Software Supply Chain Attacks (new)

Supply chain attacks — where adversaries compromise software components, build systems, or update mechanisms rather than attacking the target directly — have moved from high-profile isolated incidents (SolarWinds, XZ Utils) to a regular feature of the threat landscape. The 2026 Top 10 formalises this as a distinct category.

The attack surface is substantial: npm packages with post-install scripts, transitive dependencies with millions of downstream users, compromised CI/CD pipelines, and malicious packages with typo-squatted names. Mitigations include:

  • Software Bill of Materials (SBOM) generation for all production builds
  • Dependency pinning with hash verification (not version pinning alone)
  • Private dependency proxies with vulnerability scanning
  • Signed commits and provenance attestation in CI pipelines
  • Regular automated dependency audits with defined remediation SLAs

Broken Access Control: still number one

Broken Access Control has held the top position in the OWASP Top 10 for the third consecutive release. This is worth pausing on. The industry has invested substantially in security tooling, developer education, and automated vulnerability scanning — and yet access control failures remain the most prevalent category of serious web application vulnerability.

The pattern we see repeatedly in our penetration tests is not a lack of authentication — most systems authenticate users adequately — but a failure to consistently enforce authorisation at the data level. A user can log in correctly, but then access another user's data by modifying an ID in the URL or API request body. This is an Insecure Direct Object Reference (IDOR), and it remains shockingly common.

Quick Test

In your application, pick any resource endpoint that takes a user-owned ID as a parameter. Log in as User A, get a resource ID that belongs to User B, and try to access it. If you can, you have a broken access control vulnerability. We find this in approximately 60% of applications we test.

The fix is consistent server-side authorisation checks at every data access, with policies that verify not just that the user is authenticated but that they are specifically authorised to access the requested resource. Libraries like CASL (JavaScript), Pundit (Ruby), and OPA (Open Policy Agent) make this enforceable at the application level.

The notable restructuring: cryptography failures

The previous "Sensitive Data Exposure" category has been restructured and renamed "Cryptographic Failures," reflecting a more precise framing of the underlying root cause. The category now explicitly covers:

  • Data transmitted in cleartext (HTTP, FTP, SMTP without TLS)
  • Use of deprecated or weak cryptographic algorithms (MD5, SHA-1 for security purposes, DES)
  • Weak or default encryption keys
  • Missing or improper certificate validation
  • Passwords stored without appropriate hashing (bcrypt, Argon2, scrypt)

What your team should do now

The practical implications of the 2026 changes for most application teams:

  1. Audit all LLM integrations for prompt injection surface area. Treat every piece of external content processed by your LLM as untrusted. Never use raw LLM output in database queries, shell commands, or HTML without sanitisation.
  2. Generate an SBOM for your production applications using tools like Syft or CycloneDX. Know what you are shipping before an adversary does.
  3. Test your authorisation layer, not just your authentication. Automated IDOR testing should be part of your CI security scan. Tools like Burp Suite Pro, OWASP ZAP, or Nuclei can automate much of this.
  4. Dependency audit — run npm audit, pip-audit, or trivy against your entire dependency tree. Set up automated alerts for newly disclosed CVEs in your stack.

If you would like an independent assessment of your application against the 2026 Top 10, our security team offers penetration testing engagements that typically complete within two weeks.

More from the blog

AI & Machine LearningMay 22, 2026

Why most AI projects fail — and what the successful ones do differently

After 40+ AI implementations, the patterns that separate projects that deliver ROI from those that stall at the POC stage.

Read more
Cloud InfrastructureMay 15, 2026

Kubernetes cost optimisation: five patterns that cut our clients' bills by 40%

Container orchestration is powerful and easy to over-provision. Five techniques we apply to every K8s deployment.

Read more
Digital TransformationApril 14, 2026

Digital transformation without the buzzwords: a practical framework

Most transformation programmes fail because they start with technology instead of outcomes. This is the framework we use with every client.

Read more
WhatsApp