Guide · How Scanning Works

All 53 StackSecured scan engines, explained

Every check StackSecured runs against your app, grouped by what it actually does and what it takes to unlock it — from passive header reads to real offensive payloads, to the SEO, AEO, and GEO signals that decide whether AI search engines can find and recommend you at all.

41 · Always-Run tier

Passive parsing of JS bundles, HTML source, DNS records, and headers. Zero data mutation, read-only requests, included in every scan without pre-verification — including the free tier.

12 · Verified-Only tier

Genuinely active probes — XSS/SQLi injection, spoofed webhooks, unauthenticated database queries, live requests to a target's own AI feature. Gated strictly behind domain ownership verification (DNS or HTML token) to prevent misuse as a free attack proxy.

Verified-only: the offensive security suite

These twelve only run once you've proven you control the domain being scanned.

Attack Probe (XSS / SQLi / Auth Burst)

Real offensive payload injection attempts and an auth-endpoint request burst against the live target. Strictly gated behind domain ownership to prevent misuse as a free attack proxy.

Authorization (BOLA / IDOR)

Tests ID-bearing routes (e.g. /api/orders/123) and discovered admin routes for unauthenticated access. Does not claim full cross-user BOLA testing.

Supabase RLS (Row Level Security)

Attempts real unauthenticated SELECT queries against every discovered table to test whether RLS policies genuinely block access — not just that an anon key is present.

SSRF Detection

Probes URL-fetching endpoints (image proxies, link previews) with canary targets like cloud metadata IPs and file:// URLs to detect internal network exposure.

Webhook Signature Verification

Sends spoofed webhook payloads with a deliberately wrong or missing signature to confirm whether the endpoint verifies it before acting.

File Upload Authentication

Sends an empty multipart POST to upload endpoints, verifying that authentication is enforced before payload processing — without ever storing a file.

LLM System Prompt Leakage Probe

Sends one extraction-style probe to the target's live AI chat feature, checking the reply for content that reads like a leaked system prompt.

Unauthenticated Model API Drain Checker

Tests whether a "3 free questions" chat limit is enforced server-side or only in client JavaScript — the difference between a real limit and an unlimited free API.

Clerk / Auth0 Webhook Signature Verifier

Sends spoofed webhook payloads matching each provider's real signature scheme (Svix headers for Clerk, Bearer-token pattern for Auth0), not a generic guess.

Edge Middleware Auth-Bypass Probe

Tests the header behind CVE-2025-29927, a real patched Next.js vulnerability where a forged header could skip middleware — and any auth checks living in it.

Public PII & Unmasked Data Harvester

Probes "list everything" endpoints and inspects responses for structurally unambiguous PII — a valid card number, an SSN pattern, a bulk email list.

Prototype Pollution & Object Injection Probe

Sends a __proto__-keyed payload against a control payload of identical shape, checking whether an unsafe object merge can be polluted.

Security — core application checks

Seventeen always-run checks covering secrets, headers, sessions, and the low-level protocol edge cases most scanners skip.

API Key Exposure

Scans client JS bundles for exposed secret keys — OpenAI, Anthropic, Stripe secret, Supabase service-role. Ignores intentional public keys (Supabase anon, Stripe publishable) to prevent false alarms.

Config File Exposure

Probes .env, .git/config, wp-config.php and similar paths, validated against a real content fingerprint per file type — not just a 200 status, which almost every SPA host returns for any path.

CORS Configuration

Sends a spoofed origin header to detect wildcard, reflective, or credentialed CORS misconfigurations that let any website read authenticated responses.

Security Headers

Checks HSTS, CSP, and X-Frame-Options on the homepage, with retry logic so a brief cold-start delay doesn't produce a false "could not be tested."

Admin Route Exposure

Probes sensitive API paths (/api/admin, /api/users) while ignoring page routes that safely redirect to a sign-in screen.

Active/Passive Probe

Passive-tier checks — open-redirect detection and debug-endpoint reachability. The genuinely offensive tier is the separate, verified-only Attack Probe engine below.

GraphQL Security

Checks for unauthenticated introspection (full schema leakage) and whether query batching can be used to bypass per-request rate limits.

Cookie Security

