OWASP Top Ten 2025: The New Vulnerabilities Threatening Your Web Applications

OWASP Top Ten 2025: The New Vulnerabilities Threatening Your Web Applications

On November 6, 2025, OWASP (Open Web Application Security Project) published the candidate version of its Top Ten 2025, the reference document on web application security risks. This major update, coming 4 years after the 2021 version, reflects the rapid evolution of threats and development practices.

Two new categories make their appearance, some vulnerabilities are consolidated, and the ranking has been reorganized to better reflect the reality of risks in 2025. For developers, security architects, and technical managers, understanding these changes is crucial to protecting their applications.

In this article, we will explore the OWASP Top Ten 2025 in depth, analyze the changes, compare with the previous version, and provide practical recommendations — SAST/DAST tooling, CI/CD integration, penetration testing, and governance — to secure your web applications.

What is the OWASP Top Ten?

The OWASP Top Ten is an industry standard publication that identifies and documents the ten most critical application security risks. Based on real data from thousands of tested applications, it serves as a reference for:

• Developers who want to understand risks to avoid
• Security teams that evaluate applications
• Technical managers who prioritize security efforts
• Auditors who verify compliance

2025 Methodology:

• Analysis of thousands of applications tested between 2021 and 2025
• Data from multiple sources: automatic scanners, manual tests, incident reports
• 3.73% of tested applications present at least one Top Ten vulnerability

The Top Ten 2025: Overview

Here is the complete ranking of the 10 most critical risks in 2025:

1. A01:2025 - Broken Access Control (3.73% of applications)
2. A02:2025 - Security Misconfiguration (3.00% of applications)
3. A03:2025 - Software Supply Chain Failures (NEW)
4. A04:2025 - Cryptographic Failures (3.80% of applications)
5. A05:2025 - Injection (high prevalence)
6. A06:2025 - Insecure Design (3.50% of applications)
7. A07:2025 - Authentication Failures (36 weaknesses identified)
8. A08:2025 - Software and Data Integrity Failures (unchanged)
9. A09:2025 - Security Logging and Monitoring Failures (name modified)
10. A10:2025 - Improper Error and Exception Handling (NEW — 24 weaknesses)

Detailed Analysis: Major Changes

Comparison of prevalence rates for the 4 OWASP categories with explicitly stated data in the 2025 release candidate

