The OWASP Top 10 is one of the most recognizable application security resources, but it is often used too narrowly. It is not a promise of complete coverage, a substitute for secure design, or a checklist that one scanner can finish. It is an awareness baseline that helps teams understand recurring classes of web application risk and connect them to concrete engineering decisions.
What Is the OWASP Top 10?
The OWASP Top 10:2025 is the current released edition of OWASP’s awareness document for critical web application security risks. It groups many individual weaknesses into ten broad categories so that developers, security engineers, product owners, architects, and executives can discuss risk using a shared vocabulary.
The categories are not ten single vulnerabilities. Each one contains multiple Common Weakness Enumerations and can appear in different technologies, architectures, and business processes. Broken access control, for example, may involve an administrative function, a tenant boundary, a document identifier, a GraphQL resolver, or a service-to-service permission.
What Changed in the OWASP Top 10:2025?
The 2025 edition reflects a broader view of modern application risk. It analyzes weaknesses at category level, emphasizes root causes over symptoms, and accounts for cloud services, build systems, dependency chains, APIs, distributed applications, and operational failure conditions.
| 2025 development | Why it matters | Practical response |
|---|---|---|
| Software Supply Chain Failures is A03 | The risk now covers more than known vulnerable libraries | Govern source, build, artifact, dependency, and deployment trust |
| Security Misconfiguration moved to A02 | Highly configurable cloud and application stacks increase exposure | Use hardened baselines and continuous configuration review |
| Mishandling of Exceptional Conditions is new | Systems may fail open or behave unsafely during abnormal states | Test timeouts, partial failures, fallbacks, and error paths |
| Root causes receive greater emphasis | Fixing the cause prevents more than one visible symptom | Connect findings to design, process, and control ownership |
The list is data-informed rather than purely data-driven. OWASP combines contributed testing data with community input because some important weaknesses—especially design and operational issues—are difficult to detect reliably with automated tools alone.
OWASP Top 10 Vulnerabilities With Practical Examples
The examples below are intentionally defensive. They explain the risk pattern, business impact, and prevention approach without providing harmful exploitation instructions. Any testing should be authorized, scoped, and performed with controlled accounts and synthetic data.
A01:2025 Broken Access Control
What it means: the application does not consistently enforce who may view a record, change an object, invoke a function, cross a tenant boundary, or perform an administrative action.
Safe example: A customer portal receives a request for account 7721. The server verifies that the session is valid but does not verify that account 7721 belongs to the authenticated customer.
Why it matters: one missing authorization decision can expose private records, enable unauthorized changes, or give a normal user access to privileged functions.
Prevention: deny by default, enforce authorization on the server for every object and action, centralize policy where practical, verify tenant context, test horizontal and vertical privilege boundaries, and log denied and unusual access attempts without exposing sensitive values.
API connection: review BOLA and IDOR API security for object-level authorization patterns.
A02:2025 Security Misconfiguration
What it means: an application, API gateway, cloud service, server, container, framework, identity platform, or supporting component is deployed with unsafe settings.
Safe example: A production API returns a detailed stack trace that includes internal service names, file paths, and framework information.
Why it matters: excessive error detail, exposed management interfaces, permissive cross-origin settings, unnecessary services, public storage, weak headers, and inconsistent environment settings can create avoidable attack paths.
Prevention: use version-controlled hardening baselines, remove defaults and sample services, separate development from production configuration, restrict management paths, continuously assess cloud and container settings, and verify effective configuration after deployment.
A03:2025 Software Supply Chain Failures
What it means: trust breaks somewhere in the software supply chain—source repositories, dependencies, package registries, build systems, CI/CD actions, container images, artifacts, update channels, or third-party services.
Safe example: A deployment pipeline promotes an artifact from an unverified build without checking its origin, integrity, dependency inventory, or approval state.
Why it matters: secure application code can still inherit risk from compromised tooling, abandoned dependencies, malicious packages, untrusted build steps, or tampered artifacts.
Prevention: maintain a current component inventory and software bill of materials where appropriate, approve dependency sources, protect developer and CI identities, isolate build systems, verify artifacts, pin and review versions, monitor emerging component risk, and define an urgent update process.
A04:2025 Cryptographic Failures
What it means: sensitive data is not adequately protected in transit, at rest, in backups, in caches, in logs, or during application processing.
Safe example: An application masks payment data in the user interface but writes the complete value into a debug log retained by a broader operations team.
Why it matters: weak protocols, poor key management, hard-coded secrets, unnecessary data collection, and sensitive logging can turn an operational issue into a data breach.
Prevention: classify data, minimize collection and retention, use current approved cryptography, protect keys separately from protected data, rotate secrets, enforce transport security, avoid sensitive values in telemetry, and verify protection across replicas, exports, analytics, and backups.
A05:2025 Injection
What it means: untrusted input changes the meaning of a query, command, template, expression, or interpreter instruction instead of remaining ordinary data.
Safe example: A search value is inserted into a database statement through string concatenation rather than a parameterized query.
Why it matters: injection can affect SQL and NoSQL databases, operating-system commands, directories, templates, expression engines, and other interpreters.
Prevention: use parameterized interfaces, avoid dynamic command construction, validate input by expected type and structure, constrain server-side operations, encode output for its destination, use least-privileged service identities, and test every interpreter boundary.
A06:2025 Insecure Design
What it means: the application lacks necessary security controls at the architecture or business-rule level. The implementation may work exactly as designed, but the design itself allows harmful behavior.
Safe example: A refund workflow permits unlimited repeated requests because the design has no transaction-state check, approval threshold, or abuse limit.
Why it matters: scanners cannot fully discover missing business rules, unsafe trust assumptions, inadequate separation of duties, or abuse paths that use valid application features.
Prevention: perform threat modeling, document abuse cases, define security requirements before implementation, use secure reference patterns, protect sensitive business flows, introduce appropriate approval and transaction controls, and review design changes when the business process changes.
A07:2025 Authentication Failures
What it means: the application cannot reliably establish or maintain the identity of a user, service, device, or client.
Safe example: A resource server accepts a token without confirming the expected issuer, audience, lifetime, token type, and signature validation requirements.
Why it matters: weak recovery flows, poor session handling, missing replay protections, credential stuffing exposure, inconsistent token validation, and long-lived credentials can allow identity compromise.
Prevention: use established identity protocols and libraries, validate tokens completely, protect login and recovery flows, support phishing-resistant authentication where appropriate, rotate and revoke credentials, secure sessions, rate-limit sensitive identity actions, and monitor anomalies.
Related guide: see OAuth API security mistakes for token and authorization-flow guidance.
A08:2025 Software or Data Integrity Failures
What it means: the system trusts software, updates, serialized objects, configuration, data, or workflow outputs without establishing their integrity and approved origin.
Safe example: An application automatically installs an update from a channel that is not restricted, authenticated, or checked for a valid signature.
Why it matters: tampered updates, unsafe deserialization, unreviewed automation, untrusted plugins, and compromised pipeline outputs can alter application behavior.
Prevention: use signed and verifiable artifacts, restrict update channels, separate duties in deployment workflows, validate data formats and object types, avoid unsafe native deserialization, review high-impact changes, and protect integrity metadata and keys.
A09:2025 Security Logging and Alerting Failures
What it means: important security events are missing, lack context, are retained incorrectly, are not monitored, or do not lead to a timely investigation and response.
Safe example: A sensitive export endpoint records only “request failed.” The event omits the user, client, endpoint, object scope, decision, correlation identifier, and response outcome.
Why it matters: teams cannot reconstruct events, distinguish normal errors from abuse, measure control effectiveness, or prove that alerts reach an owner.
Prevention: define security-relevant events, log identity and decision context, use consistent timestamps and correlation IDs, protect log integrity, centralize monitoring, avoid secrets and personal data in telemetry, test alert routing, and rehearse investigations.
A10:2025 Mishandling of Exceptional Conditions
What it means: the application behaves unsafely during errors, timeouts, invalid states, partial failures, resource exhaustion, unexpected input, or dependency outages.
Safe example: When an authorization dependency times out, the application uses a fallback path that completes the sensitive action instead of denying it safely.
Why it matters: systems that are secure during normal operation may fail open, disclose internal detail, lose transaction consistency, skip validation, or create repeated side effects under abnormal conditions.
Prevention: define secure failure behavior, make sensitive operations fail closed, use idempotency where needed, handle partial transactions, set bounded retries and timeouts, validate state transitions, test dependency failure, and monitor unusual error combinations.
OWASP Top 10 vs OWASP API Security Top 10
The web application Top 10 and the OWASP API Security Top 10:2023 overlap, but they answer different questions. The web list covers broad application risk. The API list focuses on how APIs expose identities, objects, properties, functions, resources, business flows, inventories, and third-party dependencies.
| Web Top 10:2025 category | Common API expression | Useful API-specific lens |
|---|---|---|
| Broken Access Control | Cross-user records, tenant escapes, admin functions | BOLA, property-level authorization, function-level authorization |
| Security Misconfiguration | Exposed gateways, debug routes, permissive CORS, unsafe defaults | API8 Security Misconfiguration |
| Insecure Design | Automated abuse of purchasing, booking, signup, or recovery flows | API6 Sensitive Business Flows |
| Authentication Failures | Weak token validation, recovery, client identity, or session controls | API2 Broken Authentication |
| Logging and Alerting Failures | No operation, identity, object, or response context | Behavior-aware API telemetry and investigation evidence |
| Supply Chain and Integrity Failures | Unsafe partner responses or untrusted external APIs | API10 Unsafe Consumption of APIs |
API programs also need continuous inventory. An application may pass a review while undocumented, deprecated, or externally exposed APIs remain outside the assessment scope. See shadow, zombie, and ghost APIs for a practical inventory workflow.
How to Use OWASP Examples Safely and Effectively
Examples should help teams recognize a control failure, not encourage uncontrolled testing. A useful example includes the protected asset, expected policy, observed behavior, business impact, owner, and evidence required to confirm remediation.
Use controlled identities
Create approved test users with known roles, tenants, and permissions. Never use real customer accounts for authorization experiments.
Use synthetic records
Seed non-sensitive test data so expected and denied outcomes can be verified without exposing personal or production information.
Define stop conditions
Stop when behavior affects availability, leaves the approved scope, changes real data, or produces unexpected downstream effects.
Capture minimal evidence
Record the endpoint, identity, policy, decision, status, and redacted outcome. Avoid copying credentials or sensitive payloads into tickets.
How to Test and Verify OWASP Top 10 Controls
No single tool can verify every category. A balanced program combines design review, implementation testing, operational evidence, and human judgment.
| Verification method | Best suited for | Important limitation |
|---|---|---|
| Threat modeling and abuse cases | Insecure design, trust boundaries, sensitive flows | Requires current architecture and business knowledge |
| Static and code review | Injection, unsafe APIs, missing checks, insecure patterns | May not reveal effective runtime policy or deployment state |
| Software composition analysis | Known component, license, and dependency risk | Does not prove build provenance or runtime exposure |
| Configuration assessment | Cloud, container, gateway, identity, and server settings | Must verify the effective production configuration |
| Dynamic and manual testing | Authorization, session, input, error, and business logic | Requires authorization, scope, and safe test data |
| Runtime monitoring | Identity misuse, object access, anomalies, errors, and response risk | Needs tuning, ownership, retention, and response workflows |
| Incident exercises | Logging, alerting, evidence quality, and recovery readiness | A test environment may not mirror production operations |
Use ASVS 5.0 to convert risk categories into versioned, testable requirements. Use the WSTG to structure authorized testing. For APIs, add the OWASP API Security Top 10 and test authorization, business flows, resource consumption, inventory, and third-party interactions explicitly.
A Five-Phase OWASP Top 10 Implementation Roadmap
Inventory and classify
List applications, APIs, domains, owners, environments, data classes, external exposure, privileged functions, dependencies, and critical business flows.
Define testable requirements
Map the most relevant Top 10 categories to ASVS requirements, architecture decisions, secure coding guidance, configuration standards, and acceptance criteria.
Build verification into delivery
Add threat modeling, peer review, automated checks, dependency analysis, configuration validation, and controlled security testing to the software lifecycle.
Observe production behavior
Collect operation-aware telemetry for identity, authorization decisions, errors, sensitive endpoints, response characteristics, dependencies, and business-flow anomalies.
Measure and improve
Track ownership, remediation time, recurring findings, test coverage, alert quality, control exceptions, dependency exposure, and retirement of unsupported assets.
OWASP Top 10 Security Checklist
This checklist is designed for practical review. It should be adapted to the application’s architecture, data, business impact, users, and assurance requirements.
| Control area | Evidence to request | Warning sign |
|---|---|---|
| Asset ownership | Current application and API inventory with named owners | Unknown or unsupported production endpoints |
| Authorization | Role, tenant, object, property, and action test matrix | Client-side checks or inconsistent service decisions |
| Configuration | Versioned hardening baseline and deployment validation | Manual production changes and exposed defaults |
| Supply chain | Component inventory, provenance, artifact verification, update process | Unreviewed sources or unsigned build outputs |
| Data protection | Data-flow map, classification, retention, key and secret controls | Sensitive values in logs, caches, exports, or test data |
| Injection prevention | Parameterized interfaces and interpreter-boundary tests | Dynamic query or command construction |
| Secure design | Threat models, abuse cases, transaction and workflow controls | Security considered only after implementation |
| Authentication | Identity-flow review, token validation, session and recovery tests | Long-lived credentials or inconsistent validation |
| Integrity | Trusted update channels, signing, review, and safe data handling | Automatic trust of artifacts, plugins, or serialized data |
| Logging and response | Context-rich events, tested alerts, investigation playbooks | Generic logs, sensitive telemetry, or unowned alerts |
| Exceptional conditions | Timeout, failure, retry, rollback, and fail-closed tests | Sensitive actions continue when dependencies fail |
Common OWASP Top 10 Program Mistakes
Claiming complete coverage
The categories are broad, and several depend on business context, architecture, and production operations. Avoid claims that one product, scan, or test provides complete Top 10 coverage.
Treating rankings as universal priorities
A01 is ranked first in the 2025 list, but your highest risk may be a supply-chain path, a sensitive payment flow, a cryptographic weakness, or an unsafe operational fallback. Prioritize with system-specific evidence.
Testing only the user interface
Mobile applications, APIs, background jobs, administrative functions, partner integrations, GraphQL operations, and service identities may expose behavior that is not visible through the main web interface.
Ignoring responses and business outcomes
A request may look valid while the response exposes excessive data or the workflow creates an unauthorized refund, export, privilege change, or other business impact.
Generating alerts without owners
Detection has limited value if no team owns the event, evidence is incomplete, routing is untested, or the remediation decision is not recorded.
Authoritative OWASP Resources
Conclusion
The OWASP Top 10:2025 is most useful when it improves decisions. It should lead to clearer security requirements, better design reviews, safer implementation patterns, stronger authorization, controlled dependencies, predictable failure behavior, useful telemetry, and faster remediation.
Use the Top 10 to build awareness. Use ASVS to define verifiable requirements. Use the WSTG and authorized testing to evaluate controls. Add API-specific guidance and runtime context where business functions are exposed through APIs. That combination turns a familiar list into a working application security program.
FAQs About OWASP Top 10 Vulnerabilities
What is the OWASP Top 10?
The OWASP Top 10 is an awareness document that groups the most important web application security risks into ten categories. It helps development, security, product, and leadership teams use a shared language for application risk.
What are the OWASP Top 10 vulnerabilities in 2025?
The OWASP Top 10:2025 categories are Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions.
Is the OWASP Top 10 a compliance standard?
No. It is primarily an awareness baseline. Organizations can map it to policies and training, but it does not replace a verifiable standard, threat modeling, secure development practices, penetration testing, or regulatory requirements.
What is the difference between OWASP Top 10 and ASVS?
The Top 10 describes broad risk categories. OWASP ASVS provides detailed, testable security requirements that teams can use during design, development, verification, procurement, and assurance activities.
Are OWASP Top 10 examples safe to use?
Examples are useful when they explain a weakness without providing harmful exploitation steps. Testing should use authorized systems, synthetic data, controlled accounts, documented scope, and clear stop conditions.
Does the OWASP Top 10 apply to APIs?
Yes, but APIs also have specialized risks such as object-level authorization failures, sensitive business-flow abuse, resource consumption, inventory gaps, and unsafe third-party API consumption. The OWASP API Security Top 10 provides additional API-specific guidance.
What is the most important OWASP Top 10 category?
There is no universal answer for every system, although Broken Access Control is ranked A01 in the 2025 list. The right priority depends on the application, data, users, architecture, exposure, business functions, and existing controls.
Can automated scanners cover the full OWASP Top 10?
No. Automation can identify many implementation weaknesses, but categories such as insecure design, business-logic abuse, authorization context, and operational alert effectiveness require human review and system-specific evidence.
How should teams test OWASP Top 10 risks?
Use a balanced approach that combines threat modeling, architecture review, code review, software composition analysis, configuration checks, automated testing, manual authorization and business-logic testing, and runtime validation.
How often is the OWASP Top 10 updated?
OWASP updates the list periodically rather than on a fixed annual schedule. Teams should reference the edition explicitly and confirm the current official release when updating training, policies, or procurement requirements.
How does runtime monitoring support OWASP risk reduction?
Runtime monitoring can reveal unusual identity use, object access, payloads, response data, error patterns, dependency behavior, and business-flow activity that may not be visible during pre-production testing.
What is the first practical step for reducing OWASP Top 10 risk?
Start by inventorying applications and APIs, identifying sensitive data and business actions, assigning owners, and mapping the highest-risk flows to testable security requirements and observable runtime signals.
Move from awareness to actionable API security
OWASP awareness is an important foundation, but production APIs also need continuous inventory, identity and object context, sensitive-response visibility, business-flow analysis, and investigation-ready events. Ammune helps teams connect broad risk categories to real API behavior.