The OWASP Top 10 (2021): What Every Developer and Security Team Needs to Know

Why the OWASP Top 10 Still Matters

Every few years, the Open Worldwide Application Security Project (OWASP) publishes an updated ranking of the most critical security risks facing web applications. For development teams, security engineers, and CISOs alike, this list serves as a foundational benchmark. It shapes how penetration testing firms scope engagements, how compliance auditors evaluate controls, and how engineering teams prioritize their security backlogs.

The 2021 edition introduced significant changes from the previous 2017 list, reflecting the current state of application security. As an offensive cybersecurity firm headquartered in San Francisco, we at CyberGuards work with Bay Area startups and enterprises that ship code at extraordinary velocity. The patterns we see in real-world penetration tests align closely with the OWASP data — and in some cases, the risks have intensified beyond what the previous 2017 list captured.

Whether you are a startup preparing for your first SOC 2 audit or a public company maintaining PCI DSS compliance, understanding this list is essential. Let us walk through every category and outline the testing and remediation approaches that actually work.

2017 vs. 2021: The Full Comparison Table

Before diving into each category, here is a side-by-side comparison showing how the list evolved from the 2017 edition to the current 2021 edition. Some categories were renamed, some were consolidated, and three entirely new entries appeared.

While the overall structure may look familiar, the substance within each category has changed materially. The data behind the 2021 list includes incident reports, bug bounty submissions, and scanning data from a much broader set of contributors — including cloud-native and API-heavy applications that dominate the San Francisco tech ecosystem.

A01:2021 — Broken Access Control

Broken access control moved to the top position in 2021, displacing injection which had held the number one spot since the OWASP Top 10 began. The category encompasses a broad set of attack patterns, including horizontal privilege escalation across microservices, insecure direct object references (IDOR) in GraphQL APIs, and authorization bypass through manipulation of JWTs and session tokens.

What changed from 2017: The 2021 edition elevated this category from fifth to first place, reflecting data showing that 94% of applications tested had some form of broken access control. API-level access control failures are now a dominant attack vector. With the proliferation of single-page applications and mobile backends, authorization logic has migrated from monolithic server-side checks to distributed enforcement across dozens of services. When even one service fails to validate permissions, attackers gain access to resources they should never see.

Testing Techniques

• Automated IDOR scanning: Use tools like Burp Suite's Autorize extension to compare authenticated responses across different user roles. Map every API endpoint and systematically test whether User A can access User B's resources.
• JWT manipulation: Decode tokens, modify claims (changing role from user to admin), and test whether the server validates the signature properly. Test for algorithm confusion attacks (switching RS256 to HS256).
• Forced browsing: Enumerate administrative paths, API versioning endpoints (/api/v1/ vs /api/v2/), and debug routes that may lack authorization checks.
• Multi-tenant boundary testing: In SaaS applications, verify that tenant isolation holds across every data access path, including exported reports, shared links, and webhook configurations.

Remediation Guidance

Implement authorization checks at the framework level, not in individual route handlers. Use policy-as-code tools such as Open Policy Agent (OPA) to centralize access decisions. Adopt a deny-by-default model and require explicit grants for every resource. In our engagements with Bay Area SaaS companies, the teams that enforce authorization through middleware consistently outperform those that rely on scattered checks throughout their codebase.

A02:2021 — Cryptographic Failures

Previously known as "Sensitive Data Exposure" in the 2017 list, this category was renamed and shifted focus to the root cause: the failure to properly protect data at rest and in transit. The 2021 edition emphasizes weak key management practices, the continued use of deprecated algorithms like SHA-1 and MD5 for integrity checks, and insufficient encryption of data within cloud storage services.

What changed from 2017: The renaming from "Sensitive Data Exposure" to "Cryptographic Failures" reflects a shift from symptoms to root causes. The scope now addresses cryptographic failures in container orchestration secrets, mismanaged TLS certificates in service meshes, and the storage of sensitive tokens in client-side storage mechanisms like localStorage. The rise of multi-cloud architectures has made key management exponentially more complex.