A01:2025 - Broken Access Control (Still #1)

Position: 1st place (unchanged since 2021)

Prevalence: 3.73% of tested applications present at least one of the 40 weaknesses in this category.

Why is it still #1? Access control remains the most widespread security problem because it is complex to implement correctly and often neglected during development phases.

The most frequent attack vector is IDOR (Insecure Direct Object Reference): an attacker simply changes an ID in the URL (/api/orders/1234 → /api/orders/1235) to access another user's data. Without systematically verifying that the authenticated user is indeed the owner of the requested resource, the entire database can be exposed. E-commerce platforms, healthcare systems, and financial services have suffered massive data breaches through this trivial-to-exploit but frequently overlooked vector.

Examples of weaknesses:

• Horizontal access: A user can access another user's data at the same privilege level
• Vertical access: A user can access features reserved for administrators
• Bypassing access controls via modified parameters
• Unauthenticated access to sensitive resources

Protection measures:

• Implement Role-Based Access Control (RBAC)
• Verify permissions on each request, not just at authentication
• Use proven security frameworks
• Regularly test access controls with tools like OWASP ZAP

A02:2025 - Security Misconfiguration (Rising)

Position: 2nd place (up from 5th place in 2021)

Prevalence: 3.00% of affected applications

Why this rise? The explosion of cloud deployments, containers, and microservices has multiplied attack surfaces and opportunities for misconfiguration. Each new service deployed with default settings is a potential entry point for attackers.

Examples of problems:

• Services running with insecure default configurations
• Error messages that reveal sensitive system information
• Debug features enabled in production environments
• Missing security headers (CSP, HSTS, X-Frame-Options, etc.)
• Databases exposed publicly without authentication

Protection measures:

• Use secure default configurations across all environments
• Automate configuration checks (Infrastructure as Code)
• Disable all unnecessary features and services
• Implement a security hardening process
• Regularly scan configurations with tools like Snyk, Checkmarx, or Trivy

A03:2025 - Software Supply Chain Failures (NEW)

Position: 3rd place (new category)

Why this new category? Supply chain attacks have exploded in recent years. Major incidents like SolarWinds, Log4j, and malicious npm packages have demonstrated the deep vulnerability hidden within software dependencies.

The XZ Utils incident of 2024 perfectly illustrates this risk: a malicious contributor spent two years earning the trust of the open-source community before introducing a backdoor into a compression library present in virtually all Linux distributions. Had the flaw not been discovered in time, millions of servers could have been compromised. This type of attack exploiting the trust placed in dependencies is precisely what OWASP targets with this new category. To learn how to automate the detection of these risks in your daily workflow, see our guide on automating security in the CI/CD pipeline.

What this category encompasses:

• Vulnerabilities in dependencies: Unupdated third-party libraries
• Unverified components: npm, PyPI, Maven packages not validated
• Compromised build systems: Unsecured CI/CD toolchains
• Distribution infrastructure: Compromised Docker registries, npm repositories
• Transitive dependencies: Vulnerabilities in dependencies of your dependencies

Examples of recent attacks:

• Log4j (2021): Critical vulnerability in a Java library used by millions of applications
• Malicious npm packages: Popular packages compromised to steal credentials
• SolarWinds (2020): Compromise of a monitoring tool used by thousands of organizations

Protection measures:

• Regular dependency audit: Use tools like Snyk, Dependabot, WhiteSource
• Signing and verification: Verify package integrity before installation
• Minimize dependencies: Only use necessary and actively maintained packages
• Proactive updates: Keep dependencies current with security patches
• SBOM (Software Bill of Materials): Document all application dependencies
• Automatic scanning: Integrate scanning into your CI/CD pipeline

Recommended tools:

# Simplified example — npm audit
npm audit

# Simplified example — Snyk
snyk test

# Simplified example — Dependabot (GitHub)
# Automatic configuration in .github/dependabot.yml

A04:2025 - Cryptographic Failures (Declining)

Position: 4th place (down from 2nd place in 2021)

Prevalence: 3.80% of affected applications

Why this decline? Developers are better trained on cryptography, and modern frameworks use secure algorithms by default. However, mistakes remain frequent in custom implementations and legacy systems.

Examples of problems:

• Using weak hashing algorithms (MD5, SHA-1) for sensitive data
• Weak or hardcoded encryption keys
• Incorrect secret management (API keys, tokens stored in plaintext)
• Expired or self-signed SSL/TLS certificates
• Encryption using obsolete algorithms (DES, RC4)

Protection measures:

• Use modern algorithms (AES-256, SHA-256, RSA-2048+)
• Never hardcode secrets in source code
• Use secrets managers (AWS Secrets Manager, HashiCorp Vault)
• Renew SSL/TLS certificates regularly with automated tooling (Let's Encrypt)
• Validate certificates on both server and client sides

A05:2025 - Injection (Declining but Still Critical)

Position: 5th place (down from 3rd place in 2021)

Why this decline? The widespread adoption of modern frameworks with built-in protection (ORMs, prepared statements) has reduced injection vulnerabilities. However, attacks remain frequent in legacy codebases and custom implementations.

Types of injection:

• SQL Injection: Malicious SQL code injection
• NoSQL Injection: Injection into NoSQL databases
• Command Injection: Execution of system commands
• LDAP Injection: Injection into LDAP directories
• XSS (Cross-Site Scripting): JavaScript script injection

Stored XSS represents a particularly dangerous vector: an attacker injects a malicious script into a form field (username, comment, product description) that the application stores in the database. Every visitor who subsequently views that page executes the script unknowingly, enabling session cookie theft, redirection to phishing sites, or silent exfiltration of sensitive data. Multi-tenant SaaS applications that allow content customization by clients are especially exposed.

Protection measures:

• Use parameterized queries (prepared statements)
• Use ORM (Object-Relational Mapping) with automatic escaping
• Validate and sanitize all user inputs
• Use allowlists rather than denylists
• Implement Content Security Policy (CSP) to prevent XSS

Example of secure code:

// ❌ VULNERABLE — SQL Injection (simplified example)
const query = `SELECT * FROM users WHERE id = ${userId}`;

// ✅ SECURE — Parameterized query
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);

A06:2025 - Insecure Design (New Approach)

Position: 6th place (down from 4th place)

Prevalence: 3.50% of applications

Major change: This category now emphasizes threat modeling and secure design from the start, rather than specific technical vulnerabilities found later in the SDLC.

Secure design principles:

• Threat modeling: Identify threats before you start building
• Defense in depth: Multiple independent layers of security
• Principle of least privilege: Grant only the permissions strictly necessary
• Fail-secure: In case of error, the system must deny access by default
• Separation of concerns: Isolate critical components from each other

Protection measures:

• Conduct Security Design Reviews (SDR) before development begins
• Use threat modeling frameworks (STRIDE, DREAD, PASTA)
• Implement security controls from the design phase
• Train developers on security principles and threat modeling

A07:2025 - Authentication Failures (Name Modified)

Position: 7th place (unchanged)

Change: The name was modified from "Identification and Authentication Failures" to "Authentication Failures" to more accurately reflect the 36 weaknesses now documented in this category.

Examples of problems:

• Weak passwords accepted without enforcement
• No protection against brute force attacks
• Incorrect session management (tokens not invalidated on logout)
• Multi-factor authentication (MFA) not implemented
• Insecure password recovery mechanisms

Protection measures:

• Implement strong password policies (length over complexity)
• Limit login attempts with rate limiting and account lockout
• Use MFA (Multi-Factor Authentication) for all sensitive operations
• Invalidate sessions after logout or expiration
• Use secure tokens (JWT with short expiration, refresh token rotation)

A08:2025 - Software and Data Integrity Failures (Unchanged)

Position: 8th place (unchanged)

Focus: This category focuses on the failure to maintain trust boundaries and verify the integrity of software, code, and data artifacts throughout the development and deployment lifecycle.

Examples of problems:

• Software updates distributed without digital signatures
• Data integrity not validated before processing
• Code not verified before deployment to production
• No integrity verification for downloaded files or artifacts

Protection measures:

• Digitally sign all software updates and release artifacts
• Verify data integrity with checksums (SHA-256) at each pipeline stage
• Implement integrity controls for critical configuration files
• Use trusted, verified registries for packages and container images

A09:2025 - Security Logging and Monitoring Failures (Name Modified)

Position: 9th place (unchanged)

Change: The name was updated to emphasize the importance of the alerting functionality necessary to trigger appropriate action on relevant security events — logging without alerting is insufficient.

Examples of problems:

• Critical security events not logged (failed logins, permission escalations)
• Logs containing sensitive information (passwords, tokens, PII)
• No alerts for suspicious events or anomalous patterns
• Logs not centralized, making incident investigation impossible

Protection measures:

• Log all critical events (authentication attempts, access to sensitive resources, errors)
• Never log sensitive information in plaintext
• Implement an alert system for suspicious patterns (SIEM integration)
• Centralize logs (ELK Stack, Splunk, Datadog, Grafana Loki)
• Set up appropriate log retention policies (minimum 1 year for compliance)

A10:2025 - Improper Error and Exception Handling (NEW)

Position: 10th place (new category)

Prevalence: 24 weaknesses identified

Why this new category? Incorrect error and exception handling can reveal sensitive system information to attackers, allow security bypasses through unexpected application states, or cause denial of service when unhandled exceptions crash services.

Examples of problems:

• Error messages that expose database structure, stack traces, or internal paths
• Generic catch blocks that silently mask all errors
• Unhandled exceptions that cause service crashes (denial of service)
• Business logic that fails open instead of fail-secure
• Stack traces and debug information exposed to end users

Protection measures:

• Never expose technical details in user-facing error messages
• Handle each specific exception type explicitly and appropriately
• Implement fail-secure behavior (when in doubt, deny access)
• Log detailed error information server-side only, never in responses
• Test all error scenarios as part of your standard QA process

Example of secure code:

// ❌ VULNERABLE — Revealing error message (simplified example)
catch (error) {
  res.status(500).send(`SQL Error: ${error.message}`);
}

// ✅ SECURE — Generic message for user, detailed log server-side
catch (error) {
  logger.error('Database error', { error, userId, action });
  res.status(500).send('An error occurred. Please try again.');
}

Comparison 2021 vs 2025: Major Changes

Flow diagram showing progression, regression and new categories between the 2021 and 2025 editions of the OWASP Top Ten

Categories removed from Top Ten 2021:

• A10:2021 - Server-Side Request Forgery (SSRF): Integrated into other categories

Action Plan: How to Protect Your Application

Concrete action pipeline: audit, prioritization, implementing controls and DevSecOps training

Step 1: Security Audit

Immediate actions:

1. Perform a security scan with OWASP ZAP or Burp Suite
2. Audit all your dependencies with Snyk or Dependabot
3. Check your configurations (security headers, SSL/TLS, etc.)
4. Review your access control implementations

Step 2: Prioritization

Recommended priority order:

1. A01 - Access Control: Critical impact, highest prevalence
2. A03 - Supply Chain: New major risk requiring immediate attention
3. A02 - Configuration: Quick wins with high security impact
4. A05 - Injection: High prevalence, critical impact
5. A10 - Exception Handling: New, often quick to fix

Step 3: Implementation of Controls

Recommended tools:

• OWASP ZAP: Vulnerability scanner (free, open source)
• Snyk: Dependency audit and real-time monitoring
• SonarQube: Static code analysis
• Burp Suite: Professional penetration testing
• Dependabot: Automatic dependency updates (GitHub-native)

Step 4: Training and Awareness

Actions:

• Train the entire team on the OWASP Top Ten 2025 specifics
• Integrate security into the development process (DevSecOps)
• Conduct security-focused code reviews on every pull request
• Organize regular security awareness sessions (at least quarterly)

How to Integrate the OWASP Top Ten 2025 into Your CI/CD Pipeline?

Complete DevSecOps pipeline: SAST on commit, DAST after build, SBOM audit before deployment, quarterly pentest

The DevSecOps approach consists of shifting security as early as possible in the development lifecycle (shift left), rather than applying it only at the end of the chain. This integration relies on two complementary types of analysis that every mature CI/CD pipeline should embed.

Static Analysis (SAST — Static Application Security Testing) examines source code without executing it. Tools like SonarQube or Semgrep detect potential SQL injections, poor cryptographic practices, or access control flaws directly in the code, before the build phase even begins. Git pipeline integration enables automatic blocking of any pull request presenting critical vulnerabilities, reducing the cost of remediation by a factor of 10 compared to detecting issues in production.

Dynamic Analysis (DAST — Dynamic Application Security Testing) tests the running application by simulating real attacks against a staging environment. OWASP ZAP or Burp Suite send malformed requests, attempt injections, and verify runtime security configurations. These tests uncover vulnerabilities that static analysis cannot detect — particularly runtime configuration issues related to service orchestration or missing HTTP response headers.

Combining SAST + DAST + automated dependency auditing forms the defensive triad recommended by OWASP 2025. To avoid the most common pitfalls when setting up this type of automation, our guide on the time bombs of automated deployment details the critical mistakes to avoid.

Minimal GitHub Actions configuration:

# Simplified example — .github/workflows/security.yml
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SonarQube SAST
        run: sonar-scanner
  dependency-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Snyk dependency scan
        run: snyk test --severity-threshold=high

What SAST and DAST Tools Should You Use for OWASP Top Ten 2025?

Tool selection depends on your tech stack, team size, and budget. For teams getting started, OWASP ZAP (free, open source) and Semgrep (free community edition) offer an excellent value-to-effort ratio. More mature teams or those operating in regulated environments (finance, healthcare, strict GDPR compliance) will benefit from commercial solutions like Checkmarx or Veracode, which offer rules pre-mapped to each OWASP 2025 category.

A frequently overlooked approach: Interactive Application Security Testing (IAST) instruments the application from the inside to detect vulnerabilities in real time during existing functional tests. Solutions like Contrast Security identify flaws that neither SAST nor DAST detect separately, because they observe the application's internal behavior during normal execution. For Node.js applications, libraries like helmet and express-rate-limit provide the first line of defense against misconfiguration (A02) and brute force attacks (A07) — though they do not replace a full tooled audit.

Penetration Testing: Validating Your Application's Resilience

Automated tools (SAST, DAST) effectively detect known vulnerabilities and bad practices, but they do not replace manual penetration testing conducted by an expert. An experienced pentester simulates the behavior of a real attacker: they chain multiple minor vulnerabilities to escalate privileges, exploit business logic specific to your application, and search for novel flaws that automated rule sets don't cover.

The recommended frequency is at least annually, with an additional test after every major architectural change or the addition of critical features (online payments, access to personal data, third-party integrations). Reference methodologies are OWASP WSTG (Web Security Testing Guide) and PTES (Penetration Testing Execution Standard). A pentest report identifies not only the vulnerabilities present but their real-world exploitability and potential attack chains — invaluable information for prioritizing remediation based on actual risk rather than theoretical risk scores.

OWASP Top Ten 2025 Security Checklist

Mind map detailing the root causes of the 6 most critical vulnerability categories in OWASP 2025

A01 - Access Control

• RBAC (Role-Based Access Control) implemented
• Permission verification on each request (not just at login)
• Horizontal and vertical access tests performed
• Principle of least privilege applied throughout

A02 - Configuration

• Security headers configured (CSP, HSTS, X-Frame-Options, etc.)
• Generic error messages in production (no stack traces)
• Debug features disabled in all non-development environments
• Secure default configurations applied to all services

A03 - Supply Chain

• Regular dependency audit performed
• Security updates applied promptly
• SBOM (Software Bill of Materials) maintained and versioned
• Automatic scanning integrated into CI/CD

A04 - Cryptography

• Modern algorithms used (AES-256, SHA-256, RSA-2048+)
• Secrets managed via a dedicated secrets manager
• Valid and up-to-date SSL/TLS certificates
• No hardcoded secrets in source code or configuration files

A05 - Injection

• Parameterized queries used for all database operations
• ORM with automatic escaping in use
• Input validation and sanitization on all user-supplied data
• CSP implemented to prevent XSS attacks

A06 - Design

• Threat modeling performed before each major feature
• Security design reviews documented
• Defense in depth implemented across all layers
• Fail-secure behavior configured by default

A07 - Authentication

• MFA implemented for sensitive operations
• Strong password policy enforced
• Rate limiting on all login endpoints
• Secure session management with proper invalidation

A08 - Integrity

• Digitally signed software updates and release artifacts
• Data integrity verification with checksums
• Integrity controls for critical configuration files

A09 - Logging

• All critical events logged (auth attempts, access, errors)
• No sensitive information in log output
• Alert system configured for anomalous patterns
• Logs centralized and retained per compliance requirements

A10 - Exception Handling

• Generic error messages shown to users
• Each exception type handled specifically and appropriately
• Fail-secure behavior implemented throughout
• Stack traces never exposed in HTTP responses

Security Governance: How to Organize Your Team for OWASP 2025

Illustrative severity score comparison across the 10 OWASP 2025 categories — editorial scores based on documented prevalence, exploitability and impact

Security is not simply a list of technical tools: it requires adapted organizational structures and a security culture embedded in the team's daily practices. OWASP 2025 demands treating security as a shared responsibility across developers, DevOps teams, product managers, and leadership.

Appointing a Security Champion — one developer per team trained in security and responsible for OWASP compliance — distributes responsibility without creating a bottleneck. This role includes reviewing pull requests from a security perspective, monitoring new CVEs relevant to the team's stack, and regularly updating the application's SBOM.

From a regulatory standpoint, the OWASP Top Ten 2025 aligns with the requirements of the GDPR (data minimization, security by design), the NIS2 directive (risk management, incident notification), and standards like ISO 27001 and SOC 2. An application compliant with OWASP 2025 covers a significant portion of these regulatory requirements, reducing the overall cost of compliance audits. If your application integrates an AI chatbot or LLM features, the security-specific risks documented in our analysis of hidden costs in AI chatbot templates add to the standard OWASP risks and deserve dedicated attention in your threat model.

The recommended cadence for mature security governance includes: weekly security-focused code reviews, SAST/DAST on every commit, monthly dependency audits, quarterly penetration testing on critical features, and a comprehensive annual security posture review.

Conclusion: Security is a Continuous Process

The OWASP Top Ten 2025 reflects the constant evolution of threats and development practices. The two new categories (supply chain and exception handling) demonstrate that attackers continue to adapt their strategies — and so must defenders.

The 5 Essential Truths:

1. Security is not a state, it's a process: Continue to audit, test, and improve continuously
2. Dependencies are a major risk: Monitor and update regularly — every package is a potential attack surface
3. Configuration matters: Poor configuration can negate all your other security efforts
4. Secure design pays off: Integrating security from the start is 10× cheaper than fixing it later
5. Training is crucial: A security-aware team is your most effective and durable defense

Investment in security pays off:

• Protection against data breaches and their reputational consequences
• Regulatory compliance (GDPR, NIS2, etc.) at reduced cost
• Customer trust and competitive differentiation
• Significant savings on incident response and recovery costs

Every day without a security audit = Ongoing exposure to preventable risks

A single exploited vulnerability = Potential data breach affecting all your users

Security is your digital shield — invest in it before you need it

If you develop or maintain web applications, make sure you understand and address the risks of the OWASP Top Ten 2025. This is the only reliable way to protect your users and your business against modern threats.

---

Need a security audit for your application? Contact BOVO Digital for a complete assessment based on the OWASP Top Ten 2025 and the implementation of appropriate, prioritized protection measures.