For decades, the OWASP Top 10 has served as the foundational bedrock for web application security. It’s the industry’s go-to awareness document, guiding developers and security professionals on the most critical risks facing their web applications. Yet, in our rapidly evolving digital landscape, where cloud-native architectures, AI integration, sophisticated supply chains, and API-first development are the norm, the traditional OWASP Top 10, even its 2021 iteration, is showing its age.
Its critics often highlight its limitations: a focus on symptoms over root causes, an incomplete picture of modern attack surfaces, infrequent updates struggling to keep pace with new technologies, and a bias towards traditional web application flaws.
It’s time for a more holistic, proactive, and future-ready approach. We introduce the VIEH Security Top 10 for Web (2024 Edition) – a reimagined framework designed to address these critical gaps, emphasizing fundamental design, supply chain integrity, cloud-native complexities, and the often-overlooked human element.
.
The Guiding Principles of the VIEH Security Top 10
Our proposed VIEH framework is built upon several core tenets that differentiate it from its predecessor:
- Root Causes & Design First: We shift the focus to identifying and mitigating security flaws at the earliest stages—design and architecture—rather than merely patching implementation bugs.
- Proactive Security: This list champions a “shift-left” philosophy, encouraging threat modeling, secure-by-design principles, and embedding security throughout the entire Software Development Life Cycle (SDLC).
- Modern Technology Integration: Risks associated with emerging paradigms like AI/ML, serverless, microservices, complex client-side frameworks, and robust API ecosystems are explicitly addressed.
- Holistic Posture: Beyond just application code, this framework considers the broader security ecosystem, including the software supply chain, cloud infrastructure, and the human factor.
- Business Logic & Data Integrity: A greater emphasis is placed on vulnerabilities that directly impact core business processes, lead to data corruption, or compromise the integrity of critical assets.
Introducing the VIEH Security Top 10 for Web (2024 Edition):
Let’s delve into each category, understanding its significance, its evolution from traditional concepts, and its actionable implications for modern web security.
S1: Insecure Design & Architectural Flaws
The Ultimate Root Cause
Traditional security often focuses on finding bugs in code. However, the most insidious vulnerabilities stem from a flawed blueprint. Insecure Design & Architectural Flaws covers weaknesses inherent in how an application is conceived, not just how it’s coded. This includes the absence of effective threat modeling, inadequate trust boundaries between components, or poorly designed authentication/authorization workflows. No amount of perfect coding can fix an inherently insecure design.
- Why it’s #1: It directly tackles the “Symptom vs. Root Cause” loophole of older lists, mandating proactive security from the project’s inception.
- Examples: Designing a password reset flow that relies on easily guessable personal information, failing to isolate high-privilege microservices from public-facing components, or allowing direct database access from a web-facing service.
- Mitigation: Mandatory Threat Modeling workshops (e.g., using STRIDE/DREAD), adopting Zero Trustprinciples for all inter-service communication, and implementing secure-by-design architectural patterns.
| Focus | Details |
| Description | Fundamental security weaknesses introduced during the design and architecture phase. This category covers flaws that cannot be fixed by perfect coding, as the security controls were either missing, improperly placed, or inherently weak by design. |
| Addressing OWASP Loophole | This directly addresses the “Symptom vs. Root Cause” and “Not Exhaustive” loopholes by demanding proactive threat modeling and secure design patterns. It forces a shift-left approach. |
| Key Sub-Risks | 1. Lack of Trust Boundaries: Failing to segment systems based on necessary security contexts (e.g., placing privileged business logic in a public-facing microservice). 2. Insecure Workflow Design: Designing a password reset process that relies only on a single, easily-guessed piece of information (e.g., “What is your mother’s maiden name?”). 3. Improper Component Isolation: Allowing highly sensitive data to be handled by a component with lower-security requirements. |
| Mitigation | Proactive: Mandatory Threat Modeling (using STRIDE/DREAD) at the start of every sprint/feature. Use established Secure Design Patterns and reference architectures (e.g., zero-trust principles, least-privilege for service-to-service communication). Reactive: Security architecture reviews and penetration tests specifically targeting logic flaws. |
S2: Data Integrity & Supply Chain Compromise
Trusting the Untrustworthy
The modern software ecosystem is a complex web of third-party libraries, open-source components, APIs, and automated CI/CD pipelines. Data Integrity & Supply Chain Compromise highlights the critical risk of an attacker compromising any stage of this chain to inject malicious code or manipulate data. This extends far beyond merely using outdated components; it’s about the entire lifecycle’s integrity.
- Why it’s critical now: Addresses the “Not Exhaustive” loophole by encompassing pervasive threats like dependency confusion, compromised build environments, and the integrity of external data sources – risks that are now primary attack vectors.
- Examples: A malicious package uploaded to npm or PyPI, a compromised CI/CD server injecting backdoors into deployment artifacts, or unverified deserialized objects leading to remote code execution.
- Mitigation: Generating and reviewing Software Bill of Materials (SBOMs), implementing robust Code Signing, enforcing Immutable Builds, and continuous Software Composition Analysis (SCA) scanning.
| Focus | Details |
| Description | Failure to guarantee the integrity and authenticity of code, data, updates, and libraries from development to production. This is the risk of an attacker exploiting any component in the Software Supply Chain (CI/CD pipeline, dependencies, external assets). |
| Addressing OWASP Loophole | Significantly expands on “Vulnerable and Outdated Components” (A06) and “Software and Data Integrity Failures” (A08) by focusing on the entire delivery pipeline, not just the final deployed code. Addresses “Infrequent Updates” for quickly evolving dependencies. |
| Key Sub-Risks | 1. Dependency Confusion/Malware: Exploiting package managers (npm, PyPI) to inject malicious code via private/public component name conflicts. 2. Compromised CI/CD Pipeline: Injecting malicious code or configuration into the build server, leading to poisoned application artifacts. 3. Unverified Data Flows: Accepting critical, unverified data or deserialized objects from external systems (a new form of injection that leads to RCE). |
| Mitigation | Proactive: Software Bill of Materials (SBOM) generation and mandatory review. Code Signing for all released components. Use Immutable Builds and separate, hardened build environments. Reactive: Continuous Software Composition Analysis (SCA) scanning and Runtime Application Self-Protection (RASP) to monitor loaded libraries. |
S3: Advanced Injection & Logic Manipulation
Beyond SQLi: The Rise of Contextual Attacks
While classic SQL Injection remains a threat, Advanced Injection & Logic Manipulation broadens the scope to include sophisticated attacks targeting new interpreters (NoSQL, OS commands, Cloud API calls) and, critically, Prompt Injection against AI/LLM-integrated applications. It also explicitly includes the manipulation of core business logic to achieve unintended outcomes.
- Why it’s evolved: Expands on the traditional “Injection” (A03) by explicitly incorporating business logic flawsand emerging AI/ML-specific threats, directly addressing the “Infrequent Updates” for new technology.
- Examples: Crafting inputs to an LLM chatbot to bypass safety filters or extract confidential backend data, exploiting a NoSQL database via query operator injection, or altering HTTP request parameters to change pricing on an e-commerce site.
- Mitigation: Use of Parameterized Queries and Safe APIs. Apply a Positive Security Model (allow-listing) for all critical input fields. Implement LLM Input/Output Guardrails for AI integration.
| Focus | Details |
| Description | The execution of unintended commands by injecting untrusted data into an interpreter, plus the manipulation of application logic to achieve unauthorized business outcomes. This includes emerging forms of injection targeting new technology. |
| Addressing OWASP Loophole | Evolves “Injection” (A03) by explicitly including Logic Flaws (often missed) and emerging Prompt Injection threats related to AI-integrated web applications, addressing the “Infrequent Updates” loophole for new tech. |
| Key Sub-Risks | 1. Prompt Injection (LLM): Manipulating an AI/LLM-integrated app (e.g., customer service chatbot) via user input to bypass security filters, leak backend data, or perform unauthorized actions. 2. NoSQL/OS Command Injection: Exploiting modern application stacks that use different interpreters (e.g., MongoDB query operators, shell commands via child processes). 3. Parameter Tampering: Modifying hidden fields (e.g., price, quantity, user ID) to abuse core business logic (e.g., completing an order for $0). |
| Mitigation | Proactive: Use of Parameterized Queries and Safe APIs. Apply a Positive Security Model (allow-listing) for all critical input fields. LLM Input/Output Guardrails for AI integration. Reactive: Robust, centralized input validation and output encoding across all application layers. |
S4: Broken Authorization & Session Management
Who Are You, and What Are You Allowed To Do?
This category consolidates and elevates the challenges of enforcing correct user privileges (Authorization) and managing authenticated sessions in distributed environments. It covers everything from horizontal privilege escalation (IDOR) to vertical privilege escalation (role changes) and weaknesses in modern token-based authentication (like JWTs).
- Why it’s essential: Combines and deepens aspects of A01 and A07, specifically addressing the complexity of authorization in microservices where a chain of services must correctly propagate and enforce user permissions.
- Examples: Changing a user ID in a URL to access another user’s account (IDOR), manipulating a JWT token to elevate user privileges, or allowing session tokens to be reused after logout.
- Mitigation: Centralized, “Deny by Default” authorization policy. Robust Token Signing and Verification (using strong key rotation). Rate limiting on API calls, especially for endpoints prone to IDOR enumeration.
| Focus | Details |
| Description | Failures in enforcing user permissions (Authorization) and weaknesses in maintaining user identity state (Session Management). This is the risk of a user gaining unauthorized access to data (IDOR) or elevated privileges (Broken Function Level Authorization). |
| Addressing OWASP Loophole | Combines the most critical parts of A01 (Access Control) and A07 (Identification and Authentication Failures) with a strong emphasis on the complexity of token-based authorization in microservice architectures, which often leads to poor authorization chaining. |
| Key Sub-Risks | 1. Broken Object Level Authorization (BOLA/IDOR): The application allows a user to access or modify another user’s resource by simply changing an identifier (ID) in the request (e.g., URL parameter, JSON body). 2. Token Abuse/JWT Tampering: Flaws in validating or revoking JSON Web Tokens (JWTs), allowing attackers to forge tokens, reuse expired tokens, or alter claims (e.g., changing their role from ‘user’ to ‘admin’). 3. Insecure API Key/Secret Usage: Hard-coding or exposing internal secrets and API keys that grant unauthorized access to backend services. |
| Mitigation | Proactive: “Deny by Default” authorization policy. Implement authorization checks in a single, reusable component for all endpoints. Enforce strong Token Signing and Verification (using robust key rotation). Reactive: Rate limiting on API calls, especially for endpoints prone to IDOR enumeration. |
S5: Cryptographic Mismanagement & Data Exposure
Encryption Is Hard, Key Management Is Harder
It’s not enough to simply use encryption; Cryptographic Mismanagement & Data Exposure focuses on the correct implementation, secure storage, and lifecycle management of cryptographic keys and certificates. Failures here lead directly to sensitive data exposure, whether at rest, in transit, or in memory.
- Why it’s critical: Refines A02 by focusing on the management and operational lifecycle of encryption, which is often a key failure point in modern, distributed applications.
- Examples: Hardcoding API keys or database credentials in source code, using weak or deprecated hashing algorithms (e.g., SHA1, MD5) for passwords, or failing to classify sensitive data leading to its accidental exposure without encryption.
- Mitigation: Use a centralized Secrets Management solution (e.g., HashiCorp Vault). Enforce Strong, Salted Password Hashing (e.g., Argon2 or bcrypt). Regular scanning for hardcoded secrets in repositories.
| Focus | Details |
| Description | Failure to use cryptography correctly or failure to secure the management of cryptographic assets. This leads to the compromise of sensitive data (e.g., passwords, PII, financial info) or system credentials. |
| Addressing OWASP Loophole | Refines A02 by focusing on the management and operational lifecycle of encryption, which is often a key failure point in modern, distributed applications, rather than just the selection of an algorithm. |
| Key Sub-Risks | 1. Insecure Key Management: Cryptographic keys or secrets (for database, S3) are stored in source code, environment variables, or unsecured configuration files instead of a dedicated secret vault. 2. Weak/Outdated Cryptography: Using broken hashing algorithms (e.g., SHA1, MD5) for passwords or outdated TLS versions. 3. Insufficient Data Classification: Failure to identify and consistently encrypt all sensitive data in all states (at rest, in transit, and in memory). |
| Mitigation | Proactive: Use a centralized Secrets Management solution (e.g., HashiCorp Vault, AWS Secrets Manager) for all credentials. Enforce Strong, Salted Password Hashing (e.g., Argon2 or bcrypt). Reactive: Automated Certificate and Key Rotation. Regular scanning for hardcoded secrets in repositories. |
S6: Cloud-Native & Environmental Misconfiguration
The Peril of the Cloud Frontier
The Shared Responsibility Model of the cloud means customers are responsible for how they configure their resources. Cloud-Native & Environmental Misconfiguration covers insecure configurations of cloud services (IAM, S3, Kubernetes, serverless functions), containers, and infrastructure-as-code (IaC). A single misstep can expose an entire environment.
- Why it’s a top concern: Directly addresses a major gap in older lists by explicitly tackling cloud-specific risksthat are now ubiquitous, greatly expanding on “Security Misconfiguration” (A05).
- Examples: Overly permissive IAM Roles allowing a compromised function to access an entire cloud account, publicly exposed S3 buckets, or insecure Docker images running with elevated privileges.
- Mitigation: Implement Policy-as-Code (PaC) using tools like Open Policy Agent (OPA). Use Cloud Security Posture Management (CSPM) tools for continuous monitoring. Enforce Least Privilege for all cloud resources.
| Focus | Details |
| Description | Misconfiguration of the underlying cloud environment, container runtime, serverless functions, and infrastructure-as-code (IaC) that exposes the application or its data. |
| Addressing OWASP Loophole | Significantly expands “Security Misconfiguration” (A05) to explicitly cover the cloud Shared Responsibility Model and the unique risks of dynamic, distributed environments (e.g., containers, serverless). Addresses “Domain Bias.” |
| Key Sub-Risks | 1. Overly Permissive IAM Roles: Granting containers, serverless functions, or cloud resources broad permissions (e.g., S3:*) that allow them to access or modify resources they shouldn’t. 2. Exposed Storage/Services: Leaving public access enabled on cloud storage buckets (S3, Azure Blob) or exposing databases/internal services via unsecured security groups or public network endpoints. 3. Container/K8s Insecurity: Running containers with elevated privileges (privileged: true), using insecure base images, or failing to secure Kubernetes secrets. |
| Mitigation | Proactive: Implement Policy-as-Code (PaC) using tools like Open Policy Agent (OPA) to enforce security rules pre-deployment. Use Cloud Security Posture Management (CSPM) tools for continuous monitoring. Reactive: Implement Least Privilege for all cloud resources and service accounts. Disable all unnecessary ports and services. |
S7: Insufficient Security Monitoring & Alerting
If a Breach Happens in the Cloud, Does Anyone Hear It?
A security event that goes undetected is a successful attack. Insufficient Security Monitoring & Alerting highlights the critical need for comprehensive logging of security-relevant events, effective analysis, and timely alerts. Without these, incident response becomes a guessing game, and attackers can dwell in systems for months.
- Why it’s paramount: Elevates A09 by emphasizing proactive alerting, threat detection capabilities, and the full incident response lifecycle, not just generating logs.
- Examples: Failing to log authentication failures, authorization failures, or critical configuration changes; logs being tampered with or deleted; or an overwhelming volume of unactionable alerts leading to alert fatigue.
- Mitigation: Centralized, WORM (Write Once, Read Many) logging and SIEM solutions. Define High-Fidelity Alerts for indicators of compromise (IOCs). Ensure logs contain sufficient data for complete forensic analysis.
| Focus | Details |
| Description | The lack of appropriate logging, monitoring, and alerting for security-relevant events, allowing attacks to go undetected or unaddressed for extended periods (Dwell Time). |
| Addressing OWASP Loophole | Retains the criticality of A09 but broadens it to include proactive alerting and behavior anomaly detection, moving beyond simple log file creation to active incident response preparation. |
| Key Sub-Risks | 1. Missing Critical Events: Failing to log security-relevant events like authentication failures, authorization failures, data exports, or configuration changes. 2. Log Tampering/Lack of Protection: Storing logs locally where an attacker can modify or delete them to cover their tracks. 3. Alert Fatigue/Unprioritized Alerts: Overwhelming security teams with low-value alerts, causing critical incidents to be ignored. |
| Mitigation | Proactive: Centralized, WORM (Write Once, Read Many) logging and monitoring solution (SIEM). Define High-Fidelity Alerts for indicators of compromise (e.g., 5 consecutive login failures from a single IP, rapid IDOR enumeration attempts). Reactive: Ensure logs contain sufficient data (user, timestamp, source IP, outcome, affected resource) for complete forensic analysis. |
S8: Client-Side & Frontend Attack Surface
The Browser as the New Battleground
Modern web applications are often complex Single-Page Applications (SPAs) heavily reliant on JavaScript and numerous third-party libraries. Client-Side & Frontend Attack Surface addresses the growing risks from compromised client-side code, third-party script injections, and browser-based attacks that steal data directly from the user’s browser.
- Why it’s a dedicated category: Separates and elevates client-side risks, which are often generalized under “Injection” (A03), acknowledging the massive, dynamic attack surface of modern JavaScript-heavy frontends.
- Examples: A Magecart attack injecting malicious JavaScript into a payment page via a compromised analytics script, DOM-based XSS, or overly permissive Cross-Origin Resource Sharing (CORS) policies.
- Mitigation: Implement strong Content Security Policy (CSP) headers to restrict script sources. Use Subresource Integrity (SRI) for all critical third-party scripts.
| Focus | Details |
| Description | Vulnerabilities arising from the complexity and reliance on third-party libraries in modern client-side code (SPAs, web components, browser extensions). This includes attacks that compromise the user’s browser context. |
| Addressing OWASP Loophole | Gives a dedicated, modern focus to client-side risks, which are often generalized under A03 (Injection), addressing the rapidly growing attack surface of Single-Page Applications (SPAs) and external script dependencies. |
| Key Sub-Risks | 1. Client-Side Supply Chain Attack (Magecart): Compromising a third-party script (e.g., a payment widget or analytics code) to steal data directly from the user’s browser. 2. DOM-Based XSS: Script injection that occurs purely within the browser’s Document Object Model (DOM), often missed by server-side scanners. 3. Insecure CORS Policies: Misconfigured Cross-Origin Resource Sharing (CORS) allowing unauthorized external websites to access authenticated resources via the user’s browser. |
| Mitigation | Proactive: Implement strong Content Security Policy (CSP) headers to restrict script sources. Use Subresource Integrity (SRI) for all critical third-party scripts. Reactive: Use tools to monitor client-side scripts and detect unauthorized code changes or data exfiltration attempts. |
S9: API & Microservice Security Flaws
The Glue That Binds, The Gaps That Break
APIs are the backbone of modern web applications, connecting microservices, frontends, and external partners. API & Microservice Security Flaws focuses on vulnerabilities specific to API design, implementation, and consumption, particularly prevalent in microservice architectures.
- Why it’s integrated: While OWASP has a dedicated API Top 10, this integrates the most critical API-specific risks into the general web list, reflecting the API-first nature of virtually all modern web applications.
- Examples: Broken Object Level Authorization (BOLA), allowing manipulation of another user’s data via an API ID, excessive data exposure where an API returns more sensitive information than necessary, or lack of rate limiting leading to API abuse.
- Mitigation: Implement a robust API Gateway with centralized rate limiting and authentication checks. Use Schema-Based Validation (e.g., OpenAPI/Swagger) to explicitly define and filter all API fields.
| Focus | Details |
| Description | Specific risks inherent in the design and management of modern APIs, which are the backbone of most web applications (often REST, GraphQL, or gRPC). This focuses on high-impact API-specific vulnerabilities. |
| Addressing OWASP Loophole | Integrates the most critical API-specific risks (often found in the dedicated OWASP API Top 10) into the general web list, acknowledging that all modern web frontends are API consumers. Addresses the “Domain Bias.” |
| Key Sub-Risks | 1. Broken Object Property Level Authorization (BOPLA / Mass Assignment): Allowing a client to modify sensitive object properties (e.g., changing role from ‘user’ to ‘admin’ via a POST request) that they should not have access to. 2. Excessive Data Exposure: APIs returning all fields of a database object, even those not needed or not authorized for the requesting user (e.g., a user profile API returning the user’s password hash or internal IDs). 3. Lack of Resource and Rate Limiting: Failure to limit the frequency or volume of requests, leading to brute-force attacks, denial of service (DoS), or mass data scraping. |
| Mitigation | Proactive: Implement Schema-Based Validation (e.g., OpenAPI/Swagger) to explicitly define and filter all API request and response fields. Deploy API Gateways with centralized rate limiting and authentication checks. Reactive: Implement strict Role-Based Access Control (RBAC) at the property level, ensuring only authorized fields can be written or read. |
S10: Human Factor & Social Engineering Vulnerabilities
The Strongest Link, or the Weakest?
No matter how robust our technical controls, humans remain the ultimate target. Human Factor & Social Engineering Vulnerabilities acknowledges that phishing, credential stuffing, insider threats, and a lack of security awareness are often the easiest and most successful entry points for attackers.
- Why it’s crucial: Addresses the “Not Exhaustive” loophole by explicitly including the non-technical but highly critical human element, recognizing that technology alone cannot fully secure an application.
- Examples: An employee falling for a phishing email, leading to system access; users reusing weak passwords across multiple sites (credential stuffing); or an insider intentionally or unintentionally leaking sensitive data.
- Mitigation: Enforcing Multi-Factor Authentication (MFA) everywhere. Conducting regular, mandatory Security Awareness Training and phishing simulations. Implement Zero Trust Architecture principles, aggressively limiting access and requiring continuous verification.
| Focus | Details |
| Description | Risks introduced by the developers, administrators, or end-users of the application, which are often the easiest and most successful initial attack vectors. This exploits trust, urgency, or ignorance. |
| Addressing OWASP Loophole | Acknowledges the human element as the ultimate root cause for many breaches (e.g., falling for phishing, poor credential storage), addressing the “Not Exhaustive” loophole by including a non-technical, but highly critical, risk. |
| Key Sub-Risks | 1. Credential Stuffing/Theft: Attackers using credentials stolen from other breaches to gain access to the application, leveraging end-user password reuse. 2. Spear Phishing: Targeting employees with privileged access (e.g., a developer, cloud admin) to steal their credentials and gain access to the environment or source code. 3. Insider Threats: Malicious or negligent actions by internal employees who have legitimate access to critical systems or data. |
| Mitigation | Proactive: Mandatory Multi-Factor Authentication (MFA) for all users, especially those with privileged access. Continuous Security Awareness Training and phishing simulations for all employees. Reactive: Implement Zero Trust Architecture principles, aggressively limiting access and requiring continuous verification, even for internal users. Use Behavioral Analytics to flag unusual employee activity. |
Conclusion: A New Era for Web Security with VIEH
The VIEH Security Top 10 for Web (2024 Edition) is not meant to replace the excellent work done by OWASP but to augment and modernize it. It’s a call to action for the security community to embrace a more holistic, proactive, and future-aware approach to protecting our digital assets. By addressing the fundamental design flaws, securing the entire software supply chain, accounting for cloud-native complexities, integrating emerging tech like AI, and never forgetting the human element, we can collectively build a more resilient and secure web for tomorrow.
The landscape is constantly shifting, and our security frameworks must evolve with it. The VIEH Security Top 10 for Web aims to be that necessary evolution, guiding us towards stronger, more defensible web applications in 2024 and beyond.
The entire report and the proposed VIEH Security Top 10 are specifically created for web applications (including their underlying microservices, APIs, and cloud-native environments).
By: VIEH Security team
