@patrickivanuellf2VoidSpider: an open-source passive security scanner with a live “spider” graph dashboard
Hi everyone, I’m Patrick, a CS student in Indonesia who also runs a few small game websites and VPS servers. I built VoidSpider, a passive security audit scanner for websites and local files you own.
How it works: a Node.js server scans one target continuously and streams results over SSE to a fullscreen dashboard. Each page or file becomes a node cluster, and a geometric spider reaches out to whatever is being scanned right now. Findings get a severity level, a fix suggestion, and an A–F score.
What it checks
Websites: security headers (CSP, HSTS, cookies), exposed files like /.env and /.git/config, leaked keys in HTML/JS, TLS configuration, SPF/DMARC/DNSSEC, and subdomain takeover risk.
Local files: hardcoded secrets, risky code patterns, webshell and obfuscation rules (YARA-style, extendable via JSON), dependency CVEs via OSV.dev, secrets in git history, Dockerfile/Kubernetes/Terraform misconfigs, and invisible-Unicode prompt injection.
Extras: drift detection against a baseline, Telegram alerts, SSH/honeypot log ingestion, SARIF output for CI, and an optional triage agent using Claude that only sees redacted snippets.
A deliberate design choice: it never sends attack payloads, never tries to log in, and never port-scans. Everything is passive GET requests, and it needs an --saya-pemilik-situs (“I own this site”) flag for remote targets. A scanner that can attack works just as well against anyone else’s site. For active testing I added an optional OWASP ZAP integration that you run yourself, with a double confirmation flag.
Honest limitations: it’s pattern-based, so expect false positives and misses. SPAs are only read as far as their initial HTML, and it’s not a replacement for a full SAST or pentest.
Where I’d love feedback:
What passive checks am I missing that you’d want in a first-pass audit? For the entropy-based generic secret detection, how would you reduce false positives further? Is the “passive only” boundary the right call, or too limiting?
Repo (MIT): github.com/patrickivanuellf/VoidSpider
Comments3
Passive only is the right call, because a small site owner will only point a scanner at their site if they trust it can't break anything. Building iContact taught me that SPF and DMARC problems quietly push a business's emails into spam without the owner ever knowing why, so I'd make that check the headline of your first-pass audit, not just one item on the list.
Exactly. For the first pass, I'll prioritize running quick DNS TXT record checks for SPF, DKIM, and DMARC enforcement policy. Is there any specific edge case you think I should flag right away?
Passive only is right. We run a similar monitor (Shield) for small sites, and the passive checks that caught the most real problems for us were: backup files left in the web root (.zip, .sql, .bak, wp-config.php~), public JS source maps, directory listing, and a CMS version leaked via the generator meta tag or readme files. One more worth adding for anyone running sites for search traffic: fetch the same page with a Googlebot user agent and a normal one and diff them, hacked sites often show injected spam links only to crawlers. For entropy false positives, require a key-like context (a variable name such as key, token, secret near the string), match known prefixes (AKIA, sk_live_, ghp_) first, and skip UUIDs, hashes and base64 image data. Publishable keys like Stripe pk_ or a Maps key are worth a separate low severity bucket instead of a hit.
3 comments
Passive only is the right call, because a small site owner will only point a scanner at their site if they trust it can't break anything. Building iContact taught me that SPF and DMARC problems quietly push a business's emails into spam without the owner ever knowing why, so I'd make that check the headline of your first-pass audit, not just one item on the list.
Exactly. For the first pass, I'll prioritize running quick DNS TXT record checks for SPF, DKIM, and DMARC enforcement policy. Is there any specific edge case you think I should flag right away?
Passive only is right. We run a similar monitor (Shield) for small sites, and the passive checks that caught the most real problems for us were: backup files left in the web root (.zip, .sql, .bak, wp-config.php~), public JS source maps, directory listing, and a CMS version leaked via the generator meta tag or readme files. One more worth adding for anyone running sites for search traffic: fetch the same page with a Googlebot user agent and a normal one and diff them, hacked sites often show injected spam links only to crawlers. For entropy false positives, require a key-like context (a variable name such as key, token, secret near the string), match known prefixes (AKIA, sk_live_, ghp_) first, and skip UUIDs, hashes and base64 image data. Publishable keys like Stripe pk_ or a Maps key are worth a separate low severity bucket instead of a hit.