Testing Techniques

• TLS configuration auditing: Use testssl.sh or SSLyze to identify weak cipher suites, expired certificates, and missing HSTS headers.
• Secret scanning: Analyze source code repositories, CI/CD configurations, and container images for hardcoded API keys, database credentials, and private keys.
• Data classification review: Map all sensitive data flows and verify that encryption is applied appropriately at each storage and transit point.
• Key rotation testing: Verify that key rotation procedures work correctly and that old keys are properly deprecated.

Remediation Guidance

Classify data according to sensitivity levels and apply encryption standards accordingly. Use managed key services (AWS KMS, Google Cloud KMS, Azure Key Vault) rather than self-managed key infrastructure. Enforce TLS 1.3 wherever possible and eliminate all uses of deprecated cryptographic algorithms. Implement automated certificate management to prevent expiration-related outages and security gaps.

A03:2021 — Injection

Injection has been a fixture on the OWASP Top 10 since its inception. In the 2021 edition, it dropped from first to third place but retains a broad attack surface. While SQL injection remains relevant, the category now encompasses cross-site scripting (XSS) — previously a separate entry — along with NoSQL injection, LDAP injection, and OS command injection.

What changed from 2017: Injection dropped from the number one position and now includes cross-site scripting, which was previously listed separately as A07:2017. As San Francisco companies build increasingly complex applications, the attack surface continues to expand. We have seen injection flaws firsthand in penetration tests for Bay Area startups where user inputs flow directly into queries and commands without proper sanitization.

Testing Techniques

• Parameterized query verification: Confirm that all database interactions use parameterized queries or prepared statements, never string concatenation.
• Input validation boundary testing: Submit special characters, Unicode sequences, and encoding variations to every input field and API parameter.
• Prompt injection testing: For LLM-integrated applications, craft inputs designed to override system instructions, extract hidden prompts, and trigger unintended actions.
• Second-order injection: Test for stored injection payloads that execute when data is retrieved and processed in a different context.

Remediation Guidance

Use parameterized queries universally. Implement strict input validation with allowlists rather than denylists. For LLM integrations, isolate user inputs from system prompts using delimiter strategies, implement output filtering, and apply the principle of least privilege to any actions the model can trigger. Consider architectural patterns that prevent user input from ever being concatenated directly into executable contexts.

A04:2021 — Insecure Design

Insecure Design is a new category introduced in the 2021 edition to distinguish design-level flaws from implementation bugs. It focuses on risks related to design and architectural flaws, calling for greater use of threat modeling, secure design patterns, and reference architectures.

Why this was added: This category addresses the absence of threat modeling during the design phase of software development. It calls out the failure to define security requirements before coding begins — a pattern we see frequently in fast-moving startups across the Bay Area where speed-to-market pressures often override security architecture reviews.

Testing Techniques

• Architecture review: Examine system design documents and data flow diagrams for trust boundary violations, missing authentication layers, and insufficient rate limiting.
• Business logic testing: Identify workflows where security depends on client-side enforcement or assumes a specific sequence of operations that attackers can circumvent.
• Abuse case development: Create attack scenarios that exploit the intended functionality of the application in unintended ways — for example, using a referral system to generate fraudulent credits.
• Threat model validation: Compare the existing threat model (if one exists) against actual application behavior to identify gaps.

Remediation Guidance

Integrate threat modeling into the software development lifecycle. Use frameworks like STRIDE or PASTA to systematically identify risks during design. Establish security design patterns as reusable components — for example, standardized rate limiting, anti-automation controls, and transaction integrity checks. Require security architecture review for any feature that handles sensitive data or financial transactions.

A05:2021 — Security Misconfiguration

Security misconfiguration remains one of the most commonly exploited vulnerability classes. The 2021 edition moved it up from sixth place and now includes the former XML External Entities (XXE) category, which was A04 in 2017.

