OWASP Top 10 2025: Risks, Testing, and Fixes

The OWASP Top 10 2025 gives product, engineering, and security teams a current way to discuss the most critical web application security risks. The list is useful, but it is not a complete assessment. The practical question is what to test first, what evidence to collect, and how to move from a finding to a verified fix.

Explore Penti's OWASP Top 10 penetration testing resource for attacker-focused testing, prioritized findings, and expert validation.

What changed in the OWASP Top 10 2025?

OWASP describes the Top 10 as an awareness document for developers and web application security. The 2025 release updates the risk categories to reflect modern software delivery, dependency chains, and recurring root causes. OWASP also states that the list is not complete, so teams should use it as a starting point rather than a substitute for threat modeling, testing, monitoring, or a broader application security program.

The most important changes affect how teams scope their work:

• Broken Access Control remains A01. Server-Side Request Forgery, or SSRF, is included within this category in the 2025 release.
• Security Misconfiguration moves to A02. Configuration choices now deserve earlier attention across applications, services, identity providers, cloud resources, and deployment environments.
• Software Supply Chain Failures is A03. This expands the former vulnerable and outdated components focus to include dependencies, build systems, and distribution infrastructure.
• Root causes matter more than isolated symptoms. A recurring error, unsafe default, missing design decision, or broken release control may create several visible weaknesses.

Read the official OWASP Top 10 2025 introduction for the release context and category changes. When translating those changes into work, keep the question tied to your own attack surface: which identities, requests, data stores, third-party services, and release paths could an attacker influence?

OWASP Top 10 2025 risks and testing priorities

The table below is a planning aid, not a replacement for a test plan. Each row connects the category to a practical question and an initial remediation direction. The right depth depends on the application's architecture, data, roles, exposure, and business-critical workflows.

A01: Broken Access Control

Access control is about what an authenticated or unauthenticated actor is allowed to do. Testing should begin with high-value objects and actions, not only with the login screen. Create test identities for meaningful roles, organizations, tenants, support users, and administrators. Then compare the same request across identities and object identifiers.

Testing questions

• Can a normal user read, update, export, or delete another user's object?
• Can a lower-privilege role call an administrative endpoint directly?
• Are authorization decisions enforced on the server for every API version and alternate route?
• Does an SSRF-style server request cross a trust boundary and reach a resource the caller should not control?

Capture the full request, identity, object, response, and business effect. A useful fix is usually centralized authorization with explicit deny tests, not a front-end control that hides a button. Penti's web application security testing guide provides additional context on mapping authenticated surfaces and trust boundaries.

A02: Security Misconfiguration

Misconfiguration can sit in application settings, cloud services, identity providers, API gateways, headers, storage, deployment variables, or administrative tools. A configuration review should compare production behavior with secure defaults and approved exceptions. It should also account for forgotten hosts, preview deployments, debug modes, verbose errors, exposed administration, and inconsistent settings between environments.

Testing questions

• Are debug features, stack traces, directory listings, test routes, or default accounts exposed?
• Do cross-origin, cookie, content security, transport, and cache settings match the application's trust model?
• Can a public cloud resource, service endpoint, or deployment control be reached without the intended restriction?

Record the effective setting and the environment where it was observed. Remediation is stronger when secure configuration is versioned, reviewed, checked in delivery, and monitored for drift. Do not treat a scanner result as a complete diagnosis without confirming how the configuration changes real application behavior.

A03: Software Supply Chain Failures

The 2025 category goes beyond a list of outdated libraries. It asks whether the software supply chain can be trusted from dependency selection through build, release, update, and distribution. That includes direct and transitive dependencies, package sources, build runners, source control, artifact storage, signing, and update channels.

Testing questions

• Can an unreviewed dependency or build action enter a release?
• Are artifacts traceable to source and reproducible enough to investigate?
• Are package and update sources authenticated, reviewed, and protected from substitution?
• Can a compromised token or build runner change the artifact delivered to customers?

Start with an inventory of components and build relationships. Then protect the highest-impact paths with least privilege, review, provenance records, dependency controls, and alerting. The goal is not to promise that every dependency is risk-free. The goal is to make unauthorized change harder to introduce and easier to detect.

A04: Cryptographic Failures

