OWASP Top 10 2025: What’s changed and how to identify coverage gaps
Application security tools evolve, but so do the risks they need to catch. A security testing process built around the OWASP Top 10: 2021 may still be useful, yet the 2025 edition brings changes that teams need to account for.
The latest OWASP Top 10 expands the focus on software supply chain security, highlights mishandling of exceptional conditions as a distinct risk, and changes how several existing categories are ranked and scoped. These changes matter when you’re deciding whether your current security tools, testing methods, and development processes provide enough coverage.
Simply checking whether a scanner supports the OWASP Top 10 isn’t enough. You need to understand what each category covers, which tests can identify the relevant weaknesses, and where manual review or other security tools are still necessary.
This guide breaks down the OWASP Top 10 2025 changes, explains what each category means, and shows how to assess your current application security coverage, with Beagle Security as one part of a broader testing strategy.
What is OWASP Top 10 2025?
The OWASP Top 10:2025 is the eighth edition of OWASP’s widely used awareness document for developers and application security professionals. It highlights ten of the most critical web application security risks, drawing on contributed testing data and community input. It is intended to raise awareness and guide security improvement, rather than serve as a complete application security standard or a checklist that guarantees an application is secure.
The 2025 edition contains these ten categories:
A01: Broken Access Control
A02: Security Misconfiguration
A03: Software Supply Chain Failures
A04: Cryptographic Failures
A05: Injection
A06: Insecure Design
A07: Authentication Failures
A08: Software or Data Integrity Failures
A09: Security Logging & Alerting Failures
A10: Mishandling of Exceptional Conditions
The list reflects both observed weaknesses and risks highlighted by the security community. OWASP’s methodology deliberately considers more than what can be measured through automated testing data alone, because some important risks are difficult to detect or consistently measure at scale.
For security teams, that distinction matters. The Top 10 can help organize a security program, but it shouldn’t be treated as proof that a tool or process covers every weakness within a category. The next step is to translate the categories into specific controls, test cases, and review activities that fit your application.
OWASP Top 10 2025: What’s changed from 2021?
The 2025 edition includes two new categories, one consolidation, and changes to the scope and ranking of existing categories. The most notable shifts are the broader focus on software supply chain failures, the introduction of mishandling of exceptional conditions, and the move of server-side request forgery (SSRF) into broken access control.
Here’s what changed and what each category means for your security testing strategy.
A01: Broken access control
2021 position: #1 → 2025 position: #1
Broken access control retains its position as the top risk. It covers failures that let users act outside their intended permissions, potentially exposing, modifying, or destroying information or performing unauthorized actions. In 2025, SSRF is included within this category rather than appearing as its own category, as it did in 2021.
For example, an application might let a standard user access another user’s account by changing an identifier in a request. Another weakness might allow an authenticated user to access an internal resource through an improperly controlled server-side request.
What to check: Test authorization across user roles, resources, and sensitive functions. Check whether direct requests can bypass access restrictions, and include SSRF testing where relevant to your application’s architecture.
A02: Security misconfiguration
2021 position: #5 → 2025 position: #2
Security Misconfiguration moves up three places, reflecting its prominence in the 2025 assessment. It covers insecure settings across application components, frameworks, servers, cloud services, and other parts of the application stack. Examples include unnecessary enabled features, default credentials, exposed debugging functionality, unsafe permissions, and missing or incorrectly configured security headers.
Misconfigurations can be introduced through deployment changes, insecure defaults, or differences between development, testing, and production environments.
What to check: Review application and server configurations, security headers, exposed services, default accounts, permissions, and error handling. Combine automated checks with configuration reviews because not every deployment or infrastructure setting can be assessed through an application penetration test alone
A03: Software supply chain failures
2021 predecessor: A06 Vulnerable and Outdated Components
This is one of the most significant changes in the 2025 edition. The earlier category focused on vulnerable and outdated components. The new Software Supply Chain Failures category expands the scope to risks across the software ecosystem, including dependencies, build systems, development tools, and software distribution.
The risk isn’t limited to a library with a known vulnerability. A compromised package, an untrusted dependency, or a tampered build pipeline can introduce malicious code into an otherwise legitimate application.
What to check: Maintain an inventory of software components and their dependencies, review component provenance and updates, and assess access controls and integrity protections across source repositories, CI/CD pipelines, and artifact repositories. Use software composition analysis (SCA) and supply chain security controls alongside application testing.
A04: Cryptographic failures
2021 position: #2 → 2025 position: #4
Cryptographic Failures remains a distinct category, but moves down two places. It covers weaknesses in how applications protect sensitive information through cryptography. These can include inadequate encryption, weak cryptographic algorithms, improper key management, or failures to protect sensitive data appropriately.
A system might, for example, transmit sensitive information over an insecure connection or store credentials using an unsuitable hashing approach.
What to check: Review how sensitive data is stored and transmitted, whether appropriate cryptographic mechanisms are used, and how keys, certificates, passwords, and secrets are managed. Use configuration reviews and code-level checks where needed; runtime testing alone may not establish whether cryptographic implementation and key management are sound.
A05: Injection
2021 position: #3 → 2025 position: #5
Injection moves down two places but remains a major application security risk. It occurs when untrusted input is interpreted as part of a command or query. Examples include SQL injection, command injection, and cross-site scripting (XSS). OWASP’s 2025 category includes multiple injection-related weaknesses and emphasizes the importance of testing inputs across application entry points.
For instance, an application that builds database queries unsafely from user input may allow an attacker to manipulate the query and access information they shouldn’t be able to retrieve.
What to check: Test parameters, headers, cookies, request bodies, and other relevant inputs for injection flaws. Combine dynamic testing with secure coding practices, parameterized queries, input validation, and code analysis where appropriate.
The category’s lower ranking does not mean injection can be deprioritized in your own application. Your actual exposure depends on the technologies and functionality you use.
A06: Insecure design
2021 position: #4 → 2025 position: #6
Insecure Design moves down two places. Introduced in 2021, this category focuses on weaknesses in an application’s architecture, requirements, and business logic and not simply coding mistakes. The 2025 edition continues to emphasize threat modeling, secure design patterns, and defining security requirements early in development.
Consider an application that allows a sensitive transaction to be repeated or completed in an unintended sequence because the workflow never accounted for that possibility. Even if each individual endpoint is implemented correctly, the overall design may still allow abuse.
What to check: Review threat models, security requirements, trust boundaries, and critical business workflows. Use misuse cases and manual testing to examine how features behave when actions occur in unexpected sequences or under conditions the original design didn’t anticipate.
A07: Authentication failures
2021 name: Identification and authentication failures → 2025 name: Authentication failures
The category remains at #7, with a name change that better reflects its scope. It covers weaknesses that allow an application to recognize an invalid or incorrect identity as legitimate. Examples include weak authentication controls, credential stuffing, ineffective session management, and problems with credential recovery.
For example, an application might fail to invalidate a session after logout, allowing a previously issued session token to remain usable.
What to check: Test login and recovery flows, session creation and invalidation, token validation, and protections against automated authentication attacks. Where applicable, verify that multi-factor authentication and other identity controls are implemented and enforced as intended. Testing should include authenticated application areas, not just endpoints accessible before login.
A08: Software or data integrity failures
2021 name: Software and data integrity failures → 2025 name: Software or data integrity failures
This category remains at #8, with a small wording change. Its focus is on failures to verify the integrity and trustworthiness of software, code, and data. Examples include accepting untrusted serialized data, using components from untrusted sources, or applying software updates without verifying their integrity.
The distinction from Software Supply Chain Failures is important. A03 looks at broader failures across the software supply chain, while A08 focuses on integrity and trust boundaries, for example, whether an application verifies that an update or artifact has not been tampered with.
What to check: Review signature and integrity verification, trust in external components, deserialization of untrusted data, and the controls protecting code and artifacts as they move through development and deployment.
Depending on the issue, you may need code review, pipeline security checks, and artifact verification in addition to runtime application testing.
A09: Security logging and alerting failures
2021 name: Security logging and monitoring failures → 2025 name: Security logging & alerting failures
The category remains at #9, but its updated name emphasizes that logging must lead to meaningful alerting and response. Recording an event is not enough if suspicious activity goes unnoticed or nobody acts on the alert.
For example, an application might record failed login attempts but have no alerting rules for a sustained credential-stuffing attack. The records exist, but they may not trigger a timely response.
What to check: Verify that important security events are logged, logs are protected from tampering, suspicious activity is monitored, and alerts reach the appropriate responders. Review alert thresholds and response procedures as well as the quality and completeness of the logs.
This category often requires operational testing and review of logging and monitoring systems. A penetration test can help assess whether certain actions generate expected events or alerts, but it cannot by itself establish that the entire monitoring and incident response process is effective.
A10: Mishandling of exceptional conditions
New in 2025
Mishandling of Exceptional Conditions is a new category in the 2025 edition. It groups weaknesses involving improper error handling, logical errors, failure to handle unexpected conditions, and systems that fail open instead of failing securely. OWASP maps 24 CWEs to this category.
Imagine an application that encounters an error while checking a user’s permissions. If the error causes the application to allow the request rather than deny it, an exceptional condition could become an access control vulnerability.
What to check: Test how the application behaves when required parameters are missing, dependencies fail, requests contain unexpected values, or operations encounter errors. Verify that sensitive operations fail securely, partial failures don’t bypass controls, and error responses don’t disclose sensitive implementation details.
This category is a reminder to test not only the expected path through an application but also what happens when something goes wrong.
How to identify gaps in your OWASP Top 10 coverage
Knowing the ten categories is a starting point. The harder question is whether your existing security program can actually identify the weaknesses within them.
A tool may advertise OWASP Top 10 coverage without testing every weakness mapped to each category. Another tool might test application behavior effectively but leave dependencies, build pipelines, secure design, or incident response outside its scope.
To assess your coverage, map the risks to specific testing activities and evidence, not just product names or checkboxes on a dashboard.
Map existing security tests to the 2025 categories
Start by reviewing the security tools and processes already in place. These might include dynamic application security testing (DAST), static application security testing (SAST), software composition analysis (SCA), infrastructure and configuration checks, manual penetration testing, and secure design reviews.
A simple mapping of the issues with each vulnerability can help you get started. For every category, document:
Relevant risks: Which weaknesses in the category apply to your application?
Existing tests: Which tools, test cases, or reviews assess those weaknesses?
Evidence: When was the test last performed, and what were the results?
Limitations: Which weaknesses remain untested or need a different testing method?
Identify risks that automated tools may not detect
Automation makes security testing repeatable, but different tools examine different parts of an application. Some weaknesses are difficult to identify without understanding business requirements, reviewing source code, or examining systems outside the running application.
Pay particular attention to these areas:
Software supply chain: Application testing may identify a vulnerable component’s effect at runtime, but dependency inventories, package provenance, and CI/CD security require their own checks.
Insecure design: A scanner may find exploitable behavior, but assessing whether the architecture and business rules provide the right protections often requires threat modeling and design review.
Cryptography and integrity: Runtime tests can assess some observable weaknesses, but key management, code signing, and artifact integrity may require configuration, code, or pipeline reviews.
Logging and alerting: A test might trigger an event, but confirming that it was logged, detected, escalated, and handled requires examining the monitoring and response process.
Exceptional conditions: Automated tests can exercise error cases, but complex state transitions and business logic may require carefully designed manual tests.
OWASP itself notes that the Top 10 methodology includes community input because some important risks are not adequately represented by data from large-scale testing alone.
The goal isn’t to replace automation with manual testing. It’s to understand where automation is effective and add other methods where the risk demands them.
Validate findings through manual testing and secure design reviews
Once you’ve mapped your tools to the categories, validate whether the tests provide meaningful coverage.
Manual penetration testing can help explore multi-step attack paths, test authorization boundaries, and examine business logic that may not be fully covered by predefined checks.
Secure design reviews and threat modeling help identify missing controls before they become implementation flaws.
For example, an automated test might confirm that an endpoint requires authentication. A deeper assessment should also check whether the authenticated user has permission to access the specific resource, whether related endpoints enforce the same restriction, and whether the workflow can be abused through an unexpected sequence of actions.
For supply chain, cryptographic, and logging risks, the appropriate validation may involve code review, configuration inspection, pipeline checks, or operational exercises rather than penetration testing alone.
Keep evidence of what was tested, which conditions were covered, what limitations remain, and whether additional assessment is needed. That evidence is far more useful than a general claim that your application is OWASP Top 10 compliant.
Prioritize remediation and retest fixes
Not every gap needs the same response or urgency. Prioritize based on factors such as exploitability, potential impact, exposed functionality, data sensitivity, and the application’s business context.
For each confirmed issue, record the affected component or workflow, supporting evidence, severity, remediation owner, and target date. Then retest the fix to confirm that the original weakness is resolved and that related functionality still behaves securely.
A useful coverage review should also track risks that have not yet been tested. Marking a category as covered when no relevant test has been performed can create a false sense of security.
Repeat the review when the application architecture, dependencies, authentication mechanisms, or deployment process changes. This keeps the coverage map aligned with the application you’re actually running.
How Beagle Security helps identify application vulnerabilities
Identifying OWASP Top 10 coverage gaps requires more than knowing which categories a tool supports. Teams need to test their applications, investigate findings, and understand which risks require additional controls or assessment methods.
Beagle Security provides agentic AI penetration testing for web applications and APIs, helping teams identify exploitable weaknesses through simulated attacks. Its capabilities include authenticated testing, REST and GraphQL API testing, business logic recording, and reporting mapped to security standards.
Here’s how Beagle Security can contribute to an OWASP Top 10 coverage strategy:
Test application behavior: Agentic AI penetration testing can help identify exploitable weaknesses in running applications, including relevant access control, authentication, and injection issues.
Assess authenticated functionality: Test areas behind login flows and configure role-based API authorization testing to examine access restrictions and privileged functionality.
Investigate business logic: Record complex login flows and points of interest to help test critical application workflows and uncover issues that basic endpoint checks may miss.
Review findings and remediation: Use vulnerability details, proof of exploit, and contextual recommendations to help teams investigate findings and decide what to fix.
Track security testing over time: Schedule tests and use occurrence timelines to see whether findings are new, fixed, unfixed, or reopened.
Support reporting and workflows: Generate reports mapped to OWASP and other supported security standards, and integrate testing into CI/CD and supported development workflows.
These capabilities can help teams assess the application-level risks relevant to several OWASP categories. However, Beagle Security should be one part of the coverage strategy, not a claim of complete coverage of all ten categories. Software supply chain security, secure design, cryptographic implementation, and operational logging and alerting may require additional tools, reviews, or processes.
The practical approach is to map Beagle Security’s test results to the risks it can help assess, then use the same coverage review to identify where other methods are needed.
Explore Beagle Security’s application security testing features to see how agentic AI penetration testing can fit into your broader security program.
Conclusion
The OWASP Top 10 2025 brings meaningful changes to how application security risks are grouped and prioritized. Software supply chain failures expands the focus beyond vulnerable components, mishandling of exceptional conditions introduces a distinct category for unsafe failure behavior, and SSRF is now included under broken access control.
For security teams, updating a document or switching to a tool that advertises 2025 coverage isn’t enough. The important step is to establish whether your testing methods can identify the weaknesses relevant to your applications and where gaps remain.
Map the ten categories to specific tests, validate the limits of automated tools, add manual testing and secure design reviews where needed, and retest fixes to verify the results. Use agentic AI penetration testing as a repeatable part of that process, alongside the code, dependency, configuration, and operational checks required by your application.
The goal isn’t simply to say your application is covered by the OWASP Top 10 2025. It’s to know what you’ve tested, what you haven’t, and what you’re doing about the difference.
FAQs
What is the OWASP Top 10 2025?
The OWASP Top 10 2025 is the eighth edition of OWASP’s awareness document highlighting ten critical web application security risks. It updates the categories and their rankings based on contributed testing data and community input, helping development and security teams prioritize application security improvements.
Is the OWASP Top 10 a security testing standard?
The OWASP Top 10 is an awareness document, not a comprehensive testing standard. It helps teams understand important application security risks, but it doesn’t define every test needed to assess an application. Teams may use more detailed resources, such as the OWASP Application Security Verification Standard (ASVS), to define and verify security requirements.
How do you identify gaps in OWASP Top 10 coverage?
Start by mapping each category to the security tests and processes your organization uses. Check which weaknesses those tests cover, review evidence from recent assessments, identify untested risks, and validate important findings through manual testing or specialist reviews. Prioritize the gaps based on risk, assign remediation owners, and retest fixes.
How does Beagle Security help with OWASP Top 10 2025?
Beagle Security provides automated penetration testing for web applications and APIs, with capabilities including authenticated testing, REST and GraphQL API testing, business logic recording, and OWASP-mapped reporting. It can help teams identify and investigate application vulnerabilities, while complementary tools and reviews address risks outside the scope of automated penetration testing
![Top ZAP alternatives and competitors [October 2026]](/blog/images/top-zap-alternatives-cover.webp "Top ZAP alternatives and competitors [October 2026]")
![Best API security solutions for enterprises [2026]](/blog/images/blog-banner-two-cover.webp "Best API security solutions for enterprises [2026]")
![Top 10 penetration testing companies [2026]](/blog/images/top-penetration-testing-companies-cover.webp "Top 10 penetration testing companies [2026]")