What changed from 2017: The scope now explicitly includes Kubernetes misconfigurations, overly permissive IAM policies in cloud environments, default credentials in containerized services, and exposed management interfaces. With the shift to cloud-native architectures, the blast radius of a single misconfiguration has increased dramatically.

Testing Techniques

• Cloud configuration scanning: Use tools like ScoutSuite, Prowler, or CloudSploit to identify misconfigurations across AWS, Azure, and GCP environments.
• Container security assessment: Scan Docker images for unnecessary packages, run-as-root configurations, and embedded secrets. Review Kubernetes RBAC policies and network policies.
• Default credential testing: Systematically test all services for default usernames and passwords, including databases, message queues, caching layers, and management consoles.
• HTTP header analysis: Verify the presence and correct configuration of security headers including Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and Permissions-Policy.

Remediation Guidance

Implement infrastructure-as-code with security guardrails built into CI/CD pipelines. Use policy enforcement tools like OPA/Gatekeeper for Kubernetes and AWS Config Rules or Azure Policy for cloud environments. Establish hardened baseline configurations for every service type and automate drift detection. Remove all default credentials and disable unnecessary services, ports, and features.

A06:2021 — Vulnerable and Outdated Components

The software supply chain has become one of the most actively targeted attack surfaces in cybersecurity, and the 2021 edition reflects this reality by moving this category up from ninth place in 2017 (where it was titled "Using Components with Known Vulnerabilities").

What changed from 2017: The renamed and elevated category places significantly more weight on supply chain attacks — compromised packages in npm, PyPI, and other registries; dependency confusion attacks; and the risks of transitive dependencies that introduce vulnerabilities several layers deep in the dependency graph. The category also addresses the risk of abandoned or unmaintained open-source projects.

Testing Techniques

• Software composition analysis (SCA): Run tools like Snyk, Dependabot, or OWASP Dependency-Check against all application dependencies, including transitive ones.
• Dependency confusion testing: Verify that package managers are configured to prioritize private registries and that namespace squatting protections are in place.
• End-of-life component identification: Map all components to their support lifecycle and flag any that have reached end of life or have not received updates in over 12 months.
• SBOM generation and analysis: Generate Software Bills of Materials and cross-reference against known vulnerability databases.

Remediation Guidance

Maintain a comprehensive inventory of all software components and their versions. Implement automated vulnerability scanning in CI/CD pipelines that blocks deployments when critical vulnerabilities are detected. Establish a patch management SLA — for example, critical vulnerabilities patched within 48 hours, high within one week. Use lock files and integrity verification to prevent supply chain tampering.

A07:2021 — Identification and Authentication Failures

This category addresses weaknesses in authentication mechanisms that allow attackers to compromise passwords, session tokens, or identity verification processes. Previously known as "Broken Authentication" (A02 in 2017), it dropped to seventh place thanks to increased adoption of standardized authentication frameworks.

What changed from 2017: The renamed category expands coverage beyond traditional authentication to include identification failures, OAuth and OIDC implementation flaws, and vulnerabilities in multi-factor authentication (MFA) rollout. The drop in ranking reflects improvements in framework-level authentication, but the risk remains significant for applications with custom authentication implementations.

Testing Techniques

• Credential stuffing simulation: Test rate limiting and account lockout mechanisms against automated login attempts using breached credential databases.
• Session management testing: Verify session token entropy, proper invalidation on logout, timeout enforcement, and protection against session fixation.
• OAuth flow testing: Test for open redirect vulnerabilities in OAuth callbacks, CSRF in the authorization flow, and token leakage through referrer headers.
• MFA bypass testing: Attempt to circumvent MFA through API endpoints that lack MFA enforcement, response manipulation, and race conditions in verification code validation.

Remediation Guidance

