How AuditCore actually works.
No black box. We document every scanner, every phase, every limitation — so you can decide whether the report belongs in your security review pipeline.
Each scan flows through five sequential phases
Earlier phases inform later ones — recon discovers endpoints that the crawl uses, crawl produces requests that auth-testing replays cross-role, auth-tested requests are fuzzed in the injection phase. Static analysis is independent and runs only when source or binaries are provided.
Phase 1 — Reconnaissance
Map the attack surface before touching anything intrusive.
- DMARC / SPF / DKIM email-spoof posture (checkdmarc)
- Subdomain enumeration (subfinder + crt.sh) + alive probing (httpx)
- Directory bruteforce on alive hosts (ffuf)
- Historical URL pull from Wayback / OTX / Common Crawl (gau)
- Subdomain takeover check across 20+ service fingerprints
- WAF / CDN fingerprint (Cloudflare, Akamai, Imperva, AWS WAF, F5, Sucuri…)
Phase 2 — Crawl
Capture real HTTP traffic the way a browser uses it — not just GETs.
- Playwright (headless Chromium) routes through OWASP ZAP proxy
- Records every request, response, cookie, header, body for downstream analysis
- Multi-role traversal when credentials are provided (drives BOLA/BFLA)
- App-type auto-detect: e-commerce / blog / SaaS / corporate / WordPress
Phase 3 — Auth & Authorization
The vulnerability class most automated scanners miss.
- JWT analyzer: alg:none, weak HMAC, sensitive data in payload, expiry flags
- Session fixation, cookie flag audit (Secure / HttpOnly / SameSite / __Host-)
- OAuth flow review (redirect_uri abuse, missing state, HTTP token endpoint)
- BOLA / BFLA via cross-role request replay (when 2 roles supplied)
- Header analyzer: 7 security headers + 3 leaky ones
- TLS posture (SSLyze: Heartbleed, weak ciphers, TLS ≤ 1.1, cert chain)
Phase 4 — Injection & Fuzzing
Active payload-based testing on discovered endpoints.
- OWASP ZAP active scan + Nuclei (8000+ community templates)
- sqlmap (boolean / error / union — non-destructive techniques)
- Custom analyzers: SSTI, XXE, command injection, path traversal, NoSQL, prototype pollution
- SSRF (cloud metadata + internal IPs), HTTP smuggling (CL.TE, TE obfuscation)
- Race conditions via HTTP/2 single-packet attack (Kettle 2023 technique)
- Business logic: price/quantity tamper, currency switch, status forge, role elevation
- AI agent / chatbot testing: 80+ prompt-injection payloads + Claude-generated targeted attacks
Phase 5 — Static Analysis
When source / binaries are provided, we read them too.
- Semgrep with p/security-audit rule pack (1000+ patterns)
- Gitleaks: secrets in git history (API keys, passwords, tokens)
- Trivy: dependency CVE scan on package-lock / requirements / Gemfile.lock
- MobSF (APK / IPA): manifest, permissions, strings, network config, code, binary
- Native APK analyzers: 14 tracker SDKs, ECB/MD5/SHA1 weak crypto, JS-bridge, root detection
52 scanners + 1 AI orchestrator
Each scanner is a Python class implementing a common interface (run() → RawScanResult, then normalize() → list[Vulnerability]). They run in parallel within a phase and communicate findings through a shared DB-backed result set so later scanners can reuse what earlier ones discovered.
Tier mapping
Where Claude helps — and where it doesn't
We use Claude Sonnet 4 for three things, all deterministic (temperature=0) and Redis-cached for reproducibility.
AI Context Scanner
After crawl, Claude reads the discovered surface (URLs, forms, tech hints) and generates a custom test plan. Max 5 calls per scan, capped cost.
Generative AI agent payloads
For chatbot testing: we send a benign opener, capture the bot's persona, then Claude crafts 5 prompt-injection payloads tailored to that specific bot — alongside our 80 static payloads.
FP triage
Noisy scanner output (Nuclei templates, banner-grab CVE) goes through Claude flagging likely false positives. Only HIGH-confidence flags auto-apply; you can revert any in dashboard.
Honest limitations
Automated scanning has hard boundaries. AuditCore supplements but does not replace manual penetration testing or red-teaming for high-stakes systems.
We don't guarantee discovery of all vulnerabilities
Complex business-logic flaws beyond our heuristics, vulnerabilities requiring specific application state, dynamic issues only present under load, or zero-day vulnerabilities without published signatures — these will not be caught.
WAF in front of the target reduces coverage
Active payloads may be blocked or sanitized by Cloudflare / Akamai / AWS WAF before reaching the application. We surface this with a banner; for accurate results, scan from a whitelisted IP or behind the WAF.
AI-readiness checks test signals, not actual model behavior
We check robots.txt, llms.txt, Schema.org coverage, OG tags, JS rendering — the inputs that AI agents use to decide whether/how to read your site. We don't query ChatGPT/Perplexity directly to verify they actually surface your content.
Source code analysis requires you to provide source
Semgrep / Gitleaks / Trivy run only if you connect a GitHub repo. URL-only scans are limited to runtime behavior — we cannot read your business logic or detect hardcoded secrets in code we never saw.
Mobile = static analysis; no Frida / runtime hooking
APK/IPA scans cover manifest, strings, network config, code disassembly, native binary checks. We do not execute the app on an emulator — runtime-only issues (e.g. a successful SSL pinning bypass via a fallback bug) won't be caught.
Race condition tester defaults to HTTP/2 single-packet
We use the Kettle 2023 technique (HTTP/2 multiplexing with last-byte-sync) for tight (<1 ms) timing windows when the server speaks HTTP/2. Falls back to HTTP/1.1 burst when not — wider window, may miss subtle races.
Authorization & the legal gate
Required reading before scanning anything you don't own.
In Poland (art. 267 KK) and the EU more broadly, sending exploit payloads or automated bruteforce against a system you don't own — without written authorization — is illegal. AuditCore enforces this at the orchestrator level: intrusive scanners (sqlmap, ZAP active, Nuclei active templates, ffuf bruteforce, BOLA testing) only run after the target domain has been verified as owned by the requester.
Verification methods: a DNS TXT record on _auditcore-verify.<domain> OR a file at /.well-known/auditcore-verify-<token>.txt. Either suffices; tokens are unique per (owner, domain) pair.
Scans of unverified domains run only the passive, public-information layer — DNS lookups, header/cookie analysis, SEO crawl, AI-readiness checks. The report explicitly flags how many intrusive scanners were skipped so neither of us is misled about coverage.
Ready to see this in action?
Free 1-page audit, no card. Full report with compliance mapping (PCI / ISO / NIS2 / GDPR / SOC 2).