4 New SecurityClaw Skills That Change How You Recon Web Applications

1. nextjs-recon: Next.js Runtime Config Extractor

The Problem

SecurityClaw's existing JS bundle analyser fetches static JavaScript chunks and searches for hardcoded URLs, API keys, and secrets. That works well for React apps that bake configuration into the bundle at build time. But Next.js applications increasingly use runtime-injected configuration — API gateway URLs, auth endpoints, and NEXT_PUBLIC_* environment variables are injected at render time via server-side rendering, not compiled into static chunks.

During a recent campaign, the scanner found nothing in the static JS bundles of a Next.js target. The interesting configuration — internal API gateway URLs, CloudFront distribution endpoints, authentication service URLs — was all in the __NEXT_DATA__ SSR JSON blob that the existing skill never looked at.

What It Does

The nextjs-recon skill specifically targets Next.js applications:

• Extracts the <script id="__NEXT_DATA__"> JSON blob from server-rendered pages and walks it recursively for URLs, API paths, client IDs, and NEXT_PUBLIC_* variables
• Fetches the build manifest (/_next/static/<buildId>/_buildManifest.js) to enumerate every page route in the application — including routes not linked from the UI
• Probes SSG (Static Site Generation) data routes (/_next/data/<buildId>/<route>.json) for unauthenticated access to pre-rendered page data
• Analyses large JS chunks (>30KB) for hardcoded tokens and secrets that survived the build process

Why It Matters

Next.js is the most popular React framework. A significant percentage of modern web applications are built on it. The __NEXT_DATA__ blob is present on every server-rendered page and often contains internal infrastructure details that developers don't realize are publicly visible. The build manifest route enumeration is particularly valuable — it reveals every page in the application, including admin panels, API documentation pages, and internal tools that aren't linked from the main navigation.

Where It Fits

Run nextjs-recon early in the recon phase, right after technology fingerprinting confirms a Next.js target. Its output feeds directly into other skills: discovered API URLs become targets for the CORS tester, discovered routes become targets for the authenticated portal tester, and discovered secrets get flagged immediately.

2. apigw-cors-tester: API Gateway CORS Vulnerability Tester

The Problem

CORS misconfigurations are one of the most common and most impactful web security issues — and they're surprisingly hard to test systematically. The standard check (send an Origin header, see if it's reflected) catches the obvious cases, but misses subtler patterns: wildcard CORS with credentials, null origin acceptance, suffix confusion bypasses, and the specific behaviour of AWS API Gateway's CORS implementation.

During the same campaign, two AWS API Gateway endpoints serving customer authentication and account management returned Access-Control-Allow-Origin: *. This was a HIGH finding that required manual testing to confirm. A dedicated skill would catch this pattern automatically on every campaign.

What It Does

The apigw-cors-tester skill runs a battery of CORS tests against each target endpoint:

When a wildcard CORS issue is confirmed, the skill generates a ready-to-use JavaScript proof-of-concept snippet demonstrating the exploit. This saves time during report writing and makes the finding immediately reproducible.

Severity Classification

• CRITICAL: Wildcard CORS with credentials (ACAO: * + ACAC: true) — any site can make authenticated requests
• HIGH: Wildcard CORS on authentication or account management endpoints
• MEDIUM: Wildcard CORS on static or public-data endpoints

Where It Fits

Run after endpoint discovery. The nextjs-recon skill discovers API URLs; the CORS tester checks each one. In SecurityClaw's Adaptive Campaign Graph, this chain happens automatically — when nextjs-recon outputs API URLs, the graph triggers apigw-cors-tester against each one.

3. webmail-cve-fingerprint: Webmail Version + CVE Lookup

The Problem

Webmail platforms (Roundcube, Zimbra, Horde, SquirrelMail, and proprietary solutions) frequently disclose their exact version in the HTML title, JavaScript variables, or file query strings. During the recent campaign, a target's webmail portal displayed Securemail 3.0.133 right in the page title. The scanner saw it but couldn't do anything with it — there was no automated way to cross-reference that version against known CVEs.

What It Does

The webmail-cve-fingerprint skill combines version extraction with live CVE lookup:

1. Fingerprints the platform — identifies Roundcube, Zimbra, Horde, SOGo, SquirrelMail, and proprietary webmail from page content
2. Extracts the version — checks HTML titles, JavaScript variables (window.VERSION, window.APP_VERSION), file query strings, and HTTP headers
3. Queries the NVD — hits the NIST National Vulnerability Database API with the platform name and version to find known CVEs
4. Ranks by severity — returns CVEs sorted by CVSS score, with a has_critical flag for immediate attention