Implement phishing-resistant MFA using FIDO2/WebAuthn where possible. Enforce strong password policies that check against breached password databases (such as the Have I Been Pwned API). Use proven authentication libraries and frameworks rather than custom implementations. Implement adaptive authentication that increases verification requirements based on risk signals such as new device, unusual location, or impossible travel.

A08:2021 — Software and Data Integrity Failures

This is a new category in the 2021 edition that addresses assumptions about software updates, critical data, and CI/CD pipelines without verifying integrity. It incorporates the former A08:2017 "Insecure Deserialization" as part of its broader scope.

Why this was added: The category reflects the growing importance of CI/CD pipeline security, driven by high-profile supply chain attacks that compromised build systems. It addresses the integrity of software artifacts and the need to verify that code and data have not been tampered with during the development and deployment process — a growing concern as organizations in San Francisco and across the tech industry rely on complex automated pipelines.

Testing Techniques

• CI/CD pipeline assessment: Review build system configurations for unsigned artifacts, unverified dependencies pulled during build, and overly permissive pipeline permissions.
• Update mechanism testing: Verify that software update mechanisms validate digital signatures and use secure transport channels.
• Deserialization testing: Test all deserialization endpoints for object injection vulnerabilities, particularly in Java, PHP, and Python applications.
• Data integrity validation: Verify that critical data (pricing, permissions, configurations) cannot be modified through client-side manipulation or race conditions.

Remediation Guidance

Sign all build artifacts and verify signatures before deployment. Implement branch protection rules and require code review for all changes to production branches. Use reproducible builds where possible to enable independent verification of build outputs. Apply integrity checks to all critical data paths and implement audit logging for changes to sensitive configurations.

A09:2021 — Security Logging and Monitoring Failures

Without adequate logging, monitoring, and alerting, breaches go undetected and incident response becomes reactive rather than proactive. This category was renamed from "Insufficient Logging & Monitoring" (A10 in 2017) and moved up one position.

What changed from 2017: The 2021 edition expands this category to include security observability for cloud-native architectures, including distributed tracing for security events across microservices, monitoring of serverless function invocations, and detection of anomalous API usage patterns. It also addresses the need for tamper-evident logging to prevent attackers from covering their tracks.

"The average time to detect a breach in 2024 was still 194 days. Organizations that maintain comprehensive security monitoring reduce this to under 30 days — a difference that translates directly into reduced financial and reputational damage."

Testing Techniques

• Log coverage assessment: Verify that authentication events, authorization failures, input validation errors, and administrative actions all generate log entries with sufficient detail.
• Alert validation: Trigger known attack patterns (brute force, SQL injection, directory traversal) and verify that alerts fire within acceptable time windows.
• Log injection testing: Attempt to inject malicious content into log entries that could exploit log processing pipelines or SIEM systems.
• Log integrity verification: Confirm that logs are stored in append-only or tamper-evident storage and that attackers with application-level access cannot modify or delete log entries.

Remediation Guidance

Implement centralized log management with a SIEM or security data lake. Define and enforce a logging standard that covers all security-relevant events. Set up real-time alerting for critical events such as privilege escalation attempts, unusual data exports, and authentication anomalies. Ensure log retention meets compliance requirements (typically 90 days to one year) and that logs are protected against tampering.

A10:2021 — Server-Side Request Forgery (SSRF)

SSRF is a new addition to the 2021 list, added based on community survey data even though the incidence rate was relatively low at the time. Its inclusion reflects the growing severity of SSRF in cloud environments where metadata services and internal microservice architectures amplify the impact.

Why this was added: SSRF has become one of the most impactful vulnerability classes in cloud environments. A single SSRF vulnerability can grant access to cloud instance metadata (including IAM credentials), internal services, and private network resources. The category was added to reflect real-world incidents where SSRF was the initial vector for major data breaches.

Testing Techniques

