SecurityClaw OWASP Top 10 Coverage in 2026: What's Covered, What's Not, and What's Next

Published April 7, 2026 · 10 min read

If you're evaluating a security scanning platform, the first question is always: what does it actually detect?

The OWASP Top 10 (2021 edition, still the current standard in 2026) is the baseline. Any serious scanner should map its detection capabilities against these 10 categories. If it can't tell you which categories it covers — and more importantly, which it doesn't — that's a red flag.

SecurityClaw now has 33 active scanning skills and covers 7 of 10 OWASP Top 10 categories. That's up from 4 categories just two weeks ago. Here's what changed, what each skill detects, and where the gaps remain.

Coverage Summary

A01: Broken Access Control — Good Coverage

Broken access control has been the #1 OWASP category since 2021, and SecurityClaw has the deepest coverage here with 5 skills:

• idor-scanner — Tests for Insecure Direct Object References by manipulating resource IDs in API endpoints. Catches the classic "change the user ID in the URL and see someone else's data" vulnerability.
• api-schema-discovery — Discovers undocumented API endpoints by analyzing OpenAPI/Swagger specs, JavaScript bundles, and common path patterns. Finds endpoints that developers forgot to protect.
• business-logic-scanner — Tests for authorization bypass and injection in business logic flows. Goes beyond simple IDOR to test multi-step workflows.
• auth-portal-tester — Tests authentication portals for IDOR and account takeover vectors. Currently in Tier 3 review (requires approval for active testing).
• authenticated_api_sweep — Sweeps authenticated API endpoints for broken access control patterns using valid session tokens.

Practitioner note: The combination of api-schema-discovery + idor-scanner is particularly effective. Discovery finds the endpoints; IDOR tests whether they're properly protected. Run them in sequence.

A02: Cryptographic Failures — New Coverage

Added in the last sprint: the tls-crypto-auditor skill covers the most common cryptographic failures seen in the wild:

• TLS version detection (flags TLS 1.0/1.1, requires 1.2+)
• Cipher suite analysis (flags weak ciphers: RC4, DES, 3DES, export-grade)
• Certificate validation (expiry, self-signed, wrong hostname)
• HSTS header presence and configuration

For a deep dive on what TLS auditing should cover, see our TLS auditing guide.

A03: Injection — Strong Coverage

This is where the biggest improvement happened. Two weeks ago, SecurityClaw had no dedicated injection detection. Now it has three specialized skills:

• xss-probe — Reflected XSS detection with 7 payload patterns, context-aware severity (HIGH for unfiltered reflection, MEDIUM for partial encoding, LOW for encoded output), and WAF bypass techniques. See our XSS detection guide.
• sqli-probe — Error-based and boolean-based SQL injection detection across 4 database engines (MySQL, PostgreSQL, MSSQL, SQLite). Uses 7 payloads with 14 error signature patterns. Database fingerprinting included. See our SQLi detection guide.
• ssrf-hypothesis — Hypothesis-driven SSRF detection that tests URL parameters for server-side request forgery indicators.

What's missing from A03: No dedicated command injection, LDAP injection, or template injection detection yet. These are lower-frequency than SQLi/XSS but still relevant for certain application stacks.

A05: Security Misconfiguration — Good Coverage

SecurityClaw's original strength. Four skills cover the most common misconfiguration patterns:

• apigw-cors-tester — Tests API gateway CORS configurations for overly permissive origins, credential leakage, and wildcard misuse.
• header-analysis — Checks security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• nextjs-recon — Next.js-specific reconnaissance: exposed _next/data routes, leaked environment variables, misconfigured rewrites, route enumeration.
• waf-detection — Identifies WAF presence and type. Useful for understanding what's between you and the target, not a vulnerability itself but critical context for other skills.

The 4 new skills article covers apigw-cors-tester and nextjs-recon in detail.

A06: Vulnerable and Outdated Components — Improved

Two skills now cover component-level vulnerabilities:

