OWASP Top 10 still points to access control and misconfig gaps

At a glance

What this is: The latest OWASP Top 10 shows familiar application risk patterns, with broken access controls and security misconfigurations still dominating despite category reshuffles.

Why it matters: For IAM, PAM, application security, and cloud security teams, this reinforces that access governance and configuration control remain core compensating controls even when app risk taxonomies change.

By the numbers:

• The current OWASP Top 10 is based on data for over 2.8 million apps donated by a variety of large cybersecurity firms, along with a survey circulated to security professionals.
• The report finds 3.73% of the analyzed apps impacted by the #1 category of flaws.

👉 Read Swarmnetics' analysis of the latest OWASP Top 10 findings

Context

The primary issue is not that application risk disappeared. It is that the same control failures keep reappearing under different labels, especially broken access control and misconfiguration. For identity practitioners, that matters because application security failures often become access failures once privilege, tokens, or federated trust paths are involved, which is why IAM and application security cannot be managed as separate conversations.

The article also highlights a structural limitation in how the OWASP Top 10 reads the environment. It is still largely a pre-cloud lens, so cloud-hosted systems, software supply chains, and AI-enabled development patterns create risk surfaces that are only partially captured. That makes the report useful as a baseline, but incomplete as a governance model for modern identity, NHI, and application estates.

Key questions

Q: What breaks when broken access control is treated as a purely application-layer issue?

A: Teams miss the service and token boundaries where authorization actually fails. In modern applications, privilege is often expressed through APIs, workload tokens, and internal calls, so a user-centric view leaves the real trust path unprotected. Security teams need to test where authorization is enforced, inherited, and bypassed across the application stack.

Q: Why do security misconfigurations keep creating major exposure in cloud environments?

A: Because configuration is now part of the runtime control plane, not a one-time setup task. Default permissions, exposed services, and drift across environments can create persistent access that is hard to notice and harder to retire. Continuous verification is the only reliable way to keep configuration aligned with intended trust.

Q: How do security teams know whether secure-by-design is actually improving app risk?

A: Look for fewer repeat findings in authorization, configuration, and dependency trust tests, not just fewer policy exceptions. Improvement shows up when runtime evidence confirms that critical functions are server-checked, cloud defaults are locked down, and supply chain controls are verified before release. If the same flaw classes keep returning, design reviews are not changing execution.

Q: Who should own access control and configuration failures in modern application estates?

A: Ownership should sit with the teams that can change the control in production: application engineering for authorization logic, cloud platform teams for baseline configuration, and identity teams for privileged access and trust policy. If ownership is split without a clear runtime test, gaps persist because no one is accountable for the control working end to end.

Technical breakdown

Broken access control in modern applications

Broken access control remains the most persistent application security failure because the application cannot reliably decide who or what is entitled to perform an action. In practice, this includes predictable object identifiers, missing server-side authorization checks, excessive function exposure, and weak session-to-resource binding. In identity terms, the control plane is failing at authorization, not just authentication. Where human IAM, service accounts, tokens, or delegated API access are involved, the application often trusts identity claims that have not been continuously revalidated.

Practical implication: map high-risk app functions to explicit authorization checks and test whether identity claims are enforced server-side, not just in the UI.

Security misconfigurations in cloud-hosted applications

Security misconfiguration has risen because modern applications are assembled from defaults, templates, managed services, and infrastructure code, any of which can expose data or broaden access when left unchanged. Common failures include permissive storage settings, exposed admin endpoints, weak network segmentation, and error handling that reveals sensitive detail. The article’s cloud framing matters because configuration errors often become identity errors when overbroad roles, tokens, or trust relationships are bound to those services. Misconfiguration is therefore both an infrastructure issue and an access governance issue.

Practical implication: tie configuration baselines to identity permissions so exposed services cannot inherit broad access by default.

Software supply chain failures and exceptional conditions

The reshaped middle and lower categories reflect a broader maturity problem. Software supply chain failure is not just about outdated components, but about trust in dependencies, build paths, and update channels that can be abused before deployment. Mishandling of exceptional conditions points to a different class of weakness: error states, fallback logic, and incomplete handling paths that can leak data or bypass controls. These issues matter because security teams often test the happy path while attackers target error paths and trust chains.

Practical implication: test dependency trust and error handling as first-class attack surfaces, not as edge cases discovered after release.

NHI Mgmt Group analysis

Broken access control is still the most durable application security failure because identity decisions are too often assumed instead of enforced. The article’s reminder that URL guessing, identifier enumeration, and missing authorization checks still appear in modern apps shows how frequently access logic is treated as a thin layer instead of a control boundary. For IAM and PAM teams, the lesson is that entitlement design and app enforcement must be aligned, or the application becomes the weakest authorization layer in the stack.

Cloud misconfiguration is now an identity problem as much as an infrastructure problem. When storage, compute, and API gateways are deployed with permissive defaults, the resulting exposure is usually widened by overbroad roles, stale tokens, or weak trust relationships. That is why configuration governance should be reviewed alongside privilege boundaries, not as a separate cloud-only discipline. Practitioners should treat configuration drift as access drift.

