Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The OWASP Top 10:2025 names ten major areas of web application security risk, led by broken access control. Use it to organize security reviews and identify questions to investigate—not as a universal forecast of which flaw will affect a particular site or a remediation queue that every organization should follow in the same order.
What the OWASP Top 10:2025 is—and what it is not
The OWASP Top 10 Project describes its list as “a standard awareness document for developers and web application security.” The 2025 edition is an awareness and prioritization framework. It groups risks that can overlap, and it aims, where practical, to focus on underlying causes rather than only visible symptoms.
OWASP also cautions that organizations face different threat actors and business impacts, and that its ranking method is imperfect. A high position is a reason to examine a category, not proof that it is your application’s most likely or most damaging failure. Start with the assets your application handles, its architecture, plausible threats, and the consequences of an incident.
The ten risks, in OWASP’s 2025 order
| Rank | Category | Where to look |
|---|---|---|
| A01 | Broken Access Control | Whether users and services can act only within their intended permissions |
| A02 | Security Misconfiguration | Application, system, and cloud-service settings |
| A03 | Software Supply Chain Failures | Dependencies, build systems, and software distribution |
| A04 | Cryptographic Failures | Protection of sensitive data and cryptographic keys |
| A05 | Injection | Untrusted data that reaches an interpreter as instructions |
| A06 | Insecure Design | Security controls absent or inadequate in the design |
| A07 | Authentication Failures | How user identity is established and maintained |
| A08 | Software or Data Integrity Failures | Whether software, code, and data artifacts can be trusted |
| A09 | Security Logging and Alerting Failures | Whether relevant events are recorded, protected, and acted on |
| A10 | Mishandling of Exceptional Conditions | Whether unanticipated failure paths preserve controls and safe recovery |
What each category means for a web application
A01 Broken Access Control
Authorization is the policy governing what an already identified user or service is allowed to do. OWASP’s A01 page puts it this way: “Access control enforces policy such that users cannot act outside of their intended permissions.” Failures can include violating least privilege or deny-by-default, changing a URL or API request to reach another user’s data, leaving POST, PUT, or DELETE actions unprotected, escalating privileges, tampering with tokens or cookies, or using permissive CORS settings.
#1 Best Overall
Review permission checks on every relevant action and resource, including API endpoints; do not rely on a user interface hiding a button. OWASP’s 2025 introduction reports a 3.73% average incidence rate for A01: the average share of tested applications with one or more of the 40 CWEs mapped to the category. The A01 page separately reports that 100% of applications tested had some form of broken access control. These are figures from OWASP’s tested population, not estimates for all web applications.
A02 Security Misconfiguration
Misconfiguration means an application, system, or cloud service is deployed with insecure settings. Unchanged default accounts, unnecessary features, overly informative error messages, or missing or insecure security headers can expose weaknesses even when application code has not changed.
Use a repeatable hardening process: establish secure settings, remove what the application does not need, and review configuration as part of deployment and maintenance. OWASP’s 2025 introduction gives A02 a 3.00% average incidence rate in its tested data; this is not a general-population prevalence estimate.
Recommended Free Tools
Rank #2
- Comes with secure packaging
- It can be a gift item
- Easy to read text
A03 Software Supply Chain Failures
This category extends beyond whether an application uses a vulnerable or outdated component. It covers failures across dependencies, build systems, and software distribution, where an attacker or an integrity problem can affect what enters or reaches a production application.
Consider how dependencies are selected and maintained and how software moves through build and distribution. OWASP notes that testing this category is challenging, so a low presence in observed test data should not be taken to mean low severity.
A04 Cryptographic Failures
Cryptographic failures include missing or insufficient protection and exposed keys. They can put sensitive data at risk if it is not protected appropriately in transit or if secrets and keys are mishandled.
Rank #3
Use transport-layer encryption for data in transit, select protections appropriate to the data, and safeguard cryptographic keys and other secrets. OWASP’s 2025 introduction reports a 3.80% average incidence rate for A04 in its tested data; the figure describes that dataset, not all web applications.
A05 Injection
Injection occurs when untrusted input reaches an interpreter—such as a browser, database, or command line—and is treated as instructions. OWASP’s A05 page says, “The best means to prevent injection requires keeping data separate from commands and queries:”
Prefer safe APIs and parameterized interfaces that preserve that separation. Validate untrusted input on the server as an additional control, but do not treat validation alone as a complete defense. OWASP recommends combining code review with automated testing; testing tools can help find issues, but do not guarantee that an application is safe.
A06 Insecure Design
Insecure design is a weakness in the security controls considered or built into an application’s design. It is different from a setting that was made insecure during deployment: a well-configured system can still lack a control its design needed. Evaluate security requirements and controls while deciding how the application should work, rather than relying only on later configuration or bug fixes.
A07 Authentication Failures
Authentication concerns proving and maintaining identity; authorization concerns what that identity is permitted to do. A successful login does not establish that a user should be able to access every resource or perform every action. Keep identity checks and permission checks distinct when reviewing application flows, and assess both categories rather than treating one as a substitute for the other.
A08 Software or Data Integrity Failures
This category concerns whether software, code, and data artifacts remain trustworthy across boundaries. Assess how the application establishes that an artifact or data item is genuine and has not been improperly altered. This overlaps with supply-chain risk, but the emphasis here is on maintaining and verifying integrity.
A09 Security Logging and Alerting Failures
Security operations depend on useful, trustworthy records and alerts. Risk areas include sensitive log data that is not protected, log injection, missing event coverage, outdated alert use cases, or so many alerts that important signals are obscured.
Record security-control activity with enough context to support investigation, protect logs from exposure and injection, and retain them for a period appropriate to that purpose. Connect relevant events to actionable alerts and review whether those alerts remain useful. Logging and alerting support detection and response; they do not replace preventive controls.
A10 Mishandling of Exceptional Conditions
This category addresses unanticipated failure paths that can weaken security controls or prevent safe recovery. Include exceptional conditions in design and review so that unexpected failures do not bypass the protections the application relies on. OWASP lists this as a distinct 2025 category; it should not be folded into configuration or design merely because those areas can also contribute to a failure.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to turn the list into a security review
- Map assets and consequences. Identify the data, accounts, and application functions that matter, then consider the business impact if they are exposed, changed, or unavailable.
- Trace identities to permissions. Review who can reach each resource and action, including API operations and changes to identifiers or requests. Check that access is constrained to intended permissions.
- Review design and deployment separately. Ask whether the design includes adequate controls, then inspect deployed application, system, and cloud settings for insecure defaults, unnecessary features, and unsafe exposure.
- Follow the path from code to production. Examine how dependencies, build processes, distribution, and software or data artifacts are trusted and protected.
- Trace untrusted data to execution. Look for points where input reaches interpreters; favor safe parameterized interfaces and combine review with automated testing.
- Check data protection and operational visibility. Review transport encryption and key handling, then verify that security events are recorded, protected, retained appropriately, and connected to useful alerts.
- Prioritize for your application. Use the OWASP categories to structure findings, then set remediation order according to your assets, architecture, likely threats, and business impact—not rank alone.
Why the OWASP figures need context
OWASP’s incidence figures describe its tested populations and the mapped CWEs included in its methodology. They are not a census or universal prevalence estimate for all web applications, and they do not tell an organization which vulnerability to fix first. Testing coverage and OWASP’s risk-scoring approach also affect how the results should be interpreted.
Use the figures as context for the framework, not as a probability that a specific application has a particular flaw. A category can deserve serious attention even when the available test data does not make it appear common, especially where OWASP says testing is challenging.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