Parses real Set-Cookie response headers to confirm session and auth cookies enforce HttpOnly, Secure, and SameSite.

Source Map Exposure

Checks common Next.js build paths for exposed production .js.map files, which let anyone reconstruct your original, unminified source code.

API Documentation Exposure

Checks standard Swagger/OpenAPI paths and validates the response actually contains API documentation, not just a 200 status.

HTTP Method / TRACE

Sends a raw TRACE request via Node's low-level http module — fetch() refuses to send TRACE at all, which would otherwise silently miss this on every scan.

Error Disclosure

Triggers common error conditions and scans responses for leaked stack traces, framework versions, or raw database error messages.

Open Redirect

Tests common redirect parameters (redirect, next, url) against a spoofed domain — a classic phishing vector when left unvalidated.

Auth Rate Limiting

Fires a burst of concurrent requests at login endpoints to verify credential-stuffing throttling is actually enforced, not just configured.

Next.js Data Leak (__NEXT_DATA__)

Scans the JSON hydration blob every Next.js page embeds in its HTML for secrets, connection strings, or personal data accidentally passed to the client.

Firebase Security

Tests unauthenticated read access to Firestore, Realtime Database, and default Storage — Firebase's default posture is wide open until security rules are explicitly written.

JWT / Session Security

Decodes (never forges) tokens found in cookies and JS bundles; flags alg:"none", missing expiry, and tokens stored without HttpOnly.

WordPress platform

Always attempted, but these only produce findings when the target is actually detected as WordPress — zero findings on a Next.js/Supabase target.

WP REST API User Enumeration

Checks whether /wp-json/wp/v2/users leaks real usernames with no authentication — the first step in credential-stuffing attacks against WordPress.

Active Theme & Plugin Fingerprinter

Identifies the active theme/plugins and checks for cracked-theme malware heuristics and known backdoor filenames — a common entry point on pirated themes.

CMS Migration & Config Leak Detector

Checks for backup and setup artifacts (.bak files, exported SQL dumps, debug logs) left behind during deployment or migration.

XML-RPC Brute Force Inspector

Confirms xmlrpc.php is reachable and checks — via one benign, read-only introspection call — whether it exposes the methods that enable credential-stuffing amplification.

WordPress Platform Detection Note

Always states the WordPress detection outcome either way, so "checked and it's not WordPress" is never confused with "forgot to check."

Edge & serverless

Next.js Server Action Inspector

Compares a same-origin request against a forged cross-origin one to confirm Next.js's built-in Server Action Origin validation is active.

Public Storage Bucket Auditor (S3/R2/GCS)

Checks whether a bucket referenced in client JS is publicly listable — exposing every file anyone has ever uploaded. Read-only; never writes.

Client-Side Secret Filter

Looks for the shape of a hardcoded secret assignment plus raw database connection strings with embedded credentials — catching hand-rolled secrets a vendor-prefix scanner can't.

Compliance

GraphQL Query Batching & Depth Probe

Tests query batching even when introspection is disabled, and checks for a missing query-depth limit — a classic denial-of-service vector.

Cookie Prefix & Attribute Validator

Validates that __Host-/__Secure- cookie prefixes actually meet the exact browser-enforced requirements for that prefix, or the browser silently refuses to set the cookie.

Open gRPC-Web Endpoint Auditor

Only activates when a gRPC-Web/Connect signal is detected in the bundle; checks for unauthenticated methods and exposed server reflection.

Security.txt & RFC 9116 Verifier

Checks for a valid /.well-known/security.txt file, the standard machine-readable way for a researcher who finds a real vulnerability to report it responsibly.

Infrastructure & domain hygiene

Five engines that look past your app code to the DNS, TLS, and dependency layer underneath it.

Technology + CVE Lookup

Fingerprints your tech stack and queries OSV.dev and curated CVE databases. Assigns full severity only when a version number is actually confirmed, never guessed.

Wayback Machine Exposure

Queries the Internet Archive's CDX API for archived secret files that may still sit in permanent public history even after you've removed them from your live site.

Email Security (SPF / DMARC / DKIM / DNSSEC)

Resolves DNS records at the apex domain to verify your email anti-spoofing coverage, and that each record is actually valid, not just present.

