Security Roundup March 31 – April 6, 2026: OWASP Top 10 Scanner Coverage, TLS Misconfigs at Scale & SQLi Still Everywhere

1. The OWASP Top 10 Scanner Coverage Gap

Ask any security team if they scan for the OWASP Top 10 and the answer is almost always yes. Ask them which specific categories their scanner covers and the confidence drops fast.

The reality: most automated scanners provide strong coverage for three categories and partial-to-no coverage for the remaining seven.

The takeaway: if your security program relies solely on automated scanning, you likely have blind spots in at least four OWASP categories. The fix isn't to abandon automation — it's to understand what your scanner covers and supplement with manual testing or specialized tools for the gaps.

What to Do About It

• Map your scanner's coverage against each OWASP category explicitly. Most vendors don't publish this mapping clearly.
• Layer specialized tools for weak categories: SCA for A06, SAST for A04/A08, and manual pen testing for A01/A04.
• Prioritize A03 and A10 for automated testing — injection and SSRF are the categories where automation has the highest ROI and attackers are most active.

2. TLS Misconfigurations: Still the #1 Cryptographic Failure

OWASP A02 (Cryptographic Failures) sounds abstract until you realize the most common manifestation is straightforward: bad TLS configuration. And it's everywhere.

The pattern repeats across organizations of every size: TLS is configured once during initial deployment, then never audited again. Certificates expire. Cipher suites that were acceptable in 2022 are now deprecated. HSTS headers are missing or misconfigured. And because "the site loads fine over HTTPS," nobody notices.

The Five TLS Checks Every Scanner Should Run

1. Protocol version — TLS 1.0 and 1.1 are deprecated (RFC 8996). Only TLS 1.2+ should be accepted. TLS 1.3 is preferred.
2. Cipher suite strength — RC4, DES, 3DES, and export-grade ciphers must be disabled. Look for suites with forward secrecy (ECDHE/DHE).
3. Certificate validity — Check expiration date, chain completeness, and whether the cert matches the hostname. Wildcard certs covering too many services are a risk.
4. HSTS enforcement — The Strict-Transport-Security header should be present with max-age of at least 31536000 (1 year). includeSubDomains and preload are recommended.
5. Certificate transparency — Verify the certificate appears in CT logs. Certificates not logged in CT are increasingly flagged by browsers.

If your scanner doesn't check all five, you have a gap. Our TLS auditing deep dive covers each check in detail with remediation steps.

3. SQL Injection in 2026: WAF Bypass Patterns That Still Work

SQL injection is 26 years old and still the most exploited injection flaw in web applications. OWASP ranks it A03. Every major breach database includes SQLi as a root cause. And yet, it persists — not because we don't know how to prevent it, but because the attack surface keeps expanding and bypass techniques keep evolving.

Why WAFs Aren't Enough

Web Application Firewalls catch the obvious patterns: OR 1=1, UNION SELECT, DROP TABLE. But modern SQLi bypass techniques exploit the gap between what the WAF parses and what the database executes:

• Double URL encoding — %2527 decodes to %27 at the WAF layer, then to ' at the application layer. The WAF sees a harmless encoded string; the database sees a quote.
• Comment injection — SEL/**/ECT breaks WAF keyword matching but executes normally on MySQL. Each database has different comment syntax that can be exploited.
• Boolean-based blind injection — No error output, no UNION results. The attacker infers data by comparing response lengths: AND 1=1 (normal response) vs AND 1=2 (different response). WAFs that look for error strings miss this entirely.
• Database-specific syntax — PostgreSQL's $$ string quoting, MySQL's backtick identifiers, MSSQL's EXEC vs EXECUTE — each database accepts syntax the others don't, and WAF rules rarely cover all variants.

The fix is defense in depth: parameterized queries at the code level (not WAF-level filtering), least-privilege database accounts, and scanners that test for blind injection variants — not just error-based. Our SQLi detection guide covers what a thorough scanner should check.

4. Next.js, API Gateways & the New Attack Surface

The web stack has shifted. Next.js is now the default React framework. API gateways sit in front of every microservice. And both introduce attack surface that traditional web scanners weren't built to test.

Next.js Reconnaissance Targets

Next.js applications expose predictable endpoints that reveal application structure:

• /_next/data/ — Server-side props data, often containing internal API responses
• /_next/static/ — Build manifests that reveal every route in the application
• /api/ — API routes that may lack the same auth middleware as page routes
• Source maps in development builds that expose the full source code

Most vulnerability scanners don't check these paths. A Next.js-aware recon tool should enumerate routes from the build manifest, check for exposed source maps, and test API routes independently from page routes.

API Gateway CORS Misconfigurations

API gateways (AWS API Gateway, Kong, Nginx) frequently have CORS policies that are too permissive:

• Access-Control-Allow-Origin: * on authenticated endpoints — allows any origin to make credentialed requests
• Reflecting the Origin header back without validation — effectively the same as wildcard but harder to detect in config review
• Missing Access-Control-Allow-Credentials: true check — the gateway allows cross-origin requests but the developer assumes CORS blocks them

These misconfigurations are especially dangerous when the API gateway sits in front of internal services. A CORS tester that sends requests with various Origin headers and checks the response policy is essential. See our SecurityClaw new skills roundup for how automated CORS testing works in practice.

5. Scanner Landscape: What Changed This Week

The gap between "what scanners check" and "what attackers exploit" narrowed this week with several new detection capabilities shipping across the ecosystem:

The trend is clear: scanners are moving from generic vulnerability signatures toward OWASP-category-specific detection modules. This is the right direction — but it means security teams need to actively track which categories their toolchain covers and update their scanning configuration as new capabilities ship.

6. Action Items for Security Teams

7. Essential Tools & Resources

Scanning & Testing

• OWASP ZAP — Free, open-source web app scanner. Strong A03 coverage. See our ZAP vs Burp comparison.
• Nuclei — Template-based scanner with community-contributed detection rules. See our Nuclei comparison.
• testssl.sh — Command-line TLS testing tool. Checks protocols, ciphers, certificates, and headers.
• sqlmap — Automated SQL injection detection and exploitation. Supports blind, error-based, and time-based techniques.

References

• OWASP Top 10 (2021) — The definitive web application security risk list
• OWASP Cheat Sheet Series — Practical remediation guidance for each category
• CISA KEV Catalog — Known exploited vulnerabilities requiring immediate attention

Further Reading on This Site

• Detecting SQL Injection: What Your Scanner Should Check in 2026
• How to Audit TLS Configuration: What Your Scanner Should Check in 2026
• 4 New SecurityClaw Skills That Change How You Recon Web Applications
• How to Automate OWASP ZAP Scans in GitHub Actions

Bottom Line

The OWASP Top 10 hasn't changed since 2021, but the attack surface has. Next.js, API gateways, and cloud-native architectures introduce risks that the 2021 list anticipated but most scanners still don't cover well. The gap is closing — new detection capabilities for CORS, TLS, SQLi, and framework-specific recon shipped this week — but security teams need to actively manage their coverage map rather than assuming "we scan for OWASP" means "we're covered."

Next week: we'll cover SSRF detection techniques and how cloud metadata endpoints remain the most exploited SSRF target in 2026.