Most security problems don’t stem from sophisticated flaws but from known errors that users repeat time and again. Every few years, the Open Worldwide Application Security Project (OWASP) publishes a report analysing common types of application security risks.
With the rise of trends like vibecoding or agent-based programming, where AI capabilities allow for more unattended software creation, it’s interesting to know what mechanisms can prevent security breaches, data theft, or identity theft.
| Vulnerability | Main Risk | Basic Prevention |
| Poor Access Control | Users access data or functions they should not | Enforce server-side access controls |
| Poor Security Settings | Incorrect configurations expose the application | Use secure default settings and review configurations |
| Software Supply Chain Failures | Compromised dependencies or build systems affect the application | Monitor dependencies and secure the software supply chain |
| Cryptographic Failures | Sensitive data is exposed or poorly protected | Use strong, modern encryption and proper key management |
| Injections | Untrusted input changes application commands or queries | Validate the input and use parameterised queries |
| Unsafe Design | Security weaknesses are built into the application’s design | Include security requirements during design |
| Authentication Failures | Attackers gain access to accounts | Use strong authentication and secure session management |
| Data or Software Integrity Failures | Untrusted or modified data/software is accepted | Verify integrity and use trusted update mechanisms |
| Security Logging and Alerting Failures | Attacks may go unnoticed | Implement effective logging and security alerts |
| Poor Handling of Exceptional Conditions | Errors can lead to unexpected or insecure behaviour | Fail safely and handle errors securely |
10 Most Common Application Vulnerabilities
1. Poor Access Control
The 2025 edition ranks this type of vulnerability first and identifies it as a major application security risk.
Access control problems in an application refer, for example, to not applying the principle of least privilege, which allows a user to act outside of their intended permissions.
The most common attack vectors include manipulation of parameters in URLs or HTTP headers and direct references to insecure objects (a user accesses /api/orders/123 but changes the URL to /api/orders/124 and sees another user’s order). Other possible vectors include the absence of access controls on POST/PUT/DELETE endpoints or misconfiguration of state control or authentication elements such as CSRF and CORS.
The main mitigation for this type of problem is to implement access control in trusted server-side code, never only on the client.
Also Read: Benefits Of Having FireWall Protection On The Cloud
2. Poor Security Settings
It rises from 5th to 2nd place and is present in 100% of the applications analysed.
A system becomes vulnerable when any layer of its stack (server, framework, database, cloud) lacks proper security.
The most common scenarios include applications or management consoles with default credentials in production, error messages that expose stack traces, component versions, excessive permissions in S3 buckets or similar, and absence of security headers.
The greater the complexity of the software and infrastructure (containers, cloud deployments, microservices), the larger the potential for failure. Hardening processes are necessary at all levels to mitigate risks.
3. Failures in the Software Supply Chain
The community ranked it as the main risk, and it rises from sixth position in 2021.
It extends the previous category of “vulnerable components” to cover the entire build and distribution cycle: unaudited transitive dependencies, CI/CD pipelines with weaker security controls than the systems they deploy, components from untrusted sources, and lack of separation of responsibilities in the production promotion flow.
The reference cases included in 2025 show its true scope: the theft of $1.5 billion from the cryptocurrency platform. Bybit was attacked through its wallet software, which was only activated under specific conditions, and the Shai-Hulud npm worm, which seeded malicious versions of popular packages and exfiltrated sensitive data to public GitHub repositories.
The primary mitigation involves generating and maintaining a complete Software Bill of Materials (SBOM), including transitive dependencies. Another way to limit risks is to implement staged rollouts or phased deployments to limit exposure to a vulnerability in any of the application’s components.
4. Cryptographic Failures
Another familiar name in the ranking, it drops two positions in the 2021 edition and now occupies fourth place.
It encompasses the use of weak, broken, or poorly implemented algorithms (MD5, SHA1, CBC); pseudorandom number generators that are not considered cryptographically secure; hardcoded keys or keys present in some commit in the repository history; lack of encryption for sensitive data; and poor key lifecycle management.
OWASP adds an explicit warning in this edition: the transition to post-quantum cryptography (PQC) must begin now. High-risk systems must be protected against quantum computing by the end of 2030.
For passwords, the recommended algorithms are Argon2, yescrypt, scrypt or PBKDF2-HMAC-SHA-512.
5. Injections
It drops slightly in the ranking, from third to fifth place. This category contains more than 62,000 CVEs (Common Vulnerabilities and Exposures), the largest number among the Top 10 categories.
Among the attack vectors in this type of vulnerability, we can find unvalidated, unfiltered, or unsanitised inputs that reach an interpreter (database, operating system, browser) and are executed as part of a command. This applies to SQL injections, NoSQL injections, operating system commands, or XSS.
One solution to prevent various types of injections is to use parameterised APIs or ORMs. If that’s not possible, implement positive validation on the server side and interpreter-specific escaping.
6. Unsafe Design
This category drops from fourth to sixth place in the 2025 edition.
OWASP explicitly distinguishes between insecure design and insecure implementation: these are problems with different circumstances, occurring at different stages of the development lifecycle, and requiring specific remediation. A correct implementation cannot compensate for security controls that were never designed.
This category encompasses failures in business logic, absence of threat modelling, and lack of tenant or layer segregation.
Mitigation requires applying security measures before the code: from requirements gathering, through the design of user flows and the definition of abuse cases, not just in code review.
7. Authentication Failures
As in the 2021 edition, this category remains in seventh position.
Authentication failures are weaknesses in identity verification that allow an attacker to impersonate a legitimate user. Vectors include the absence of MFA, hardcoded credentials, weak password permissions, sessions not properly invalidated after logout, and insecure recovery flows (typical “secret questions” are explicitly prohibited by NIST 800-63b).
In 2025, OWASP reflects on the rise of hybrid credential stuffing attacks: an attacker not only uses leaked credentials but also generates incremental variants (e.g., rotating a password from Winter2025 to Winter2026) based on predictable patterns.
The recommendation to avoid these types of risks is to implement validation against lists of compromised credentials (for these attacks purpose there are portals such as Have I Been Pwned) both in registration and in password change.
8. Data or Software Integrity Failures
It also remains in the same position as it did in 2021.
This is similar in concept to the software supply chain failures mentioned earlier, but it operates at a lower level. This category reflects failures that occur when the artefact you are running does not have high integrity. It covers plugins or libraries loaded from unverified sources, automatic updates without digital signature validation, or CI/CD pipelines without integrity controls.
Mitigation would include digital signatures on artefacts, as well as the use of internal repositories for high-risk dependencies.
9. Failures in Alerting and Security Logging
With a name change to place greater emphasis on the alerted part, this category maintains its ninth position in the ranking.
This category is difficult to measure statistically (only 723 associated CVEs), but its operational impact is critical. Typical failures include not logging auditable events (failed logins, denied access, etc.), logs without tamper protection, lack of alert thresholds, and false positives that overwhelm the SOC team, preventing the detection of real threats.
One of the documented scenarios describes a gap of more than 7 years that went undetected due to a lack of monitoring. OWASP recommends the use of honeytokens as a detection mechanism.
10. Poor Handling of Exceptional Conditions
Finally, we have a new category in this ranking. It has 24 CWEs (Common Weakness Enumeration) and a maximum incidence rate of 20.67%.
When an application fails to prevent, detect, or respond appropriately to exceptional conditions, the result can range from exposing sensitive information in error messages to corrupting the state in financial transactions to denial of service due to unreleased resources.
The fundamental principle is fail-closed: in the event of an error during a transaction, the system must perform a full rollback before reporting the failure. Attempting to recover a partially completed transaction is where vulnerabilities arise that are difficult to reproduce and detect.
Mitigation requires exception handling at the point where it occurs (not in higher layers), a global handler as a safety net, rate limiting on all susceptible flows, and centralisation of error logging and alerting.
Also Read: How Does AI Contribute To Business Protection Measures?
