{"id":6844,"date":"2026-02-05T07:00:00","date_gmt":"2026-02-05T07:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6844"},"modified":"2026-02-05T07:00:00","modified_gmt":"2026-02-05T07:00:00","slug":"software-supply-chain-risks-join-the-owasp-top-10-list-access-control-still-on-top","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6844","title":{"rendered":"Software supply chain risks join the OWASP top 10 list, access control still on top"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Software supply chain failures and mishandling of exceptional conditions are some of the additions to the updated OWASP Top 10<\/a>, a list of top web application vulnerabilities.<\/p>\n

Most of the list has remained unchanged since 2021. In fact, the top item, broken access control, has been on the Open Worldwide Application Security Project\u2019s list since it was first released in 2003.<\/p>\n

\u201cEveryone tries to craft their own authentication and access control mechanisms,\u201d says Jeff Williams, CTO and cofounder at Contrast Security. Williams created the list and served as the chair of the OWASP board for eight years.<\/p>\n

There are standard mechanisms out there, but most applications have specialized needs, he says. \u201cI\u2019ve seen some really god-awful horrific machines that people have built to do access control checks, and they don\u2019t build them elegantly. They build them piece by piece. \u2018Oh, we\u2019re building this function, we need to do an access check\u2019 \u2014 <\/strong>and they build their own access check. And almost nobody tests access control.\u201d<\/p>\n

A typical web application may have a hundred endpoints, Williams says, each one of which can be accessed by a number of different roles. \u201cNow you have to make sure that each of those routes work in each of those roles. Most people do a scan of their application with one role in mind, like that of a normal user. And maybe with an admin user. But there could be twenty different roles, so it\u2019s very difficult to verify.\u201d<\/p>\n

AI didn\u2019t make the top ten list, but it was included in a \u201cnext steps\u201d section of issues on the cusp of inclusion, in addition to a lack of application resilience and memory management failures.<\/p>\n

This AI category is titled: X03:2025<\/a> Inappropriate Trust in AI Generated Code (\u2018Vibe Coding\u2019).<\/p>\n

\u201cAlthough we didn\u2019t have data to support the fact that AI-generated code is causing significantly more risk than human-written code available, thanks to community feedback, professional experience, and constant online sharing of such data, we felt it prudent to add a section,\u201d says Tanya Janca, lead author of the OWASP Top 10.<\/p>\n

Developers should read and fully understand AI-generated code before committing it, she says.<\/p>\n

The OWASP Top 10 list is based on a combination of security data from a dozen different organizations, covering nearly 3 million applications, as well as a survey of 221 security experts, says security metrics expert Aram Hovsepyan, CEO at Codific and an OWASP contributing member.<\/p>\n

Here are the top 10:<\/p>\n

1 \u2013 Broken access control<\/h3>\n

When applications fail to properly enforce restrictions on what authenticated users are allowed to do, allowing attackers to access unauthorized functionality or data. For example, an attacker might manipulate an URL parameter to access another user\u2019s account information or escalate their privileges from a regular user to an administrator. This item now includes server-side request forgery, which was its own list item in 2021.<\/p>\n

2 \u2013 Security misconfiguration<\/h3>\n

Security settings are not properly defined, implemented, or maintained, leaving systems exposed to attack. Common examples include default credentials that are never changed, unnecessary features left enabled, verbose error messages that reveal sensitive information, or cloud storage buckets left publicly accessible. This vulnerability jumped from fifth place in 2021 to second place in 2025.<\/p>\n

3 \u2013 Software supply chain failures<\/h3>\n

Attackers compromise software during the build, distribution or updates to inject malicious code that gets distributed to multiple organizations. For example, attackers might compromise a popular open-source library<\/a> and inject malicious code that then gets incorporated into thousands of applications that depend on it or breach a vendor\u2019s system to insert backdoors into legitimate software updates. This is a new list item, though there was a narrower related item in 2021 \u2014 <\/strong>vulnerable and outdated components.<\/p>\n

\u201cDevelopers have become a primary target for many online attacks now,\u201d says Janca. \u201cIt is no longer a problem of including a library that has a questionable dependency.\u201d Instead, she says, there are now active attacks against the IDE, against the CI\/CD pipeline, against plugins and repositories, against developer workstations, and more. \u201cThe entire software supply chain is currently a focus for attackers,\u201d she says.<\/p>\n

4 \u2013 Cryptographic failures<\/h3>\n

Applications fail to properly protect sensitive data through encryption or use weak or broken cryptographic algorithms. Examples include transmitting sensitive data in clear text, using weak encryption algorithms, not properly validating SSL\/TLS certificates, or storing passwords without proper hashing. These failures often lead to sensitive data exposure or system compromise. This item moved down from second place on 2021\u2019s list.<\/p>\n

5 \u2013 Injection<\/h3>\n

Untrusted data is submitted as part of a command or query, tricking the application into executing unintended commands or accessing unauthorized data. Examples range from cross-site scripting, where attackers inject malicious scripts into web pages viewed by other users, to SQL injection, where they use database queries to access or modify sensitive data. This item has also moved a couple of spots down on this year\u2019s list.<\/p>\n

6 \u2013 Insecure design<\/h3>\n

Security wasn\u2019t properly considered during the design phase of the application, resulting in missing or ineffective controls. Examples include failing to implement proper threat modeling, not establishing security requirements before development begins, or designing systems that lack defense in depth. This category was introduced in 2021 to focus on design and architectural flaws rather than implementation bugs, but it\u2019s moved down a couple of places because the industry has made noticeable improvements in threat modeling.<\/p>\n

7 \u2013 Authentication failures<\/h3>\n

Applications fail to properly verify the identity of users or fail to protect authentication credentials and session tokens. Examples include allowing brute force attacks, permitting weak passwords, exposing session IDs in URLs, not properly invalidating sessions after logout, or failing to implement multi-factor authentication<\/a> for sensitive functions.<\/p>\n

8 \u2013 Software or data integrity failures<\/h3>\n

Applications fail to maintain trust boundaries and verify the integrity of software, code, and data artifacts. Examples include applications that rely on plugins, libraries, or modules from untrusted sources without integrity checks, insecure CI\/CD pipelines that allow code to be modified before deployment, or applications that auto-update without verifying digital signatures.<\/p>\n

9 \u2013 Security logging and alerting failures<\/h3>\n

Applications fail to log security-relevant events or fail to alert security teams when suspicious activities occur. Examples include not logging failed login attempts, storing logs locally without backup, logging insufficient detail to reconstruct attacks or generating logs that don\u2019t integrate with security information and event management (SIEM) systems. Great logging with no alerting is of minimal value in identifying security incidents.<\/p>\n

10 \u2013 Mishandling of exceptional conditions<\/h3>\n

Applications fail to properly handle errors, edge cases, and abnormal conditions, leading to security vulnerabilities. Examples include displaying detailed error messages that reveal sensitive information about system architecture, security checks that fail and allow unauthorized access when errors occur, or applications that crash and expose sensitive data in memory dumps.<\/p>\n

This is a category that has been just outside the top 10 for several years, says Brian Glas, department chair of computer science at Union University and an OWASP project leader. What took this item over the top was not the data about existing vulnerabilities, he says, but the survey of experts.<\/p>\n

\u201cIf it was purely data-driven, we would not have an accurate list as it would only be looking into the past.\u201d<\/p>\n

Related stories:<\/strong><\/p>\n

10 most critical LLM vulnerabilities<\/a><\/p>\n

Managing agentic AI risk: Lessons from the OWASP Top 10<\/a><\/p>\n

Understanding OWASP\u2019s Top 10 list of non-human identity critical risks<\/a><\/p>\n

Keeping up with AI: OWASP LLM AI Cybersecurity and Governance Checklist
<\/a>
<\/a>
<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Software supply chain failures and mishandling of exceptional conditions are some of the additions to the updated OWASP Top 10, a list of top web application vulnerabilities. Most of the list has remained unchanged since 2021. In fact, the top item, broken access control, has been on the Open Worldwide Application Security Project\u2019s list since […]<\/p>\n","protected":false},"author":0,"featured_media":6845,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6844","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6844"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6844"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6844\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/6845"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6844"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6844"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6844"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}