The OWASP Top 10:2025 is an awareness document that identifies ten major categories of web application security risk. Developers, testers, architects, and managers can use it to set priorities, but it is a starting point rather than a complete application security standard or testing checklist.
What changed in the OWASP Top 10:2025
OWASP published the 2025 release with a revised order and updated categories. Broken Access Control remains first. Security Misconfiguration moves to second, and Software Supply Chain Failures broadens the older focus on vulnerable and outdated components. Mishandling of Exceptional Conditions is new to the list.
The official OWASP Top 10:2025 describes the following web application security risks:
- A01 Broken Access Control: Users can act outside their intended permissions, view another user’s records, change protected data, or reach administrative functions.
- A02 Security Misconfiguration: Unsafe defaults, unnecessary features, exposed error details, missing security headers, or inconsistent cloud and application settings create openings.
- A03 Software Supply Chain Failures: Weaknesses in dependencies, build systems, update channels, repositories, and distribution processes can compromise software before deployment.
- A04 Cryptographic Failures: Poor protection of sensitive data, weak algorithms, exposed keys, or incorrect transport security can reveal information.
- A05 Injection: Untrusted input changes a command or query interpreted by SQL, operating system, directory, template, or another engine.
- A06 Insecure Design: The product lacks controls needed for its risks because security requirements and threat scenarios were not addressed during design.
- A07 Authentication Failures: Weak login, session, credential recovery, or identity checks let attackers impersonate users.
- A08 Software or Data Integrity Failures: Code, updates, serialized data, or automated pipelines are trusted without adequate verification.
- A09 Security Logging and Alerting Failures: Events are missing, unclear, poorly protected, or never reviewed, delaying detection and response.
- A10 Mishandling of Exceptional Conditions: The application fails unsafely when errors, unusual states, resource limits, or unexpected inputs occur.
Broken access control needs object-level tests
Access control bugs often hide behind a valid login. A user changes an identifier in a request and sees another account’s invoice. A standard account calls an administrative endpoint directly. A server accepts a hidden field that changes ownership. These failures are easy to miss when testing only the visible interface.
Authorization checks belong on the server and should apply to every protected object and function. Deny access by default, centralize policy where practical, record failures, and test horizontal and vertical privilege changes. Automated scanners can help, but business permissions usually require manual tests built around real roles and records.
Security misconfiguration spans code and cloud
Modern applications depend on frameworks, containers, identity services, cloud storage, gateways, and deployment pipelines. A secure codebase can still expose data through a public bucket, permissive cross-origin policy, debug endpoint, sample account, or overly broad service role.
Teams should define approved configuration as code, remove unused functions, protect management interfaces, separate environments, and compare deployed settings with the approved baseline. Error responses should help operators without revealing stack traces, credentials, internal paths, or customer data to users.
Secure coding practices must cover the delivery chain
Secure coding practices still include input validation, context-aware output encoding, parameterized queries, session protection, and clear authorization checks. The 2025 list also asks teams to look beyond source files. Dependencies, build runners, package registries, deployment credentials, and update mechanisms can all affect the integrity of released software.
Maintain an inventory of direct and transitive components, restrict who can alter the build, pin and verify dependencies where suitable, review changes, and protect signing or publishing credentials. A warning from a dependency scanner is useful only when someone owns the decision to update, replace, isolate, or accept the component.
Publishers planning a public site can pair these controls with the site's practical guide to starting a newspaper in India, because editorial operations and web application protection solve different parts of the same launch. Students who want a wider legal learning context can also visit the Law Students Club.
Application security testing should follow the lifecycle
Application security testing is stronger when it begins before release. Threat modeling can identify dangerous workflows during design. Code review and static analysis can catch unsafe patterns during development. Dependency checks can flag known component issues. Dynamic tests and penetration testing can exercise the running application and its authorization rules.
After release, logging, alerting, vulnerability intake, patch management, and incident response keep the program alive. Retest repaired findings. Review assumptions when the product adds a new role, payment flow, integration, tenant model, or cloud service. A one-time OWASP check cannot cover years of product change.
Use the OWASP list without turning it into a badge
There is no honest claim that an application is secure merely because a scan labels it OWASP compliant. The Top 10 groups common risk categories; it does not define every control for a particular system. Use it to ask better questions, teach teams, and organize findings. Pair it with requirements suited to the application, its data, and its users.
Start with the category most likely to affect the product’s business rules. Test it against real roles and data, record evidence, fix the root cause, and retest. Then move through the remaining categories while keeping a separate view of risks unique to the application.