TLS Certificate Expiry

Opens a raw HTTPS connection to inspect the SSL/TLS peer certificate's expiration date directly, with handling to avoid crashing on connection errors.

Subdomain Takeover

Matches CNAME records against known abandoned third-party provider signatures (GitHub Pages, S3, Vercel) to flag dangling hosts an attacker could claim.

AI-Code Risk (beta)

Four heuristic engines aimed specifically at mistakes common in AI-generated code — surfaced as warnings worth a human look, never confirmed vulnerabilities.

AI-Code Risk Signals

A static-pattern scan for mistakes specific to AI-generated code — client-side-only authorization checks and direct client-side database mutations with no server gate. Capped at Medium severity and phrased as advisory.

Business Logic Signals

Flags observable client-side business-logic anomalies worth human review — like client-controlled pricing fields. Explicitly low-confidence, not a confirmed exploit.

Prompt Injection Surface Scanner

Looks for a system instruction and untrusted user input concatenated into one string with no separation, before being sent to an LLM API.

Insecure LLM Output (AI-XSS)

Checks whether AI-generated output is rendered via dangerouslySetInnerHTML with no sanitizer present — letting the model become an unintended XSS delivery path.

Visibility: SEO, AEO & GEO

Three engines included free with every scan — because getting found by search engines and AI assistants is a launch requirement, not a nice-to-have.

SEO Signals

Audits traditional search fundamentals — titles, meta descriptions, Open Graph tags, canonical tags, mobile viewport — and robots.txt content itself, to catch an accidental Disallow: / blocking every crawler.

AEO — Answer Engine Optimization

Evaluates the structured data (JSON-LD, FAQ schema, HowTo schema) and verified contact pages that conversational AI engines look for before citing a product directly in an answer.

GEO — Generative Engine Optimization

Checks entity trust signals — Organization schema, Person/founder schema, linked social profiles, privacy and terms pages — that LLM-powered search weighs when deciding whether to recommend a brand at all.

See all 53 engines run against your own app

StackSecured runs every always-run engine free, in about 30 seconds — verify domain ownership to unlock the twelve offensive engines too.

Run a free scan

Common questions

What's the difference between "Always-Run" and "Verified-Only" engines?

+

Always-Run engines (41 of the 53) are passive, non-destructive checks — reading HTML, response headers, DNS records, and public archives. They're safe to run against any URL without proof of ownership. Verified-Only engines (12) are genuinely active: real XSS/SQLi payloads, spoofed webhook events, unauthenticated database queries, live requests against a target's own AI chat feature. Those only fire once you've proven domain control via a DNS or HTML token, so the scanner can't be used as an anonymous attack proxy against a site you don't own.

Does StackSecured ever attack a site without permission?

+

No. The twelve offensive engines — including Attack Probe, Authorization, Supabase RLS, SSRF, Webhook Signature Verification, and Edge Middleware Auth-Bypass Probe — are hard-gated behind domain ownership verification. Until that check passes, only the 41 passive, always-run engines run.

How reliable is the AI-Code Risk (beta) category?

+

It's intentionally conservative. Findings are capped at Medium severity, phrased as advisory rather than confirmed, and the engines explicitly state that an unauthenticated scan of a public JS bundle can't prove a flaw exists — only that a pattern is worth a human second look.

What are AEO and GEO, and why do they matter alongside SEO?

+

SEO gets your app found by traditional search engines. AEO (Answer Engine Optimization) and GEO (Generative Engine Optimization) are the same idea applied to AI systems — ChatGPT, Perplexity, Google AI Overviews — that answer questions directly instead of listing links. They check the structured data and trust signals those systems use to decide whether to cite or recommend a product at all.

Do all 53 engines run on every scan?

+

All 41 always-run engines run on every scan, including the free tier. Whether you get all 53 depends on domain verification: the 12 verified-only engines only run once ownership is confirmed. Visibility (SEO/AEO/GEO) results are always shown in full and are never paywalled.

More guides: Supabase RLS: the #1 vibe-coding bug · Exposed API keys in AI-built apps · Full vibe-coding security checklist · IDOR: the sequential-ID bug · Webhook signature verification