Cryptographic failures occur when sensitive data receives inadequate protection or when cryptographic controls are used incorrectly. Testing should follow the data. Identify sensitive fields, where they are transmitted, where they are stored, which keys protect them, and which services can decrypt or transform them.

Testing questions

• Is sensitive data sent over the intended transport and protected by appropriate protocol settings?
• Are passwords, tokens, secrets, and personal data stored and handled according to their sensitivity?
• Are keys separated by purpose, access-controlled, rotated where appropriate, and kept out of logs and source?
• Can an attacker force a downgrade, bypass a verification step, or obtain data through an alternate endpoint?

Remediation should use approved cryptographic libraries and patterns instead of custom algorithms. Review key lifecycle and data minimization alongside the code. A cryptographic finding is not fixed merely because a single field is encrypted if a backup, log, cache, export, or older API still exposes the same data.

Need a broader view of changing application risk? See how continuous security testing can help SaaS teams find and verify issues as their attack surface changes.

A05: Injection

Injection happens when untrusted data changes the meaning of an interpreter, query, command, template, or other execution context. The safe testing objective is to prove whether input crosses that boundary and affects behavior, while avoiding unnecessary exploit detail in a general awareness guide.

Testing questions

• Which inputs reach database queries, operating-system commands, templates, search engines, or expression evaluators?
• Are parameterized interfaces or safe APIs used consistently across legacy and new code?
• Do validation and output encoding match the context where data is used?
• Do error responses disclose the interpreter, query, or internal state?

Prioritize the paths that handle privileged data, administrative actions, file access, or financial outcomes. Remediation should combine contextual defenses with safe APIs, narrow validation, least privilege, and regression tests. Do not use this article as a standalone SQL injection tutorial. The purpose is to help teams decide where to test and how to close the underlying trust-boundary failure.

A06: Insecure Design

Insecure design is a design-level weakness, not just a missing line of code. A workflow may be implemented exactly as specified and still allow abuse because the specification omitted a threat, business rule, rate limit, separation of duties, or safe recovery path.

Testing questions

• What happens when a user repeats, reorders, races, or abandons a high-impact workflow?
• Can a single account approve, change, and execute a sensitive action without an independent control?
• What abuse cases were considered for invitations, resets, uploads, billing, exports, and integrations?
• Does the system fail safely when a dependency, identity provider, or fraud control is unavailable?

Threat modeling and abuse-case review belong before implementation, but testing can still expose design gaps in production-like flows. Record the intended security property, the abuse path, and the business outcome. Then update the requirement, control, test, and ownership model together.

A07: Authentication Failures

Authentication is more than password strength. Test the complete identity lifecycle, including enrollment, login, multifactor checks, sessions, token refresh, logout, recovery, account changes, and administrative support paths. A strong primary login flow can be undermined by a weaker recovery or invitation path.

Testing questions

• Can an attacker enumerate accounts, bypass a factor, reuse a token, or change recovery details?
• Are session and token lifetimes appropriate for the risk of the action?
• Are high-risk changes reauthenticated and tied to the correct account and device context?
• Do rate limits, lockout controls, and alerts work without creating an easy denial-of-service path?

Prioritize privileged accounts and actions that change identity, authorization, or recovery. Remediation should preserve usability while protecting the full lifecycle. Test with safe accounts and document state transitions so the team can reproduce both the failure and the fix.

A08: Software or Data Integrity Failures

This category focuses on whether software and data can be trusted when they cross boundaries. Examples include update mechanisms, CI/CD artifacts, deserialization paths, signed content, webhooks, and integrations that make a trust decision before validating origin or integrity.

Testing questions

• What source, signature, digest, or authorization does the system trust before applying an update?
• Can a webhook or serialized object alter a trusted state without validation?
• Are build artifacts, configuration bundles, and release packages protected from unauthorized change?

Map each trust decision and test the negative path. Remediation may include signature verification, authenticated webhooks, strict schema handling, protected release controls, and separation between untrusted data and executable behavior. Capture the exact trust boundary so a fix closes the path rather than adding a cosmetic check.

A09: Security Logging and Alerting Failures

Logging is useful only when the right security event is recorded with enough context, protected from tampering, delivered to the people or systems that need it, and connected to an action. Testing should follow a high-impact attack from trigger to detection and response.

Testing questions

