Table of Contents
- Why the OWASP Top 10 Matters
- A01: Broken Access Control
- A02: Cryptographic Failures
- A03: Injection
- A04: Insecure Design
- A05: Security Misconfiguration
- A06: Vulnerable and Outdated Components
- A07: Identification and Authentication Failures
- A08: Software and Data Integrity Failures
- A09: Security Logging and Monitoring Failures
- A10: Server-Side Request Forgery (SSRF)
- How Specter Forge Tests for All OWASP Top 10
Why the OWASP Top 10 Matters in 2026
The OWASP Top 10 is the most widely recognized framework for understanding and prioritizing web application vulnerabilities. Published by the Open Web Application Security Project, this list represents a broad consensus on the most critical security risks facing web applications today. Whether you are a developer writing code, a security engineer reviewing architecture, or a CISO setting policy, the OWASP Top 10 is the baseline you cannot afford to ignore.
The current edition, often referenced as the OWASP Top 10 2021 (and still the authoritative list going into 2025 and 2026), reflects major shifts in the threat landscape. Broken Access Control climbed to the number one position. Injection, once the perennial leader, dropped to third. New categories like Insecure Design and Server-Side Request Forgery entered the list for the first time, reflecting the evolution of both attacker techniques and application architectures.
Understanding these common web vulnerabilities is not optional. According to Verizon's Data Breach Investigations Report, web application attacks remain the primary vector in confirmed data breaches. Regulatory frameworks including PCI DSS, SOC 2, and ISO 27001 increasingly reference the OWASP Top 10 as a minimum testing standard. Organizations that fail to address these risks face not only data breaches but also compliance penalties, reputational damage, and legal liability.
In this guide, we break down each of the ten categories with real-world examples, explain how they are detected and exploited during penetration testing, and provide actionable remediation guidance. We also show how Specter Forge automates detection of every category through its AI-powered red team operations platform.
Broken Access Control
Broken Access Control moved from fifth to first position in the 2021 edition, and for good reason. This category encompasses any failure to properly enforce restrictions on what authenticated users are allowed to do. When access control is broken, attackers can view other users' data, modify records they should not have access to, or escalate their privileges to administrative levels.
Consider an application where user profiles are accessed via /api/users/1042. An attacker simply changes the ID to /api/users/1043 and retrieves another user's personal information. This is an Insecure Direct Object Reference (IDOR), one of the most common manifestations of broken access control. In 2023, a major financial platform exposed millions of customer records through precisely this flaw.
During red team operations, this is tested through IDOR enumeration across all API endpoints, forced browsing to administrative paths (such as /admin, /dashboard/admin, or /api/internal/), privilege escalation via parameter tampering (changing role=user to role=admin in requests), and horizontal access control testing by accessing resources belonging to other users. Tools like Burp Suite, ffuf, and gobuster are used alongside manual parameter manipulation.
- Deny access by default. Every endpoint should require explicit authorization.
- Implement server-side access control checks. Never rely on client-side restrictions.
- Use indirect object references or validate ownership before returning data.
- Log and alert on access control failures to detect attack patterns.
- Enforce rate limiting on sensitive endpoints to slow automated enumeration.
Cryptographic Failures
Previously titled "Sensitive Data Exposure," this category was renamed to focus on the root cause: failures in cryptographic implementation. This includes transmitting data in cleartext, using deprecated algorithms like MD5 or SHA-1 for password hashing, weak TLS configurations, hardcoded encryption keys, and improper certificate validation.
A healthcare application stored patient records encrypted with AES-128 but kept the encryption key in a plaintext configuration file within the web root. An attacker who discovered the key through a directory traversal vulnerability was able to decrypt the entire database. In another case, an e-commerce site used TLS 1.0 with CBC cipher suites, making it vulnerable to the BEAST and POODLE attacks that allowed session cookie theft.
Specialized tools like testssl.sh, sslscan, and sslyze perform comprehensive analysis of TLS configuration, including protocol versions, cipher suites, certificate validity, HSTS headers, and known vulnerabilities like Heartbleed. Red team operators also search for exposed secrets: .env files, aws/credentials, API keys in JavaScript bundles, and hardcoded passwords in source repositories.
- Enforce TLS 1.2 or higher with strong cipher suites. Disable TLS 1.0 and 1.1.
- Use bcrypt, scrypt, or Argon2id for password hashing. Never use MD5 or plain SHA.
- Store encryption keys in dedicated secrets management (AWS KMS, HashiCorp Vault).
- Implement HSTS headers with a minimum one-year max-age.
- Classify data by sensitivity and apply appropriate encryption at rest and in transit.
Injection
Injection attacks remain among the most dangerous web application vulnerabilities. They occur when untrusted data is sent to an interpreter as part of a command or query. This category includes SQL Injection (SQLi), Cross-Site Scripting (XSS), OS Command Injection, Server-Side Template Injection (SSTI), LDAP Injection, and XML External Entity (XXE) attacks.
A login form that constructs SQL queries by concatenating user input is the textbook example: SELECT * FROM users WHERE email = 'input' AND password = 'input'. An attacker enters ' OR 1=1 -- as the email and bypasses authentication entirely. More sophisticated attacks use time-based blind SQLi to extract database contents one character at a time, or second-order injection where the payload is stored and executed later.
Red team operations deploy sqlmap at level 3, risk 3 with tamper scripts to test for SQL injection across all parameters, headers, and cookies. Commix tests for OS command injection. XSS testing involves 11+ payload variations across reflected, stored, and DOM-based contexts. SSTI is tested with payloads for Jinja2, Twig, Freemarker, Velocity, and Mako template engines. Each injection type requires specialized detection techniques because the vulnerability manifests differently depending on the technology stack.
- Use parameterized queries or prepared statements for all database operations.
- Apply context-sensitive output encoding for XSS prevention (HTML, JavaScript, URL, CSS contexts).
- Validate and sanitize all user input on the server side using allowlists.
- Use a Web Application Firewall (WAF) as a defense-in-depth layer.
- Apply the principle of least privilege to database accounts and system commands.
Insecure Design
Insecure Design is a category introduced in the 2021 edition that focuses on flaws in the application's architecture and business logic rather than implementation bugs. These are vulnerabilities that no amount of secure coding can fix because the design itself is flawed. This distinction matters: a perfectly implemented but fundamentally insecure design is still vulnerable.
A movie theater booking system allows users to reserve up to 15 seats but does not impose any rate limiting or reserve-and-release timeout. An attacker scripts hundreds of reservations, effectively performing a denial-of-service attack on ticket availability without ever completing a purchase. Another example: a password reset flow that sends a four-digit code via SMS but allows unlimited guess attempts, letting an attacker brute-force any account's reset code in under 30 minutes.
Business logic testing involves sending 30-request bursts to critical endpoints to test rate limiting, analyzing password reset and registration workflows for abuse potential, testing for race conditions in payment and checkout flows, and checking whether CORS policies are properly restrictive. This type of testing is difficult to automate with traditional scanners and benefits significantly from AI-powered analysis that can understand application context.
- Incorporate threat modeling early in the development lifecycle.
- Define and enforce rate limits for authentication, registration, and payment endpoints.
- Implement transaction timeouts and reservation expiry for resource-holding operations.
- Write abuse case stories alongside user stories during requirements gathering.
- Perform design reviews with security architects before implementation begins.
Security Misconfiguration
Security misconfiguration is the most commonly seen vulnerability class in real-world assessments. It encompasses default credentials left in place, unnecessary services exposed, overly verbose error messages, missing security headers, directory listing enabled, and debug endpoints accessible in production. As applications grow more complex with microservices, cloud infrastructure, and container orchestration, the attack surface for misconfigurations expands dramatically.
A Django application deployed to production with DEBUG = True exposes full stack traces, database query details, environment variables, and installed application paths to any user who triggers an error. In another case, an Elasticsearch instance with no authentication exposed 800 million email records because the default configuration did not require credentials.
Red team operations probe for more than 60 debug and development paths including /debug, /phpinfo.php, /.env, /actuator, /server-status, and /elmah.axd. Default credential testing covers common username and password combinations across HTTP authentication, SSH, FTP, and database services using hydra. Security header analysis checks for 10 required headers including Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Permissions-Policy.
- Implement a hardening checklist for each technology in the stack.
- Remove all default credentials, sample applications, and unused features.
- Deploy all required security headers. Use tools like securityheaders.com for validation.
- Disable directory listing, verbose error pages, and stack traces in production.
- Automate configuration auditing as part of CI/CD pipelines.
Vulnerable and Outdated Components
Applications are built on stacks of dependencies: frameworks, libraries, database drivers, and operating system packages. When any component in that stack has a known vulnerability and is not patched, the entire application inherits that risk. The challenge is visibility: most organizations do not know the full inventory of components they deploy, let alone which versions are vulnerable.
The Equifax breach of 2017, which exposed 147 million records, was caused by an unpatched Apache Struts vulnerability (CVE-2017-5638). The patch had been available for two months before the breach. More recently, the Log4Shell vulnerability (CVE-2021-44228) demonstrated how a single library flaw could create a critical risk across millions of applications worldwide, from cloud infrastructure to Minecraft servers.
SearchSploit (the Exploit-DB command-line tool) cross-references detected service versions against known CVEs and available exploits. Nuclei runs thousands of templates that fingerprint specific component versions and test for known vulnerabilities in web frameworks, CMS platforms, middleware, and cloud services. Nmap version detection scripts identify exact service versions, and whatweb fingerprints web technologies including JavaScript libraries, CMS versions, and server platforms.
- Maintain a Software Bill of Materials (SBOM) for every application and service.
- Subscribe to security advisories for all components in your stack.
- Implement automated dependency scanning in CI/CD (Dependabot, Snyk, Renovate).
- Establish a patching SLA: critical CVEs within 72 hours, high within two weeks.
- Remove unused dependencies and frameworks to reduce attack surface.
Identification and Authentication Failures
Formerly "Broken Authentication," this category covers weaknesses in how applications verify user identity. This includes credential stuffing, brute-force attacks, weak password policies, flawed session management, JWT implementation errors, and missing multi-factor authentication on sensitive operations.
An application uses JWTs for authentication but sets the algorithm to none or allows the client to specify HS256 when the server expects RS256, enabling an attacker to forge valid tokens. In another scenario, session tokens are predictable or not rotated after login, allowing session fixation attacks. Credential stuffing attacks using breached password lists from previous data breaches remain devastatingly effective because users reuse passwords across services.
Red team operations use hydra for brute-force testing against HTTP login forms, SSH, FTP, and database services. Cewl generates target-specific wordlists by crawling the application. JWT tokens are analyzed for algorithm confusion vulnerabilities, weak signing secrets (tested against common secret lists), missing expiration claims, and information disclosure in payloads. Session management testing covers cookie flags (Secure, HttpOnly, SameSite), session rotation after authentication, and timeout enforcement.
- Implement multi-factor authentication for all user accounts, especially administrative ones.
- Enforce account lockout or progressive delays after failed login attempts.
- Use strong, server-side JWT validation with explicit algorithm specification.
- Rotate session tokens after successful authentication and privilege changes.
- Check passwords against breached password databases (HIBP API) at registration and login.
Software and Data Integrity Failures
This category addresses assumptions made about software updates, critical data, and CI/CD pipelines without verifying integrity. It encompasses insecure deserialization (previously its own category), auto-update mechanisms that do not verify signatures, CI/CD pipelines that can be manipulated, and reliance on untrusted CDNs or package repositories without integrity checks.
The SolarWinds supply chain attack of 2020 remains the definitive example. Attackers compromised the build pipeline for SolarWinds Orion, injecting a backdoor into a legitimate software update that was distributed to approximately 18,000 organizations, including multiple U.S. government agencies. On the deserialization front, Java applications using vulnerable versions of Apache Commons Collections allowed attackers to achieve remote code execution by sending crafted serialized objects.
Testing includes analyzing JavaScript resources loaded from third-party CDNs for Subresource Integrity (SRI) attributes, checking for insecure deserialization in application endpoints, reviewing auto-update mechanisms for signature verification, and identifying CI/CD configuration files exposed in repositories (such as .github/workflows, Jenkinsfile, or .gitlab-ci.yml) that could reveal pipeline manipulation opportunities.
- Use digital signatures and checksums to verify all software updates and packages.
- Implement Subresource Integrity (SRI) for all third-party scripts loaded from CDNs.
- Secure CI/CD pipelines with code review requirements, signed commits, and pipeline access controls.
- Avoid native deserialization of untrusted data. Use simple data formats like JSON.
- Implement dependency pinning and lockfiles to prevent dependency confusion attacks.
Security Logging and Monitoring Failures
Without adequate logging, monitoring, and alerting, breaches go undetected. Industry data consistently shows that the average time to detect a breach exceeds 200 days. This category covers insufficient logging of authentication events, missing alerts for suspicious activity, logs that do not contain enough detail for forensic investigation, and the absence of incident response processes to act on detections.
A company discovers through law enforcement notification that customer data has been available on dark web marketplaces for six months. Upon investigation, they find that the attacker had been accessing their systems through a compromised admin account for over a year. Login events were not logged, failed authentication attempts did not trigger alerts, and there was no monitoring of data exfiltration patterns. The breach affected 4 million customers.
During red team operations, the absence of detection is itself a finding. Operators note when brute-force attempts against login forms generate no lockouts or alerts, when repeated vulnerability scanning against the target generates no defensive response, when path traversal and injection attempts are not blocked by any WAF or IDS, and when the application returns detailed error messages that suggest no error monitoring is in place.
- Log all authentication events (success and failure), access control failures, and input validation errors.
- Ensure logs include sufficient context: timestamp, user identity, IP address, action, and outcome.
- Centralize logs in a SIEM platform with real-time alerting for suspicious patterns.
- Establish an incident response plan and test it with tabletop exercises.
- Set up automated alerts for brute-force attempts, impossible travel, and privilege escalation.
Server-Side Request Forgery (SSRF)
SSRF is a new addition to the OWASP Top 10 and reflects the growing prevalence of cloud-hosted applications. In an SSRF attack, the attacker induces the server-side application to make HTTP requests to an unintended destination. In cloud environments, this often means accessing the instance metadata service (such as AWS's http://169.254.169.254) to steal IAM credentials, or reaching internal services that are not exposed to the internet.
The Capital One breach of 2019 is the most prominent SSRF case. An attacker exploited an SSRF vulnerability in a WAF misconfiguration to access the AWS EC2 metadata service, obtaining IAM role credentials that provided access to S3 buckets containing over 100 million customer records. The attack chain was straightforward: SSRF to metadata to credentials to data exfiltration.
Red team operations test more than 30 parameters across the application (including url, redirect, next, callback, image, proxy, and feed) with SSRF payloads targeting cloud metadata endpoints (AWS, Azure, GCP), internal IP ranges (127.0.0.1, 10.x, 192.168.x), and internal services on common ports. Testing includes DNS rebinding techniques, URL parser confusion, and bypass methods using alternative IP representations (decimal, hex, IPv6 mapped).
- Implement allowlists for outbound requests. Never use denylists alone.
- Disable access to the cloud metadata service from application instances (IMDSv2 on AWS).
- Validate and sanitize all user-supplied URLs on the server side.
- Segment internal networks so that web-facing applications cannot reach sensitive internal services.
- Use network-level controls (security groups, NACLs) to restrict outbound traffic from application servers.
How Specter Forge Tests for All OWASP Top 10 Vulnerabilities
Traditional vulnerability scanners check for individual issues in isolation. Real attackers chain vulnerabilities together. That is why Specter Forge approaches security testing the way an experienced red team operator would: through an 8-phase autonomous operation that mirrors real-world attack methodologies.
Here is how Specter Forge's AI-powered platform maps to the OWASP Top 10:
- A01 Broken Access Control -- Phase 3 (Authorization Testing) performs IDOR enumeration, forced browsing, privilege escalation, and GraphQL introspection across every discovered endpoint.
- A02 Cryptographic Failures -- Phase 7 (Infrastructure Review) runs testssl.sh, sslscan, and sslyze against all services. Phase 1 scans for exposed secrets and credentials in public repositories.
- A03 Injection -- Phase 4 (Injection Testing) deploys sqlmap, commix, and custom XSS/SSTI/XXE/LFI payloads across all input vectors.
- A04 Insecure Design -- Phase 5 (Business Logic Testing) tests rate limiting, CORS policies, file upload restrictions, and race conditions.
- A05 Security Misconfiguration -- Phase 7 checks security headers, Phase 5 probes 60+ debug/dev paths, and Phase 2 tests default credentials.
- A06 Vulnerable Components -- Phase 7 runs SearchSploit for CVE matching, Phase 1 uses nuclei templates for version fingerprinting.
- A07 Authentication Failures -- Phase 2 (Authentication Testing) performs hydra brute-force, JWT analysis, session cookie testing, and password reset abuse.
- A08 Integrity Failures -- Phase 5 checks SRI attributes on third-party scripts. Phase 1 OSINT discovers exposed CI/CD configurations.
- A09 Logging Failures -- Detected implicitly: when brute-force and scanning operations generate no defensive response, it is noted as a finding.
- A10 SSRF -- Phase 4 tests 30+ parameters with cloud metadata payloads (AWS, Azure, GCP) and internal service discovery.
Every finding is classified by severity (Critical, High, Medium, Low, Info) with CVSS scoring, mapped to CWE identifiers, and delivered with specific remediation guidance. The final report meets OSCP-quality standards: executive summary, technical details, evidence screenshots, attack chains, and prioritized remediation steps.
"The best time to find vulnerabilities is before an attacker does. Specter Forge makes that possible at the speed and scale that modern applications demand."
Secure Your Applications Against the OWASP Top 10
Specter Forge autonomously tests for every OWASP Top 10 vulnerability category using real penetration testing tools and AI-powered analysis. Get an OSCP-quality red team report in hours, not weeks.
Start Your First Scan