Secure-by-design gains are real, but they do not offset a category model that still underweights cloud-native and AI-era risk. The article notes movement in threat modelling and design-time controls, which is encouraging, but app risk taxonomies built on older deployment assumptions will always lag operational reality. That means security architects need to supplement OWASP Top 10 thinking with identity, cloud, and supply chain controls that reflect how software is actually built and run. The practical conclusion is to govern the runtime, not just the review checklist.

Software supply chain failure and exceptional-condition handling point to a governance blind spot that many teams still miss. Attackers do not need a novel exploit when dependency trust and error paths remain under-tested. This is where the OWASP Top 10 intersects with modern identity governance: build pipelines, secrets handling, and service credentials often flow through those same paths. Practitioners should close the gap between code security reviews and operational trust decisions.

Top 10 rankings are useful only if teams translate them into control ownership. The report can tell you which flaw classes persist, but it cannot tell you which team owns authorization logic, configuration baselines, or dependency trust. That is a governance problem, not a taxonomy problem. The practical takeaway is to assign each recurring OWASP pattern to a named control owner and verify it in runtime evidence, not policy language.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For deeper context: Review Top 10 NHI Issues to connect broken access control patterns with NHI governance gaps.

What this signals

Access control and configuration failures should now be treated as governance signals, not isolated engineering defects. The persistence of these two categories means security leaders need a single view of authorization, configuration drift, and privileged paths across application and identity teams. Where identity is involved, the practical test is whether the same entitlement can be safely enforced in code, at runtime, and in review.

The control gap is increasingly between design intent and operational enforcement. That gap shows up when secure-by-design language improves but the same flaw families keep returning. For identity-heavy environments, the answer is to align application authorization, cloud baselines, and privileged access policy under one evidence-driven control model.

Top 10 language can still help prioritisation, but only if teams translate it into named operational controls. A recurring flaw category is a prompt to inspect runtime evidence, not to reword the risk register. The practical implication is to track whether critical app paths, cloud defaults, and service credentials are actually being governed, not merely documented.

For practitioners

• Map authorization checks to business-critical app functions Identify the application actions that expose data, administrative capability, or privileged workflows, then verify that each one is enforced server-side with explicit authorization logic rather than client-side assumptions. Where service accounts or tokens are used, require the same entitlement review discipline you use for human access.
• Bind cloud configuration baselines to access policy Treat misconfiguration as an access issue by pairing infrastructure baselines with identity and role constraints for storage, APIs, and administrative endpoints. Build alerts for permissive defaults, public exposure, and roles that grant broader access than the service requires.
• Test dependency trust and error paths before release Add build-time and pre-production checks for dependency provenance, fallback handling, and error-state behaviour, because attackers often exploit the paths that teams do not consider part of the main workflow. Review secrets, build credentials, and token handling wherever the supply chain touches production.
• Assign OWASP categories to control owners Turn the Top 10 into an ownership model by mapping broken access control, misconfiguration, supply chain failure, and error handling to specific engineering, cloud, or IAM teams. Review runtime evidence quarterly to confirm the control is operating, not just documented.

Key takeaways

• Broken access control and misconfiguration remain the most durable application security problems, even as OWASP category labels change.
• The article’s scale data shows that application risk is still broad, with more than 2.8 million apps analysed and 3.73% affected in the top flaw category.
• Practitioners should translate OWASP categories into runtime control ownership across authorization, configuration, and supply chain trust.

Key terms

• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Security Misconfiguration: Security misconfiguration is a control failure caused by unsafe defaults, incorrect settings, or overly broad permissions in systems and pipelines. In NHI environments, it often shows up as exposed secrets, persistent roles, or permissive cloud templates. The risk is that routine automation becomes a durable access path.
• Secure-by-Design: Secure-by-design means security requirements are built into the development process rather than added after release. The practical aim is to define minimum acceptable controls early, then enforce them consistently so products cannot ship without passing baseline security checks.
• Software Supply Chain Failure: A software supply chain failure is any breakdown in the build, dependency, signing, or distribution chain that allows tampering, compromise, or unauthorized access. For NHI security, the concern is not only corrupted code but also the credentials and machine identities that move that code through the pipeline.

What's in the full analysis

Swarmnetics' full article covers the category-by-category movement and interpretation this post intentionally leaves for the source:

• Its breakdown of how category mergers changed the apparent ranking movement in the 2025 OWASP Top 10.
• Its discussion of the pre-cloud bias in the list and why that matters for cloud-hosted systems.
• Its examples of specific flaw types such as URL guessing, user ID enumeration, and exception handling failures.
• Its commentary on how threat modelling and secure-by-design practices are influencing category movement.

👉 Swarmnetics' full post covers the ranking shifts, category mergers, and app-risk context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives security and identity practitioners a practical foundation for governing access, privilege, and trust across modern environments.