• tech-stack-cve-scanner — Fingerprints technology stacks (frameworks, libraries, server software) and cross-references against known CVEs. This is the "is your jQuery version vulnerable?" check at scale.
• webmail-cve-fingerprint — Specialized fingerprinting for webmail platforms (Roundcube, Zimbra, Horde, SquirrelMail) with CVE cross-referencing. Webmail is a high-value target because it's often internet-facing and running outdated versions.

A07: Identification and Authentication Failures — Thin Coverage

This is the weakest covered category. Three skills exist, but they're all OAuth-specific:

• oauth-security-analysis — Analyzes OAuth implementation for common misconfigurations
• oauth-client-enum — Enumerates OAuth client IDs and redirect URIs
• oauth_scope_abuse — Tests for OAuth scope escalation

What's missing: No detection for weak password policies, missing account lockout, session fixation, session ID predictability, or missing MFA indicators. If your target doesn't use OAuth, A07 coverage is effectively zero.

A10: Server-Side Request Forgery — New Coverage

The newest addition: ssrf-probe detects SSRF vulnerabilities by testing URL parameters for server-side request behavior:

• Cloud metadata endpoint detection (AWS 169.254.169.254, GCP, Azure)
• Localhost/internal IP reflection
• file:// protocol path disclosure
• Response content analysis for leaked internal data

Combined with the existing ssrf-hypothesis skill, SecurityClaw now has two complementary approaches to SSRF detection — hypothesis-driven (passive analysis) and probe-based (active testing).

The Gaps: A04, A08, A09

Three OWASP categories have zero coverage. Here's why, and whether that's fixable:

A04: Insecure Design — Hard to Automate

Insecure design flaws are business logic problems: missing rate limiting on login endpoints, no anti-automation on signup flows, predictable resource generation, missing fraud controls. These require understanding the intent of the application, which scanners fundamentally can't do.

What could be automated: Rate limiting detection (send N requests, check for 429 responses), CAPTCHA presence checks, and anti-automation header analysis. These are proxy signals, not direct insecure design detection.

A08: Software and Data Integrity Failures — Addressable

This is the most fixable gap. The primary automated check: Subresource Integrity (SRI). Any <script> or <link> tag loading from a CDN without an integrity attribute is a supply chain attack vector. A scanner can detect this by parsing HTML — no active testing required.

An SRI checker skill is on the roadmap. It's a passive, low-risk skill that would immediately close the A08 gap for the most common attack vector in this category.

A09: Security Logging and Monitoring Failures — Largely Undetectable

This is an operational concern. You can't tell from the outside whether an application is logging security events properly. The closest proxy signals: presence of Report-To, NEL (Network Error Logging), and Content-Security-Policy-Report-Only headers, which indicate the application has some monitoring infrastructure. But absence of these headers doesn't mean logging is absent — it just means it's not browser-reported.

Honest assessment: A09 will likely remain a gap for any external scanner. This is a category best addressed through code review and infrastructure audits, not automated scanning.

What's Coming Next

Based on the current gap analysis, the SecurityClaw roadmap includes:

1. SRI Checker (A08) — Detect missing Subresource Integrity on CDN-loaded scripts and stylesheets. Currently in development.
2. Session Security Tester (A07) — Check cookie flags (Secure, HttpOnly, SameSite), session ID entropy, and session fixation. Would expand A07 coverage beyond OAuth.
3. SKILL_MANIFEST backfill — 8 existing skills are missing manifests, which means their coverage isn't tracked. Backfilling these may reveal coverage that already exists but isn't mapped.

Bottom Line

7 out of 10 is solid for an automated scanner. The three gaps (A04, A08, A09) include two categories that are inherently difficult to automate (insecure design, logging failures) and one that's actively being addressed (data integrity via SRI checking).

The real story is the velocity: SecurityClaw went from 4 OWASP categories to 7 in two weeks, adding dedicated injection detection (XSS, SQLi), cryptographic auditing (TLS), SSRF probing, and component vulnerability scanning. That's the kind of coverage expansion that matters when you're choosing a platform.

No scanner covers everything. The honest ones tell you what they don't cover. Now you know.