• Internal service enumeration: Craft SSRF payloads targeting internal IP ranges, cloud metadata endpoints, and common internal service ports.
• Protocol smuggling: Test for SSRF through non-HTTP protocols (gopher, file, dict) and through URL parsing inconsistencies between validation and request libraries.
• Blind SSRF detection: Use out-of-band interaction servers (such as Burp Collaborator or Interactsh) to detect SSRF vulnerabilities that do not return responses directly to the attacker.
• Bypass technique testing: Test URL validation bypasses including DNS rebinding, IPv6 representations, decimal IP notation, and URL redirects through attacker-controlled domains.

Remediation Guidance

Implement strict allowlists for outbound requests from server-side components. Disable access to cloud metadata services from application workloads by using IMDSv2 (on AWS) or equivalent protections on other platforms. Deploy network segmentation that prevents application-tier systems from reaching internal management interfaces. Validate and sanitize all URLs on the server side before making outbound requests, and do not rely solely on denylists of internal IP ranges.

Key Themes Across the 2021 Edition

Looking at the 2021 OWASP Top 10 holistically, several overarching themes emerge that reflect the current state of application security:

The API-First Attack Surface

Nearly every category now includes API-specific attack patterns. The shift from server-rendered web applications to API-driven architectures has fundamentally changed how vulnerabilities manifest and how they must be tested. If your penetration testing program does not include comprehensive API security testing, you are leaving significant risk on the table.

Cloud-Native Complexity

Kubernetes, serverless functions, service meshes, and multi-cloud deployments have expanded the misconfiguration surface enormously. Security teams need tooling and expertise that spans infrastructure, platform, and application layers simultaneously.

AI and LLM Integration Risks

The 2021 list was published before the widespread adoption of LLMs, but the injection and insecure design categories provide a strong foundation for addressing AI-related risks. Organizations deploying AI-powered features should also consult the OWASP Top 10 for LLM Applications as a complementary resource. The San Francisco tech community, at the epicenter of the AI revolution, faces these risks acutely.

Supply Chain as a Primary Attack Vector

Multiple categories (A06, A08) address supply chain risks, reflecting the reality that modern applications are assembled from hundreds of third-party components. The integrity of these components — from open-source libraries to CI/CD tools — is now a first-order security concern.

How to Use the OWASP Top 10 Effectively

The OWASP Top 10 is a starting point, not a finish line. Here is how organizations can extract maximum value from the 2021 edition:

1. Benchmark your current state: Map your existing security controls against each of the 10 categories and identify gaps. Be honest about where your coverage is thin.
2. Prioritize based on your architecture: A company running a microservices architecture on Kubernetes should weight A05 (Security Misconfiguration) and A01 (Broken Access Control) heavily. A company integrating LLMs should prioritize A03 (Injection) with specific attention to prompt injection.
3. Integrate into your SDLC: Use the OWASP Top 10 categories as a checklist during code reviews, threat modeling sessions, and security testing. Map SAST and DAST tool findings to these categories for consistent reporting.
4. Train your developers: Use the 2021 edition as a training curriculum. Each category includes concrete examples and CWE references that developers can study and internalize.
5. Scope penetration tests accordingly: When engaging an offensive security firm, reference the OWASP Top 10 categories you are most concerned about. A well-scoped penetration test should cover all 10 categories for comprehensive web application assessments.

What This Means for Your Security Program

The 2021 OWASP Top 10 confirms that web application security is more complex than ever. The attack surface has expanded beyond traditional web interfaces to encompass APIs, cloud infrastructure, and supply chains. Defending against these risks requires a combination of secure design principles, automated tooling, developer education, and regular offensive testing.

At CyberGuards, our penetration testing methodology incorporates the complete OWASP Top 10 framework while going beyond it to address the unique risks of each client's architecture and technology stack. Operating from San Francisco, we work closely with organizations across the Bay Area and nationally to identify and remediate vulnerabilities before attackers can exploit them.

If your security program has not yet aligned with the OWASP Top 10:2021, now is the time. Understanding these categories and testing against them is one of the most effective steps you can take to strengthen your application security posture.