SecurityClaw Closes the OWASP Gap: 5 New Skills Ship in One Sprint

Published April 2026 · 8 min read

SecurityClaw just shipped 5 new scanning skills in a single sprint. That's not a typo. Five skills, each covering a different OWASP Top 10 category, all built, tested, reviewed, and merged in under 48 hours.

Before this sprint, SecurityClaw had clear gaps in its OWASP coverage. After it, the platform covers 8 out of 10 categories. Here's what shipped, what each skill detects, and why it matters for your security testing workflow.

1. The Sprint at a Glance

Four of the five skills are passive — they analyse responses without modifying requests. Only ssrf-probe is active, injecting SSRF payloads into URL parameters to test for server-side request forgery. This distinction matters: passive skills can run against any target without risk, while active skills require explicit approval before execution.

2. ssrf-probe — SSRF Detection (A10)

The headline skill of the sprint. SSRF is the vulnerability that turned cloud metadata endpoints into data exfiltration channels — it was the root cause of the Capital One breach and remains one of the most dangerous web application vulnerabilities in cloud environments.

The ssrf-probe skill injects 6 payloads into URL query parameters:

• http://169.254.169.254/latest/meta-data/ — AWS instance metadata
• http://metadata.google.internal/computeMetadata/v1/ — GCP metadata
• http://169.254.169.254/metadata/instance?api-version=2021-02-01 — Azure IMDS
• http://localhost/ and http://127.0.0.1/ — localhost access
• file:///etc/passwd — local file read

For each injection, the skill analyses the response for cloud metadata signatures (AMI IDs, IAM credential paths, GCP computeMetadata strings, Azure subscription IDs), file content patterns (/etc/passwd format), internal IP addresses, and URL reflection. Findings are classified from MEDIUM (URL reflection) to CRITICAL (cloud metadata or file read).

For a deep dive on SSRF detection and remediation, see our full article: Server-Side Request Forgery in 2026: What Your Scanner Should Detect.

3. sri-checker — Subresource Integrity (A08)

Subresource Integrity is the defence against CDN supply-chain attacks. When your page loads a script from a CDN, the integrity attribute tells the browser to verify the file's hash before executing it. Without SRI, a compromised CDN can inject malicious code into every site that loads from it.

This isn't theoretical. The Polyfill.io incident demonstrated exactly this attack at scale — a widely-used CDN was acquired and began serving malicious JavaScript to millions of sites.

The sri-checker skill scans HTML responses for <script> and <link rel="stylesheet"> tags that load from external domains without an integrity attribute. Scripts without SRI are flagged as HIGH severity (executable code), stylesheets as MEDIUM (CSS injection is lower impact but still exploitable).

The fix is straightforward: add integrity="sha384-..." and crossorigin="anonymous" to every CDN-loaded resource. Most CDN providers publish the correct hash values, and tools like srihash.org can generate them.

4. session-security-tester — Session Cookie Security (A07)

Session cookies are the keys to your users' accounts. If they're not configured correctly, attackers can steal them via XSS (missing HttpOnly), intercept them over unencrypted connections (missing Secure), or use them in cross-site request forgery attacks (missing SameSite).

The session-security-tester checks three cookie flags:

The skill also checks for session fixation — a vulnerability where a session cookie set before authentication isn't rotated after login. If the pre-auth session ID persists, an attacker who knows it can hijack the authenticated session.

5. security-header-checker — HTTP Security Headers (A04)

Security headers are the cheapest defence you can deploy. They're response headers that tell the browser to enable security features — and most applications are missing at least half of them.

The security-header-checker inspects responses for 7 headers:

For a complete guide to implementing these headers, see our article: Security Headers in 2026: The Complete Guide.

6. logging-monitor-checker — Logging and Monitoring (A09)

OWASP A09 is the hardest category to scan for because it's about what's not there — missing logs, missing alerts, missing monitoring. You can't detect the absence of logging from the outside.

The logging-monitor-checker takes a pragmatic approach, checking for observable indicators:

• Missing X-Request-ID header (MEDIUM) — indicates the application doesn't correlate requests for debugging and incident response
• Verbose error messages (HIGH) — stack traces, database errors, and framework debug output in responses indicate debug mode is enabled in production, which means logging is likely misconfigured too
• Missing rate limiting headers (MEDIUM) — no X-RateLimit-* or Retry-After headers suggests no rate limiting, which means brute-force attacks won't be detected or blocked
• Exposed debug endpoints (HIGH) — accessible /debug, /status, or framework-specific debug pages indicate monitoring infrastructure is exposed

This is partial A09 coverage — a full logging audit requires access to the application's backend. But these external indicators catch the most common misconfigurations.

7. Updated OWASP Coverage Map

Here's where SecurityClaw stands after this sprint:

From 5/10 categories covered to 8/10 (with 2 partial) in a single sprint. The remaining full gap is A06 (Vulnerable and Outdated Components) — detecting known CVEs in third-party libraries requires a dependency scanning approach rather than HTTP-level probing.

8. What's Still Missing

Two categories still need work:

• A06 — Vulnerable and Outdated Components: The tech-stack-cve-scanner provides partial coverage by fingerprinting server technologies and checking for known CVEs. Full coverage would require dependency-level scanning (like Trivy or Snyk) integrated into the pipeline.
• A09 — Security Logging and Monitoring Failures: The logging-monitor-checker catches external indicators, but true A09 coverage requires backend access to verify that security events are actually being logged, alerts are configured, and incident response procedures exist.

For the full OWASP coverage analysis, see: SecurityClaw OWASP Top 10 Coverage in 2026.