Why It Matters

Webmail is a high-value target on ISP and enterprise networks. These platforms handle email — which means password reset flows, two-factor codes, and sensitive communications all pass through them. A known CVE in the webmail platform can be the fastest path to account compromise. The skill turns a passive observation ("I see a version number") into an actionable finding ("this version has 3 known CVEs, the worst is CVSS 9.8").

Where It Fits

Run during the fingerprinting phase, alongside technology detection. When the scanner identifies a webmail login page, this skill automatically extracts the version and checks for known vulnerabilities. No manual CVE research needed.

4. auth-portal-tester: Authenticated Portal IDOR Tester

The Problem

Customer self-service portals — ISP account management, SaaS dashboards, banking portals — are where the highest-value vulnerabilities live. They're also where most automated scanners stop. The portal returns 403 to unauthenticated requests, and the scanner moves on. But behind that 403 are endpoints handling account data, billing information, and personal details — all potentially vulnerable to IDOR (Insecure Direct Object Reference) and authorization bypass.

SecurityClaw already had individual skills for account registration, authenticated API sweeping, and IDOR scanning. What it lacked was a skill that orchestrated the full flow: log in → establish a session → discover endpoints → test for IDOR — all in one automated sequence.

What It Does

The auth-portal-tester skill runs a four-phase attack sequence:

1. Login — Handles form-based authentication including CSRF token extraction, cookie-based session management, and login verification
2. Endpoint Discovery — Crawls authenticated pages (max depth 2, max 50 pages), extracts XHR/fetch API calls from JavaScript, and builds a map of all API endpoints with their HTTP methods
3. IDOR Testing — For endpoints with ID parameters (sequential integers, UUIDs, account numbers), tests adjacent values and cross-account access. If a second test account is provided, it tests whether account 1 can access account 2's resources.
4. Auth Bypass — Tests each authenticated endpoint with no session cookie and with modified/expired tokens to find missing authentication enforcement

Why It Matters

IDOR is consistently one of the most reported vulnerability types on bug bounty platforms. It's also one of the hardest to find with automated tools because it requires authenticated access and cross-account testing. This skill bridges the gap between "the scanner found a login page" and "the scanner found that user A can read user B's account data." That's the difference between an informational finding and a critical vulnerability report.

Security Note

This skill handles credentials. By design, credentials are never logged, never stored in scan results, and never persisted beyond the active session. The skill was reviewed by the security team before merge specifically for credential handling safety.

Where It Fits

This is a late-stage skill — it runs after reconnaissance, fingerprinting, and endpoint discovery have identified a customer portal worth testing. It's the skill that turns a 403 wall into actionable findings. In the Adaptive Campaign Graph, it triggers when the scanner identifies a login page on a target that's in scope for authenticated testing.

5. How They Fit Together in a Campaign

These four skills aren't isolated tools — they form a chain that SecurityClaw's Adaptive Campaign Graph can execute automatically:

1. Technology fingerprinting identifies a Next.js application behind CloudFront
2. nextjs-recon extracts API gateway URLs, routes, and environment variables from __NEXT_DATA__
3. apigw-cors-tester tests each discovered API URL for CORS misconfigurations
4. webmail-cve-fingerprint runs against any webmail subdomain discovered during DNS enumeration
5. auth-portal-tester logs into the customer portal (if test credentials are available) and tests for IDOR and authorization bypass

The campaign graph handles the chaining automatically. When nextjs-recon outputs API URLs, the graph triggers the CORS tester. When the CORS tester finds a wildcard on an auth endpoint, the graph escalates the severity. No manual intervention required — the scanner reasons about what to test next based on what it's already found.

This is the same pattern described in our Phase B AI Campaign Engine article — but with four new skills feeding into the graph, the scanner's coverage of modern web application attack surfaces is significantly broader.

6. What's Next

These skills were all born from gaps found during a single live campaign. That's the development model: run campaigns, hit walls, build skills to break through those walls, run the next campaign with more capability.

The immediate roadmap includes expanding the nextjs-recon skill to handle other SSR frameworks (Nuxt.js, SvelteKit, Remix), adding GraphQL introspection to the CORS tester, and building a credential-safe test account provisioning system for the auth portal tester.

For a deeper look at how SecurityClaw's campaign engine chains skills together, see our Phase C Hypothesis Engine article. For a comparison of SecurityClaw's approach against traditional scanning tools, check our ZAP vs Burp Suite comparison.