• Are privileged changes, failed authentication, authorization failures, exports, and suspicious workflow events recorded?
• Do logs include identity, time, source, request or transaction context, and outcome without exposing secrets?
• Does an alert reach the responsible team with a useful severity and response path?
• Can an attacker disable, flood, alter, or bypass the logging path?

Start with a small set of high-value events and test them end to end. Remediation is not a promise that every event will generate an alert. It is a measurable control: the organization knows what signal it expects, who owns it, and how the signal will be validated.

A10: Mishandling of Exceptional Conditions

Applications rarely operate only on the happy path. Timeouts, partial failures, malformed data, depleted resources, race conditions, dependency outages, and unexpected state transitions can produce a security failure even when normal requests are well protected.

Testing questions

• What state remains after a transaction, authorization check, or payment step times out?
• Do retries duplicate an action, bypass a control, or expose inconsistent data?
• Do errors reveal sensitive information or return a permissive fallback?
• Can resource exhaustion change who receives service or which controls run?

Test controlled failure conditions in a safe environment and record the before state, trigger, resulting state, and recovery. Design explicit failure states, bounded retries, idempotency, resource limits, and secure defaults. Retest the complete workflow, not only the error handler that first drew attention.

How should product teams prioritize remediation?

The OWASP categories are a useful map, but remediation order should reflect exposure and impact. A practical sequence is:

1. Inventory the attack surface. List public applications, APIs, identities, administrative paths, integrations, data stores, build systems, and high-value workflows.
2. Identify trust boundaries. Mark where requests, data, code, identities, and configuration cross between actors or systems.
3. Test the highest-consequence paths first. Prioritize privileged actions, tenant boundaries, sensitive data, release controls, account recovery, and workflows that change money or access.
4. Capture reproducible evidence. Record the tested identity, request, state, response, affected asset, business impact, and conditions needed to reproduce the issue.
5. Fix the root cause. Prefer a shared control, secure default, design requirement, or protected workflow over a one-off exception.
6. Retest and track residual risk. Verify the exact path, confirm that related variants are covered, and document what remains outside scope.

NIST's Secure Software Development Framework is a useful companion for integrating secure practices into an SDLC. The OWASP Web Security Testing Guide can also help teams organize hands-on testing. Neither source removes the need to adapt the work to the application's actual architecture and business rules.

For teams that need recurring coverage, combine application testing with vulnerability management, change review, logging, and retesting. Penti's manual and agentic penetration testing comparison explains why automated discovery and human validation serve different parts of the testing problem. Penti also describes its AI penetration testing capability as part of a broader security workflow. Use those pages for service context, not as a substitute for a scoped assessment.

Want to turn OWASP priorities into a scoped assessment? Review Penti's OWASP Top 10 penetration testing resource and choose the next step that fits your application's attack surface. An assessment can identify and validate findings, but it does not by itself create a compliance certification or guarantee that an application has no vulnerabilities.

OWASP Top 10 2025 FAQ

Is the OWASP Top 10 2025 a complete security checklist?

No. OWASP presents it as an awareness document and says it is not a complete list of application security risks. Use it to establish shared language and prioritize questions, then add threat modeling, architecture review, testing, monitoring, supply chain controls, and incident readiness that match your environment.

What is the biggest testing mistake teams make?

A common mistake is testing only unauthenticated pages or running a scanner without validating business impact. Important weaknesses often involve roles, tenant boundaries, recovery flows, APIs, integrations, configuration, or multi-step business actions. Test the paths that can change access, data, money, or trust.

Does OWASP Top 10 coverage prove compliance?

No. Coverage of OWASP categories is not a compliance certification or guarantee. Compliance requirements depend on the applicable framework, scope, control evidence, assessment method, and organization. Treat OWASP testing as one input to a broader security and assurance program.

How often should teams test against the OWASP Top 10?

Use a cadence that matches how quickly the application and attack surface change. Test after material architecture, identity, integration, or release changes, and use recurring checks for continuously changing surfaces. The important control is not a calendar label alone. It is finding issues, fixing them, and verifying the fix with evidence.

Final takeaway

The OWASP Top 10 2025 is most useful when it changes engineering decisions. Map each category to real assets and workflows, test authorization and trust boundaries, capture evidence that another person can reproduce, and prioritize fixes by exposure and consequence. Keep the list in proportion: it is a strong starting point for application security, not a complete assessment, a certification, or a promise of zero risk.