The Ten Most Critical Web Application Security Risks The OWASP Top 10 for 2025
Welcome to the 8th installment of the OWASP Top Ten!
A huge thank you to everyone who contributed data and perspectives in the survey. Without you, this installment would not have been possible. THANK YOU!
Introducing the OWASP Top 10:2025
What's changed in the Top 10 for 2025
There are two new categories and one consolidation in the Top Ten for 2025. We’ve worked to maintain our focus on the root cause over the symptoms as much as possible. With the complexity of software engineering and software security, it’s basically impossible to create ten categories without some level of overlap.
The list has two new categories and one consolidation this year. We're focusing on the why (the root cause) instead of just the what (the symptom).
A01: Broken Access Control (Still #1!)
The Problem: Users can sneak into places they shouldn't be, like accessing other people's accounts or admin pages. It's like finding a master key for the whole building.
Vibe Check: 100% of tested apps had this problem. Yikes.
How to Stop It: Handle all access checks on the server (never in the browser!), deny access by default, and log/alert when people try to mess with access.
Real Talk: Stop trusting user input in URLs or API calls that control access.
A02: Security Misconfiguration (Creeping Up!)
The Problem: The system or cloud service wasn't set up securely. Think leaving default admin passwords, turning on features you don't need, or having open-to-the-world cloud storage (like S3 buckets).
Vibe Check: Also 100% of apps had this! It's rising because software is getting super complicated to configure.
How to Stop It: Automate a "hardened" (secure) setup process, remove all unnecessary stuff (samples, docs), and make sure your cloud permissions are locked down.
A03: Software Supply Chain Failures (The Big Sleeper)
The Problem: You're using vulnerable or malicious third-party code, libraries, or dependencies. It's not your code that's bad, but the stuff you brought in (like a bad ingredient in a recipe).
Vibe Check: The community survey voted this #1 risk. Remember SolarWinds? Yeah, that.
How to Stop It: Generate and track a Software Bill of Materials (SBOM) for everything you use. Use trusted sources for components, enable MFA, and secure your build/deployment (CI/CD) systems.
A04: Cryptographic Failures
The Problem: You're not encrypting sensitive data, or you're using old, weak, or broken encryption methods. Or maybe your encryption keys are just lying around.
Vibe Check: Bad encryption can lead to session hijacking or stolen passwords.
How to Stop It: Encrypt everything sensitive at rest and in transit (use TLS 1.2+). Use strong, modern hashing algorithms (like Argon2) for passwords. And for the love of security, manage your keys properly (use an HSM!).
A05: Injection
The Problem: The classic one. You send unsanitized user input to a backend interpreter (like a database or OS command line), and the attacker's input is executed as a command. SQL Injection and Cross-site Scripting (XSS) live here.
Vibe Check: TONS of occurrences (over 1.4 million) and the most CVEs reported (62k+).
How to Stop It: Use safe APIs with parameterized queries (the #1 defense!). If you can't, use positive server-side validation. Never concatenate raw user input directly into a query or command.
A06: Insecure Design (Design Fails)
The Problem: Security wasn't even considered when the app was being designed. The flaw is in the architecture or business logic itself, not just the code.
Vibe Check: Design flaws can't be fixed by perfect code. Example: using "security questions" for password reset (NIST hates this).
How to Stop It: Use Threat Modeling early in development. Get AppSec pros involved from the start. Build secure design patterns (paved-road components) and write tests for misuse-cases.
A07: Authentication Failures
The Problem: The system is easily tricked into thinking an attacker is a legitimate user. This includes weak passwords, bad session management, or getting wrecked by credential stuffing attacks.
Vibe Check: Over 1 million documented occurrences.
How to Stop It: Enforce Multi-Factor Authentication (MFA)! Use password managers. Check new passwords against lists of breached credentials. Use secure, high-entropy session IDs that are properly invalidated on logout.
A08: Software or Data Integrity Failures (Trust Issues)
The Problem: The system assumes that data or code is trustworthy without checking its integrity. Like downloading a software update without checking the digital signature to make sure it hasn't been tampered with.
Vibe Check: This is about trust boundaries. A React app passing raw, serialized state to a Spring Boot service without checks is a common example (Insecure Deserialization).
How to Stop It: Use digital signatures to verify code and data origin/integrity. Only use vetted, internal repositories for dependencies. Secure your CI/CD pipeline and avoid insecure deserialization.
A09: Security Logging & Alerting Failures
The Problem: When an attack happens, you don't notice until weeks (or years!) later because your logging is non-existent, incomplete, or not monitored. You can't detect, investigate, or recover from a breach.
Vibe Check: It's hard to test for this, but the impact is huge (GDPR fines, massive breaches).
How to Stop It: Log all security-critical events (logins, failed logins, access control failures). Protect the integrity of your logs. Establish real-time alerts and clear playbooks for suspicious behavior.
A10: Mishandling of Exceptional Conditions (The Newbie)
The Problem: Your app freaks out when something unexpected happens (errors, crashes, late validation) and, instead of gracefully failing securely, it "fails open" or exposes sensitive info (like a stack trace).
Vibe Check: This groups together a bunch of issues that used to be called "poor code quality." It's about being robust.
How to Stop It: Validate input early and often. Don't expose technical error messages to users. Make sure errors are caught and handled securely (fail closed, not open).
A01:2025 - Broken Access Control
A01:2025 - Broken Access Control remains the top vulnerability in the OWASP Top 10, with 100% of tested applications exhibiting some form of access control failure. This category is associated with critical Common Weakness Enumerations (CWEs), including CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), CWE-201 (Exposure of Sensitive Information Through Sent Data), CWE-918 (Server-Side Request Forgery), and CWE-352 (Cross-Site Request Forgery). Statistical data reveals a significant prevalence: the maximum incidence rate reaches 20.15%, with an average of 3.74%. Coverage varies, peaking at 100% and averaging 42.93%. The average weighted exploit and impact scores are 7.04 and 3.84, respectively, with 1,839,701 total occurrences and 32,654 related CVEs, underscoring the severity and frequency of this issue.
The description emphasizes that access control enforces policies to prevent users from exceeding their intended permissions. Failures result in unauthorized disclosure, modification, or destruction of data, or execution of business functions beyond user limits. Common vulnerabilities include violations of the principle of least privilege (deny by default), where access is granted indiscriminately; bypassing checks via URL modification, parameter tampering, force browsing, or API request alterations; insecure direct object references allowing access to others' accounts via identifiers; missing access controls on APIs for POST, PUT, and DELETE methods; privilege escalation, such as acting as an unauthenticated user or gaining unauthorized privileges; metadata manipulation involving tampering with JSON Web Tokens (JWT), cookies, or hidden fields; CORS misconfigurations permitting unauthorized origins; and force browsing to access authenticated or privileged pages.
Prevention measures focus on implementing access controls in trusted server-side code or serverless APIs, where attackers cannot alter checks or metadata. Key recommendations include denying access by default except for public resources; reusing access control mechanisms application-wide while minimizing CORS usage; enforcing record ownership in models to restrict create, read, update, or delete operations; applying domain models for unique business limits; disabling web server directory listings and securing file metadata or backups outside web roots; logging and alerting on access control failures; implementing rate limits on APIs and controllers to counter automated attacks; invalidating stateful session identifiers post-logout and using short-lived JWTs or refresh tokens with OAuth for revocation; and leveraging established toolkits for declarative controls. Developers and QA teams must incorporate functional access control into unit and integration tests.
Example attack scenarios illustrate real-world exploitation. In Scenario #1, an application uses unverified user input in SQL queries for account information, such as setting a parameter with request.getParameter("acct"), allowing attackers to tamper with the 'acct' parameter to access arbitrary accounts via URLs like https://example.com/app/accountInfo?acct=notmyacct. Scenario #2 demonstrates force browsing, where attackers guess URLs like https://example.com/app/getappInfo or https://example.com/app/admin_getappInfo to access restricted pages without authentication or admin rights. Scenario #3 highlights client-side-only controls, where JavaScript enforces access, but attackers bypass it using tools like curl https://example.com/app/admin_getappInfo to directly request protected endpoints.
References provided include the OWASP Proactive Controls for implementing access control, the Application Security Verification Standard on authorization, the Testing Guide for authorization testing, the Authorization Cheat Sheet, a PortSwigger article on exploiting CORS misconfigurations, and OAuth guidance on revoking access. The page maps 40 CWEs, such as CWE-22 (Path Traversal), CWE-284 (Improper Access Control), CWE-352 (CSRF), CWE-425 (Forced Browsing), CWE-862 (Missing Authorization), and CWE-918 (SSRF), among others, highlighting the broad spectrum of related weaknesses.
A02:2025 - Security Misconfiguration
Security misconfiguration occurs when a system, application, or cloud service is set up incorrectly from a security perspective, creating vulnerabilities. This can happen if the application lacks appropriate security hardening across any part of the application stack or has improperly configured permissions on cloud services. Other contributing factors include unnecessary features being enabled or installed, such as extra ports, services, pages, accounts, testing frameworks, or privileges. Default accounts and passwords that remain unchanged also pose risks. Additionally, a lack of central configuration to intercept excessive error messages can lead to the exposure of stack traces or other overly informative error messages to users. For upgraded systems, the latest security features might be disabled or not configured securely. Excessive prioritization of backward compatibility can result in insecure configurations. Security settings in application servers, frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., may not be set to secure values. Furthermore, servers might fail to send security headers or directives, or these are not configured securely. Without a concerted, repeatable application security configuration hardening process, systems face heightened risk.
This vulnerability is exacerbated by the increasing complexity of highly configurable software, leading to a rise in its ranking from #5 in the previous edition. Testing revealed that 100% of applications had some form of misconfiguration, with an average incidence rate of 3.00% and over 719,000 occurrences of Common Weakness Enumerations (CWEs) in this category. Notable CWEs include CWE-16 (Configuration) and CWE-611 (Improper Restriction of XML External Entity Reference, or XXE). The score table highlights 16 mapped CWEs, a maximum incidence rate of 27.70%, average coverage of 52.35%, average weighted exploit of 7.96, average weighted impact of 3.97, total occurrences of 719,084, and 1,375 total CVEs.
Several real-world scenarios illustrate the risks: An application server retains sample applications not removed from production, which contain known security flaws. If one is an admin console with unchanged default accounts, attackers log in with default passwords and compromise the server. Directory listing is not disabled, allowing attackers to list directories, download compiled Java classes, decompile them, and reverse engineer code to identify severe access control flaws. The application server's configuration permits detailed error messages, such as stack traces, exposing sensitive information or underlying flaws like vulnerable component versions. A cloud service provider (CSP) defaults to open sharing permissions, enabling access to sensitive data in cloud storage.
To mitigate this vulnerability, implement secure installation processes, including a repeatable hardening process for fast, easy deployment of locked-down environments. Development, QA, and production environments should be configured identically with different credentials, and this should be automated. Use a minimal platform by removing unnecessary features, components, documentation, or samples. Review and update configurations per security notes, updates, and patches as part of patch management (linked to A03 Software Supply Chain Failures). Review cloud storage permissions, such as S3 buckets. Adopt a segmented application architecture with separation between components or tenants using segmentation, containerization, or cloud security groups (ACLs). Send security directives to clients via security headers. Establish an automated process to verify configurations across environments, with manual verification at least annually if automation is unavailable. Proactively add central configuration to intercept excessive error messages. Use identity federation, short-lived credentials, or role-based access instead of embedding static keys or secrets in code, configuration files, or pipelines.
Key resources include the OWASP Testing Guide: Configuration Management, OWASP Testing Guide: Testing for Error Codes, Application Security Verification Standard V13 Configuration, NIST Guide to General Server Hardening, CIS Security Configuration Guides/Benchmarks, Amazon S3 Bucket Discovery and Enumeration, and ScienceDirect: Security Misconfiguration.
The vulnerability maps to 16 CWEs, including CWE-5 (J2EE Misconfiguration: Data Transmission Without Encryption), CWE-11 (ASP.NET Misconfiguration: Creating Debug Binary), CWE-13 (ASP.NET Misconfiguration: Password in Configuration File), CWE-15 (External Control of System or Configuration Setting), CWE-16 (Configuration), CWE-260 (Password in Configuration File), CWE-315 (Cleartext Storage of Sensitive Information in a Cookie), CWE-489 (Active Debug Code), CWE-526 (Exposure of Sensitive Information Through Environmental Variables), CWE-547 (Use of Hard-coded, Security-relevant Constants), CWE-611 (Improper Restriction of XML External Entity Reference), CWE-614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute), CWE-776 (Improper Restriction of Recursive Entity References in DTDs, 'XML Entity Expansion'), CWE-942 (Permissive Cross-domain Policy with Untrusted Domains), CWE-1004 (Sensitive Cookie Without 'HttpOnly' Flag), and CWE-1174 (ASP.NET Misconfiguration: Improper Model Validation).
A03:2025 - Software Supply Chain Failures
Software supply chain failures involve breakdowns or compromises in building, distributing, or updating software, often stemming from vulnerabilities or malicious changes in third-party code, tools, or dependencies. This category has expanded from its 2013 origins as "A9 – Using Components with Known Vulnerabilities" to encompass all supply chain issues. It ranked #1 in the OWASP Top 10:2025 community survey with 50% of respondents selecting it as the top risk. Despite limited Common Vulnerability and Exposures (CVEs)—only 11 mapped to related Common Weakness Enumerations (CWEs)—the average incidence rate is high at 5.19%, with a maximum of 9.56%. Key CWEs include CWE-477 (Use of Obsolete Function), CWE-1104 (Use of Unmaintained Third Party Components), CWE-1329 (Reliance on Component That is Not Updateable), and CWE-1395 (Dependency on Vulnerable Third-Party Component). Organizations are vulnerable if they fail to track component versions (including transitive dependencies), use unsupported or outdated software (e.g., OS, servers, databases, libraries), neglect regular vulnerability scans or security bulletins, lack change management for supply chain elements like CI/CD pipelines and repositories, do not harden systems with access controls and least privilege, allow single-person control over code promotion, use untrusted sources, delay fixes, skip compatibility testing for updates, ignore configurations (cross-referencing A02:2025-Security Misconfiguration), or have insecure CI/CD pipelines weaker than production systems.
Contributing factors include inadequate tracking of direct and nested dependencies, reliance on unmaintained or vulnerable components, absence of patch management processes, weak change tracking across CI/CD, repositories, IDEs, and artifacts, insufficient hardening (e.g., no MFA, poor IAM), use of components from untrusted sources, lack of separation of duties, delayed upgrades, untested compatibility, misconfigurations, and complex CI/CD with security gaps. The score table highlights metrics: 6 CWEs mapped, average incidence rate 5.72%, max coverage 65.42%, average coverage 27.47%, average weighted exploit 8.17, average weighted impact 5.23, total occurrences 215,248, and 11 CVEs.
Real-world examples illustrate risks. Scenario #1: A trusted vendor's compromise introduces malware during upgrades, as in the 2019 SolarWinds attack affecting ~18,000 organizations. Scenario #2: Compromised vendors act maliciously under conditions, like the 2025 Bybit theft of $1.5 billion via wallet software supply chain attack. Scenario #3: The 2025 Shai-Hulud npm worm self-propagated by seeding malicious packages, exfiltrating data to GitHub, and auto-pushing malware using stolen tokens, impacting over 500 packages and targeting developers. Scenario #4: Component flaws with elevated privileges lead to severe impacts, such as accidental coding errors or intentional backdoors. Examples include CVE-2017-5638 (Struts 2 remote code execution linked to breaches) and CVE-2021-44228 (Log4Shell, enabling ransomware and cryptomining).
Prevention requires robust patch and change management. Generate and manage a Software Bill of Materials (SBOM) centrally, tracking all dependencies transitively. Reduce attack surface by removing unused components. Continuously inventory versions using tools like OWASP Dependency-Track, OWASP Dependency-Check, and Retire.js. Monitor CVE, NVD, and OSV for vulnerabilities via automated software composition analysis and SBOM tools; subscribe to alerts. Source components from trusted origins over secure links, preferring signed packages (see A08:2025-Software and Data Integrity Failures). Select specific versions and upgrade deliberately. Handle unmaintained components by migrating, virtual patching, or monitoring. Update CI/CD, IDEs, and tooling regularly. Deploy updates via staged rollouts or canary releases. Track changes in CI/CD, repositories, sandboxes, IDEs, SBOM tooling, artifacts, logs, integrations, and registries. Harden systems: enable MFA, lock IAM for repositories (no secrets in checks, branch protection, backups), workstations (patching, monitoring), build servers (separation of duties, signed builds, tamper-evident logs), artifacts (provenance, signing, immutability), and infrastructure as code (PRs, version control). Maintain ongoing monitoring, triaging, and updates for application lifecycles.
References include OWASP standards like Application Security Verification Standard (V15 Secure Coding and Architecture, V1 Architecture/Design/Threat Modeling), Cheat Sheets on Dependency Graph SBOM and Vulnerable Dependency Management, OWASP Dependency-Track, CycloneDX, Dependency-Check, Testing Guide (OTG-INFO-010), Virtual Patching Best Practices, and resources on insecure libraries. External sources cover CVE search, NVD, Retire.js, GitHub Advisory Database, Ruby Libraries Security Advisories, SAFECode Software Integrity Controls, and attacks like Glassworm and PhantomRaven. Mapped CWEs: CWE-447 (Use of Obsolete Function), CWE-1035 (2017 Top 10 A9), CWE-1104, CWE-1329, CWE-1357 (Reliance on Insufficiently Trustworthy Component), CWE-1395.
A04:2025 - Cryptographic Failures
A04:2025 Cryptographic Failures, ranked #4 in the OWASP Top 10 (down from previous positions), addresses vulnerabilities stemming from inadequate or improper use of cryptography. This includes the absence of cryptographic measures, deployment of weak algorithms, leakage of cryptographic keys, and associated errors. Key Common Weakness Enumerations (CWEs) linked to this risk are CWE-327 (Use of a Broken or Risky Cryptographic Algorithm), CWE-331 (Insufficient Entropy), CWE-1241 (Use of Predictable Algorithm in Random Number Generator), and CWE-338 (Use of Cryptographically Weak Pseudo-Random Number Generator). The category emphasizes that all data in transit should be encrypted at the transport layer (OSI Layer 4), leveraging modern CPU accelerations like AES instructions and simplified certificate management via services such as LetsEncrypt.org or cloud vendor tools. Beyond transport, sensitive data at rest and in transit (at the application layer, OSI Layer 7) requires additional encryption, particularly for passwords, credit card numbers, health records, personal information, and business secrets, to comply with regulations like GDPR or PCI DSS. Common issues include using outdated algorithms, default or weak keys, improper key management, hardcoded keys in repositories, missing security headers, invalid certificate validation, insecure initialization vectors (IVs), reuse of IVs, insecure modes like ECB, using passwords as keys without derivation functions, insufficient randomness, deprecated hashes (e.g., MD5, SHA1), exploitable error messages (e.g., padding oracle attacks), and potential algorithm downgrades.
Several factors heighten the risk, including reliance on weak pseudo-random number generators (PRNGs) with predictable algorithms or low entropy, as seen in CWEs like CWE-338 and CWE-331. Other contributors are inadequate encryption strength (CWE-326), missing cryptographic steps (CWE-325), key management errors (CWE-320), hardcoded keys (CWE-321), and improper certificate trust chains (CWE-296). Data classification failures lead to unnecessary storage of sensitive information, while configurations may omit enforced encryption, such as lacking HTTP security directives or supporting weak protocols. Randomness issues arise from unseeded or predictably seeded PRNGs (CWE-337, CWE-335), and modes like CBC without random IVs (CWE-329) or authenticated encryption increase exposure. The score table indicates high incidence (max 13.77%, avg 3.80%) across 32 CWEs, with 1,665,348 occurrences and 2,185 associated CVEs, reflecting broad prevalence and potential for weighted exploits (avg 7.23) and impact (avg 3.90).
In Scenario #1, a site fails to enforce TLS or supports weak encryption, allowing an attacker on an insecure network to downgrade HTTPS to HTTP, intercept session cookies, and replay them to hijack authenticated sessions, potentially accessing or modifying private data, or altering transactions like money transfers. Scenario #2 involves a password database using unsalted or simple hashes, where a file upload vulnerability enables retrieval of the database; attackers then use rainbow tables or GPU cracking to expose hashes, especially if salts are predictable or functions are weak.
To mitigate, classify and label data to identify sensitivity per laws or needs, and store sensitive keys in hardware or cloud-based HSMs. Use trusted cryptographic implementations, avoid storing sensitive data unnecessarily through tokenization or truncation, and encrypt all sensitive data at rest. Employ strong, up-to-date algorithms and protocols (TLS 1.2+, forward secrecy, no CBC), enforce HSTS for HTTPS, and disable caching for sensitive responses across CDNs, servers, and applications like Redis. Avoid unencrypted protocols (e.g., FTP, STARTTLS, SMTP for confidential data). For passwords, use adaptive, salted hashing with high work factors like Argon2, yescrypt, scrypt, or PBKDF2-HMAC-SHA-512; for legacy systems, consult OWASP Password Storage Cheat Sheet for bcrypt. Generate IVs appropriately (e.g., via CSPRNG for modes requiring it, never reuse with fixed keys), always use authenticated encryption, and derive keys from passwords via proper functions. Ensure cryptographic randomness is unseeded or securely seeded, avoid deprecated functions (MD5, SHA1, CBC, PKCS#1 v1.5), and review configurations with specialists or tools. Prepare for post-quantum cryptography (PQC) by 2030, per ENISA guidelines.
References include OWASP Proactive Controls on cryptography, ASVS sections V11 (Cryptography), V12 (Secure Communication), and V14 (Data Protection); cheat sheets on Transport Layer Protection, User Privacy Protection, Password Storage, Cryptographic Storage, and HSTS; Testing Guide for weak cryptography; and external resources like ENISA's PQC roadmap and NIST's post-quantum standards. The mapped CWEs (32 total) cover issues like weak password encoding (CWE-261), cleartext transmission (CWE-319), key expiration misuse (CWE-324), and algorithm downgrades (CWE-757), providing a comprehensive framework for identification and remediation.
A05:2025 - Injection
A05:2025 - Injection is ranked #5 in the OWASP Top 10 for 2025, having dropped from #3 in the previous edition. It is positioned between A04:2025-Cryptographic Failures and A06:2025-Insecure Design. Injection vulnerabilities are among the most prevalent and tested categories, with 100% of applications examined for some form of injection. The category encompasses 37 Common Weakness Enumerations (CWEs), making it the leader in CVE count with 62,445 total CVEs reported. Notably, Cross-site Scripting (CWE-79) accounts for over 30,000 CVEs, while SQL Injection (CWE-89) contributes more than 14,000. The high volume of lower-impact XSS incidents reduces the average weighted impact of the category, as indicated by a score of 4.32 on average weighted impact and 7.15 on average weighted exploit, despite a maximum incidence rate of 13.77% and full coverage in testing (100% max coverage, 42.93% average coverage). A total of 1,404,249 occurrences have been documented across these CWEs.
Injection vulnerabilities arise when untrusted user input is improperly handled and sent to an interpreter—such as a browser, database, or command line—causing the interpreter to execute parts of that input as commands. Applications are susceptible when user-supplied data lacks validation, filtering, or sanitization; when dynamic queries or non-parameterized calls without context-aware escaping are used; when unsanitized data is incorporated into object-relational mapping (ORM) search parameters to access sensitive records; or when hostile data is directly concatenated into SQL, commands, or stored procedures. Common types include SQL, NoSQL, OS command, ORM, LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. Detection involves source code review combined with automated testing, including fuzzing of all inputs such as parameters, headers, URLs, cookies, JSON, SOAP, and XML. Integrating Static (SAST), Dynamic (DAST), and Interactive (IAST) tools into CI/CD pipelines aids in identifying these flaws pre-deployment. A related emerging risk involves Large Language Models (LLMs), covered under LLM01:2025 Prompt Injection in the OWASP LLM Top 10.
Prevention centers on separating data from commands and queries. The optimal approach is using safe APIs that provide parameterized interfaces or migrating to ORMs, thereby avoiding direct interpreter use. Even stored procedures may pose risks if they concatenate queries or execute hostile data via mechanisms like EXECUTE IMMEDIATE. When separation is impossible, positive server-side input validation can mitigate threats, though it is incomplete for applications requiring special characters, such as text areas or mobile APIs. For remaining dynamic queries, escape special characters using interpreter-specific syntax. However, SQL elements like table or column names cannot be escaped, rendering user-supplied structure names hazardous, particularly in report-writing software. These manual techniques are error-prone due to the complexity of parsing and escaping strings, and they lack robustness against system changes.
Example scenarios illustrate real-world exploitation. In the first, an application constructs a vulnerable SQL query by concatenating user input: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; An attacker inputs ' OR '1'='1 via the 'id' parameter (e.g., http://example.com/app/accountView?id=' OR '1'='1), altering the query to return all accounts records. More severe attacks could modify, delete data, or invoke stored procedures. The second scenario involves blind trust in frameworks like Hibernate Query Language (HQL): Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); An attacker uses ' OR custID IS NOT NULL OR custID=' to bypass filters and retrieve all accounts, demonstrating unauthorized data access despite HQL's reduced dangerous functions. The third example shows direct passage of user input to OS commands: String cmd = "nslookup " + request.getParameter("domain"); Runtime.getRuntime().exec(cmd); An attacker inputs example.com; cat /etc/passwd to execute arbitrary server commands.
Key prevention resources include the OWASP Proactive Controls for Secure Database Access, ASVS section on Input Validation and Encoding, and various Cheat Sheets such as Injection Prevention, SQL Injection Prevention, Injection Prevention in Java, Query Parameterization, and Automated Threats to Web Applications – OAT-014. Additional references cover Server-side Template Injection and fuzzing resources. The category maps to 37 CWEs, including CWE-20 (Improper Input Validation), CWE-74 (Improper Neutralization of Special Elements), CWE-78 (OS Command Injection), CWE-89 (SQL Injection), CWE-79 (XSS), and others up to CWE-917 (Expression Language Injection).
A06:2025 - Insecure Design
Insecure Design ranks #6 in the OWASP Top 10:2025, down two spots from #4 in the prior edition. The shift reflects improvements in threat modeling and secure design practices, as well as the rise of Security Misconfiguration (#2) and Software Supply Chain Failures (#3). Introduced in 2021, this category captures design and architectural flaws, including business logic errors such as undefined state changes. It emphasizes pre-coding activities like requirements analysis and design under Secure by Design principles. Key CWEs include CWE-256 (Unprotected Storage of Credentials), CWE-269 (Improper Privilege Management), CWE-434 (Unrestricted Upload of File with Dangerous Type), CWE-501 (Trust Boundary Violation), and CWE-522 (Insufficiently Protected Credentials).
The Score Table shows 39 CWEs mapped, with a maximum incidence rate of 22.18%, average incidence rate of 1.86%, maximum coverage of 88.76%, average coverage of 35.18%, average weighted exploit of 6.96, average weighted impact of 4.05, total occurrences of 729,882, and total CVEs of 7,647.
Insecure Design encompasses weaknesses from missing or ineffective control design. It differs from insecure implementation: design flaws lack necessary controls and cannot be fixed by perfect coding, while implementations may have defects even in secure designs. A root cause is the absence of business risk profiling, leading to inadequate security levels.
Three pillars ensure secure design: Requirements and Resource Management: Collect business requirements, including confidentiality, integrity, availability, authenticity, and business logic. Assess exposure and tenant segregation. Define functional and non-functional security requirements. Budget for design, build, testing, operations, and security. Secure Design: Embed threat modeling in refinement sessions to evaluate data flows, access controls, and security measures. In user stories, map correct flows, failure states, assumptions, and validations. Document results and incentivize improvements. Secure design is a culture, not an add-on tool. Secure Development Lifecycle: Adopt secure patterns, paved-road components, tooling, threat modeling, and post-mortems. Engage security specialists early and throughout. Use the OWASP Software Assurance Maturity Model (SAMM) to structure efforts. Foster developer responsibility through awareness, risk mitigation, and security discussions.
To prevent: Establish a secure development lifecycle with AppSec professionals to evaluate and design security and privacy controls. Build and use a library of secure design patterns or paved-road components. Apply threat modeling to critical areas like authentication, access control, business logic, and key flows. Use threat modeling educationally to build security mindset. Integrate security language and controls into user stories. Add plausibility checks across application tiers (frontend to backend). Write unit and integration tests for critical flows, including use-cases and misuse-cases. Segregate tiers on system and network layers based on exposure. Segregate tenants robustly across all tiers by design.
A credential recovery workflow uses “questions and answers,” prohibited by NIST 800-63b, OWASP ASVS, and OWASP Top 10, as answers are not unique and unreliable for identity proof. Remove and replace with secure alternatives. A cinema chain offers group discounts up to fifteen attendees without deposit. Attackers exploit business logic by booking excessive seats across locations in few requests, causing financial loss. An e-commerce site lacks anti-bot measures, allowing scalpers to buy high-end video cards for resale. This harms reputation and customers. Implement anti-bot logic and rules like rejecting rapid purchases to block inauthentic transactions.
References: OWASP Cheat Sheet: Secure Design Principles, OWASP SAMM: Design | Secure Architecture, OWASP SAMM: Design | Threat Assessment, NIST – Guidelines on Minimum Standards for Developer Verification of Software, The Threat Modeling Manifesto, Awesome Threat Modeling.
The category maps to 39 CWEs, including CWE-73 (External Control of File Name or Path), CWE-183 (Permissive List of Allowed Inputs), CWE-256 (Unprotected Storage of Credentials), CWE-266 (Incorrect Privilege Assignment), CWE-269 (Improper Privilege Management), CWE-286 (Incorrect User Management), CWE-311 (Missing Encryption of Sensitive Data), CWE-312 (Cleartext Storage of Sensitive Information), CWE-313 (Cleartext Storage in a File or on Disk), CWE-316 (Cleartext Storage of Sensitive Information in Memory), CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')), CWE-382 (J2EE Bad Practices: Use of System.exit()), CWE-419 (Unprotected Primary Channel), CWE-434 (Unrestricted Upload of File with Dangerous Type), CWE-436 (Interpretation Conflict), CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')), CWE-451 (User Interface (UI) Misrepresentation of Critical Information), CWE-454 (External Initialization of Trusted Variables or Data Stores), CWE-472 (External Control of Assumed-Immutable Web Parameter), CWE-501 (Trust Boundary Violation), CWE-522 (Insufficiently Protected Credentials), CWE-525 (Use of Web Browser Cache Containing Sensitive Information), CWE-539 (Use of Persistent Cookies Containing Sensitive Information), CWE-598 (Use of GET Request Method With Sensitive Query Strings), CWE-602 (Client-Side Enforcement of Server-Side Security), CWE-628 (Function Call with Incorrectly Specified Arguments), CWE-642 (External Control of Critical State Data), CWE-646 (Reliance on File Name or Extension of Externally-Supplied File), CWE-653 (Insufficient Compartmentalization), CWE-656 (Reliance on Security Through Obscurity), CWE-657 (Violation of Secure Design Principles), CWE-676 (Use of Potentially Dangerous Function), CWE-693 (Protection Mechanism Failure), CWE-799 (Improper Control of Interaction Frequency), CWE-807 (Reliance on Untrusted Inputs in a Security Decision), CWE-841 (Improper Enforcement of Behavioral Workflow), CWE-1021 (Improper Restriction of Rendered UI Layers or Frames), CWE-1022 (Use of Web Link to Untrusted Target with window.opener Access), and CWE-1125 (Excessive Attack Surface).
A07:2025 - Authentication Failures
Authentication Failures, ranked #7 in the OWASP Top 10 for 2025, involves vulnerabilities where attackers trick systems into accepting invalid or incorrect users as legitimate. This category, encompassing 36 Common Weakness Enumerations (CWEs) such as CWE-259 (Use of Hard-coded Password), CWE-287 (Improper Authentication), CWE-384 (Session Fixation), and CWE-798 (Use of Hard-coded Credentials), reflects persistent challenges despite standardized frameworks. The vulnerability arises when applications fail to secure authentication processes, enabling attacks like credential stuffing, brute force, or session mismanagement. Data shows a maximum incidence rate of 15.80%, average of 2.92%, and 1,120,673 occurrences across 7,147 CVEs, with full coverage of CWEs but only 37.14% average coverage in practice.
Key factors include weak or default passwords (e.g., "Password1" or "admin/admin"), inadequate protections against automated attacks like credential stuffing or hybrid password attacks (e.g., incrementing passwords like "Password1!" to "Password2!"), and poor session management, such as reusing session identifiers or failing to invalidate sessions post-logout or inactivity. Other contributors are ineffective multi-factor authentication (MFA), weak credential recovery processes (e.g., knowledge-based answers), insecure password storage (plain text, encrypted, or weakly hashed), and exposure of session identifiers in URLs or hidden fields. Applications allowing account creation with breached credentials or lacking proper credential scope validation (e.g., for JWTs) further exacerbate risks.
Credential Stuffing and Hybrid Attacks: Attackers use breached username-password lists for automated logins, enhanced by hybrid tactics like incrementing passwords (e.g., "Winter2025" to "Winter2026" or "ILoveMyDog6" to "ILoveMyDog7"). Without defenses against bots or scripts, applications become password oracles, confirming valid credentials for unauthorized access. Reliance on Single-Factor Passwords: Outdated practices like mandatory password rotation and complexity requirements lead to password reuse and weakness, enabling attacks. NIST 800-63 guidelines recommend shifting to MFA to mitigate this. Session Management Flaws: Improper timeouts allow sessions to persist after users log out (e.g., closing a browser tab on a public computer). In SSO environments, single logout (SLO) failures let attackers access accounts in other systems, such as mail or documents, if the browser retains authentication.
To prevent these issues, enforce MFA to block automated attacks and stolen credential reuse. Promote password managers for stronger user choices and avoid default credentials, especially for admins. Implement checks against top 10,000 worst passwords and breached credential lists (e.g., via haveibeenpwned.com) during account creation or changes. Align policies with NIST 800-63b guidelines for memorized secrets, avoiding forced rotations unless a breach is suspected. Harden pathways against enumeration by using uniform error messages (e.g., "Invalid username or password"). Limit failed login attempts with delays, log failures, and alert on detected attacks without causing denial-of-service. Use secure session managers generating high-entropy, random IDs stored in cookies (not URLs), invalidated on logout, idle, or timeout. Prefer trusted third-party systems for authentication and verify credential scopes (e.g., JWT aud/iss claims).
The page references NIST 800-63b (section 5.1.1 on Memorized Secrets) and haveibeenpwned.com for breach checks. It maps 36 CWEs, including CWE-258 (Empty Password in Configuration File), CWE-288 (Authentication Bypass Using an Alternate Path), CWE-307 (Improper Restriction of Excessive Authentication Attempts), CWE-521 (Weak Password Requirements), CWE-613 (Insufficient Session Expiration), CWE-640 (Weak Password Recovery Mechanism), and CWE-1393 (Use of Default Password), among others focused on authentication bypass, weak credentials, and session issues.
A08:2025 - Software or Data Integrity Failures
Software or Data Integrity Failures occur when code and infrastructure fail to protect against invalid or untrusted code or data being treated as trusted and valid. This vulnerability arises from assumptions about software updates and critical data without verifying integrity. Key examples include applications relying on plugins, libraries, or modules from untrusted sources, repositories, or content delivery networks (CDNs). Insecure CI/CD pipelines that do not consume or provide software integrity checks can lead to unauthorized access, insecure or malicious code, or system compromise. Additionally, CI/CD pipelines pulling code or artifacts from untrusted sources without verification (e.g., checking signatures) are vulnerable. Auto-update functionality in applications that downloads updates without sufficient integrity verification allows attackers to upload malicious updates for distribution. Insecure deserialization of objects or data encoded in modifiable structures also poses a risk.
The vulnerability stems from failures in maintaining trust boundaries and verifying the integrity of software, code, and data artifacts. Notable Common Weakness Enumerations (CWEs) include CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes), and CWE-502 (Deserialization of Untrusted Data). The score table indicates 14 CWEs mapped, with a maximum incidence rate of 8.98%, an average incidence rate of 2.75%, maximum coverage of 78.52%, average coverage of 45.49%, average weighted exploit of 7.11, average weighted impact of 4.79, total occurrences of 501,327, and 3,331 total CVEs. These metrics highlight the prevalence and potential impact of such failures.
Inclusion of Web Functionality from an Untrusted Source: A company uses an external service provider with a DNS mapping (e.g., myCompany.SupportProvider.com to support.myCompany.com), causing authentication cookies from myCompany.com to be sent to the untrusted provider. Attackers with access to the provider’s infrastructure can steal cookies and perform session hijacking. Update without Signing: Devices like home routers, set-top boxes, and firmware lack signed updates, making them targets for attackers. Unsigned firmware increases risks, with remediation often limited to future versions as older ones age out. Use of Package from an Untrusted Source: A developer downloads an unsigned package from a website instead of a trusted package manager, introducing malicious code due to the lack of integrity checks. Insecure Deserialization: A React application serializes user state and passes it to Spring Boot microservices. An attacker modifies the serialized data (e.g., Java object signature "rO0" in base64) and uses tools like the Java Deserialization Scanner to achieve remote code execution.
To mitigate Software or Data Integrity Failures: Use digital signatures or similar mechanisms to verify software or data originates from the expected source and has not been altered. Restrict libraries and dependencies (e.g., npm, Maven) to trusted repositories; for high-risk profiles, host an internal vetted repository. Implement a review process for code and configuration changes to prevent malicious code or configurations in pipelines. Secure CI/CD pipelines with proper segregation, configuration, and access controls to ensure code integrity during build and deploy processes. Avoid using unsigned or unencrypted serialized data from untrusted clients without integrity checks or digital signatures to detect tampering or replay.
OWASP Cheat Sheet: Software Supply Chain Security, OWASP Cheat Sheet: Infrastructure as Code, OWASP Cheat Sheet: Deserialization, SAFECode Software Integrity Controls, A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack, CodeCov Bash Uploader Compromise, Securing DevOps by Julien Vehent, Insecure Deserialization by Tenendo.
This category, ranked #8, focuses on integrity verification at a lower level than Software Supply Chain Failures, emphasizing trust boundary maintenance. Includes CWE-345 (Insufficient Verification of Data Authenticity), CWE-353 (Missing Support for Integrity Check), CWE-426 (Untrusted Search Path), CWE-427 (Uncontrolled Search Path Element), CWE-494 (Download of Code Without Integrity Check), CWE-502 (Deserialization of Untrusted Data), CWE-506 (Embedded Malicious Code), CWE-509 (Replicating Malicious Code), CWE-565 (Reliance on Cookies without Validation and Integrity Checking), CWE-784 (Reliance on Cookies without Validation and Integrity Checking in a Security Decision), CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), CWE-830 (Inclusion of Web Functionality from an Untrusted Source), CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes), and CWE-926 (Improper Export of Android Application Components).
A09:2025 - Security Logging and Alerting Failures
This category is underrepresented in data due to its difficulty in testing and minimal CVE representation (723 CVEs). It includes issues like improper output neutralization for logs (CWE-117), insertion of sensitive data into logs (CWE-532), and insufficient logging (CWE-778). Score metrics show 5 CWEs mapped, with a max incidence rate of 11.33%, average 3.91%, max coverage 85.96%, average 46.48%, average weighted exploit 7.19, weighted impact 2.65, total occurrences 260,288, and total CVEs 723. Community surveys voted it into the list for the third time, highlighting its impact on visibility, incident alerting, and forensics despite low data visibility.
In Scenario #1, a children's health plan provider's website operator undetected a breach due to absent logging and monitoring, allowing an attacker to access and modify over 3.5 million sensitive health records since 2013, discovered only after an external report. Scenario #2 involved a major Indian airline's breach of over ten years of passenger data, including passports and credit cards, at a third-party cloud provider, notified belatedly. Scenario #3 saw a European airline suffer a GDPR-reportable breach from payment vulnerabilities, harvesting over 400,000 customer records and incurring a 20 million pound fine.
Developers should log all security control failures (e.g., login, access control, input validation) with user context for forensic analysis, ensuring logs are in consumable formats and encoded to prevent injections. Every security control success or failure must be logged, with audit trails using integrity controls like append-only tables. Transactions throwing errors should rollback and fail closed. Issue alerts for suspicious application or user behavior, guided by developer documentation or systems. DevSecOps and security teams must establish monitoring, alerting use cases, and playbooks for quick SOC responses. Use honeytokens as traps in databases or data to generate low-false-positive alerts on access. Optional behavior analysis or AI can reduce false positives. Adopt incident response plans like NIST 800-61r2, educating developers on attacks. Tools like OWASP ModSecurity Core Rule Set, ELK stack, or commercial observability products aid in logging, alerting, and real-time response.
Key references include OWASP Proactive Controls: C9: Implement Logging and Monitoring; OWASP Application Security Verification Standard: V16 Security Logging and Error Handling; OWASP Cheat Sheet: Application Logging Vocabulary; OWASP Cheat Sheet: Logging; NIST SP 1800-11, -25, -26 on data integrity for ransomware and events; and a real-world Snowflake breach example.
Mapped CWEs are CWE-117 (Improper Output Neutralization for Logs), CWE-221 (Information Loss of Omission), CWE-223 (Omission of Security-relevant Information), CWE-532 (Insertion of Sensitive Information into Log File), and CWE-778 (Insufficient Logging). The category emphasizes alerting for action on events, retaining #9 position with a name tweak to highlight alerting.
A10:2025 - Mishandling of Exceptional Conditions
Mishandling exceptional conditions occurs when software fails to prevent, detect, or respond appropriately to unusual or unpredictable situations. This leads to crashes, unexpected behavior, and security vulnerabilities. Exceptional conditions may stem from missing or incomplete input validation, late or high-level error handling, unexpected environmental states (e.g., memory, privilege, or network issues), inconsistent exception handling, or unhandled exceptions that leave the system in an unknown state. Any uncertainty about the next instruction indicates mishandling.
Consequences include logic bugs, overflows, race conditions, fraudulent transactions, and issues with memory, state, resources, timing, authentication, and authorization. These can compromise confidentiality, availability, and integrity. Attackers exploit flawed error handling to trigger such vulnerabilities.
Anticipate exceptional conditions and handle them at the point of origin. Catch every possible error, respond meaningfully (inform users, log events, alert if needed), and recover safely. Implement a global exception handler for uncaught errors. Use monitoring and observability to detect repeated errors or attack patterns, enabling automated responses. Fail closed: roll back incomplete transactions to avoid unrecoverable states. Apply rate limiting, resource quotas, and throttling to prevent resource exhaustion and denial-of-service conditions. Limit repeated error messages to statistical summaries to protect logging and monitoring (see A09:2025 Security Logging & Alerting Failures). Enforce strict input validation with sanitization or escaping for hazardous characters. Centralize error handling, logging, monitoring, and alerting in a single, consistent mechanism. Establish organization-wide policies for exceptional-condition handling to simplify code review and auditing. Incorporate threat modeling, secure design reviews, code reviews, static analysis, stress testing, performance testing, and penetration testing.
Resource Exhaustion (Denial of Service) – An application catches file-upload exceptions but fails to release resources, locking resources with each exception until exhaustion. Sensitive Data Exposure – Database errors leak full system details to users; attackers force errors to gather reconnaissance data for refined SQL injection. State Corruption in Financial Transactions – Network disruptions interrupt multi-step transactions; without proper rollback (failing closed), attackers exploit partial commits to drain accounts or create race conditions allowing duplicate transfers.
OWASP MASVS-RESILIENCE, OWASP Cheat Sheet: Logging, OWASP Cheat Sheet: Error Handling, OWASP ASVS: V16.5 Error Handling, OWASP Testing Guide: 4.8.1 Testing for Error Handling, Best practices for exceptions (Microsoft, .NET), Clean Code and the Art of Exception Handling (Toptal), General error handling rules (Google for Developers), Example of real-world mishandling.
CWE-209, CWE-215, CWE-234, CWE-235, CWE-248, CWE-252, CWE-274, CWE-280, CWE-369, CWE-390, CWE-391, CWE-394, CWE-396, CWE-397, CWE-460, CWE-476, CWE-478, CWE-484, CWE-550, CWE-636, CWE-703, CWE-754, CWE-755, CWE-756.
Comments
Post a Comment