The OWASP Top 10 is an awareness framework for understanding important classes of web application risk. The current published edition is the OWASP Top 10:2025. The older 2017 and 2021 lists are useful for historical comparison, but their category names, numbering, and scope must not be presented as the latest ranking. This distinction matters because application architecture has changed: modern teams depend on package registries, deployment pipelines, cloud configuration, API interfaces, and complex trust boundaries.
OWASP does not promise that fixing ten categories will make an application secure. It identifies recurring risk families that help teams prioritize design reviews, security testing, and prevention. A credible security program also includes asset inventory, threat modeling, code review, dependency governance, incident response, and ongoing verification. The categories offer a common language for discussing exposure; they do not replace product-specific analysis.
How to interpret the 2025 list
The 2025 categories are 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 and Alerting Failures, and A10 Mishandling of Exceptional Conditions. The sequence is an ordering of awareness priorities, not a step-by-step attack playbook or a guarantee that risks outside the list are harmless.
Several changes deserve attention. The software supply-chain category explicitly expands the older vulnerable-components concern to include weaknesses in dependency provenance and build or distribution processes. Mishandling of exceptional conditions is a new category that highlights unsafe behavior when applications receive unexpected input or enter a failure state. Meanwhile, many issues that teams recognize from the 2017 edition still matter even though their labels or ranking changed.
Broken access control: test the rule at every boundary
Access control determines whether a particular identity is permitted to perform an action on an object. A common failure is checking authorization on a page but not on the API used by that page. For example, changing an invoice ID in an HTTP request should never expose another customer’s invoice simply because the request was authenticated. Authorization needs to be enforced on the server using the requester’s identity and the target resource’s ownership and permissions.
Test horizontal access between peers and vertical access between ordinary users and administrators. Include tenant separation, background jobs, exported files, and batch APIs. A useful negative test asks what would happen if the user deliberately modifies an object identifier, request method, or role field. Successful defense means the backend rejects the action consistently, not that a button is hidden in the interface.
Security misconfiguration: control the environment as code
Misconfiguration can make a secure feature unsafe. Excessively permissive object storage, development credentials left in production, debug routes, incorrect CORS policies, unnecessary services, and wide network exposure all create avoidable risk. Review default settings during initial deployment and again after upgrades, migrations, or infrastructure changes.
Keep secure baseline configurations in version control, automate checks for critical deviations, and test the resulting deployed state. Different environments may need different values, but the reason for every exception should be documented. When a service is exposed publicly, prove that public access is required for its function rather than assuming that a working endpoint is properly protected.
Software supply chains: dependencies, builds, and trusted releases
A web application can be compromised without any developer writing an obviously vulnerable line of code. A malicious dependency update, compromised package-maintainer account, poisoned build artifact, or unprotected CI/CD credential can alter what eventually runs in production. Supply-chain protection begins by knowing what components are included and which systems can modify them.
Maintain dependency inventories, evaluate update sources, pin or constrain versions appropriately, and review critical transitive dependencies. Protect release signing keys and build credentials, require review for pipeline changes, and record provenance where practical. A vulnerability scanner is one part of this program; it does not detect every malicious release or configuration failure.
Cryptography: protect data with correct choices and key management
Cryptographic failures are often caused by usage rather than mathematics. Sensitive information may be sent without adequate transport protection, encrypted with outdated settings, logged in plain text, or protected by keys stored beside the data. A secure design classifies which information requires confidentiality or integrity and chooses appropriate controls across its life cycle.
Use well-supported protocols and libraries instead of inventing custom encryption. Manage keys as privileged secrets, rotate and revoke them when required, and restrict who or what can request decryption. For passwords, use a modern password-hashing algorithm with appropriate work factors rather than reversible encryption. Test for accidental disclosure in logs, backups, exports, and error responses.
Injection: keep commands separate from untrusted input
Injection occurs when untrusted data is interpreted as part of a command or query. SQL injection is a familiar example, but command, template, and other interpreter boundaries can fail in comparable ways. The central defense is to separate instructions from data using parameterized interfaces, safe APIs, and strict contextual handling instead of hoping that input filtering will catch every dangerous string.
Review data flows from HTTP requests, file content, message queues, third-party services, and administrative interfaces. An internal integration can still supply malicious or malformed data. Combine parameterization, least-privilege execution, and targeted testing; input validation should describe allowed business values, not replace a safe query or command construction method.
Insecure design: address harmful workflows before coding
Some vulnerabilities are not coding mistakes but failures to consider misuse. A password-reset workflow that allows unlimited guesses or an account-recovery process that reveals sensitive information can be correctly implemented according to an unsafe design. Threat modeling helps identify the assets involved, who can reach them, and how an attacker might exploit the intended workflow.
Write misuse cases alongside user stories, decide how rate limits and approval boundaries work, and test business rules with realistic adversarial scenarios. A secure control must fit the product’s actual behavior. Adding a scanner after release cannot compensate for a system whose fundamental trust boundaries permit the wrong operations.
Authentication and session management need separate checks
Authentication failures allow an attacker to impersonate or retain access as another user. Examples include weak account-recovery flows, insecure credential storage, missing defenses against credential stuffing, and sessions that remain usable after account or privilege changes. Consider multi-factor authentication, secure session cookies, rotation and expiration, risk-based monitoring, and reliable recovery policies.
Test the whole identity lifecycle: initial sign-in, reset, token issuance, permission changes, sign-out, and account deactivation. Identity systems frequently span several services, so inconsistent handling between an application and its identity provider can create a gap even if each individual screen appears secure.
Integrity, logging, and exceptional conditions
Software or data integrity failures involve trusting content or execution flows that should be verified. Protect update mechanisms, serialized objects, message payloads, and deployment artifacts according to the risks they carry. Logging and alerting failures create a different problem: a breach can occur without anyone recognizing it. Capture meaningful events, correlate them across services, protect log integrity, and build alerts that reach people who can respond.
Mishandled exceptions can turn unusual conditions into security failures. An authorization check that fails open when a dependency times out is more dangerous than an ordinary error page. Test unexpected inputs, partial outages, canceled transactions, storage failures, and dependent-service delays. Fail safely, preserve enough diagnostic information for operators, and keep sensitive internals out of messages returned to users.
Turning OWASP awareness into a practical review
Start with one high-value workflow such as account recovery, checkout, file upload, or administrative configuration. Draw its data movement and trust boundaries; identify who controls each input; and test what should happen for unauthorized access, malformed requests, dependency failures, and replayed operations. Then relate each discovered weakness to the appropriate OWASP 2025 category rather than using the category name as a substitute for diagnosis.
Professional security education can provide complementary context. For example, CEH covers broader ethical-hacking concepts that intersect with web application vulnerability testing, but a general ethical-hacking credential is not the same as demonstrated competence in secure web application design. Application teams still need framework-specific testing, remediation evidence, and a repeatable review process.
A useful OWASP-based review should also distinguish detection from remediation. Finding that an API returns another user’s record is evidence of broken access control; fixing it requires a verified authorization policy at the correct server boundary, regression tests for unauthorized requests, and monitoring for attempts to bypass that policy. Simply concealing the route in a browser interface does not solve the issue. Similarly, an injection finding should result in safer command or query construction and tests that cover the original input path, not only the addition of a new blacklist.
Teams should record severity in the context of real deployment rather than treating the category rank as a substitute for impact analysis. Ask whether an attacker can reach the vulnerable workflow, what data or action would be exposed, which privileges are required, and how reliable an exploit would be. Then connect the decision to ownership, release scheduling, and a clear validation of the fix. This process turns a reference list into demonstrable improvement in application security.
Check OWASP’s official 2025 project before preparing training or writing compliance language. A legacy list can be cited accurately when discussing the history of security practice, but it should never be mislabeled as the current release. The most useful result of studying the Top 10 is a better ability to find, explain, prioritize, and prevent vulnerabilities in real applications.
As a practical release gate, assign a named reviewer to each security finding and attach evidence of the attempted fix. Retest the same vulnerable input, then test a nearby case that might bypass the change: another user account, a different tenant, a missing header, or a second API method. Record the environment, software version, expected authorization rule and observed result. This prevents teams from mistaking a cosmetic mitigation for a tested repair and makes future regression checks repeatable.
