A founder ran his own production site through Flux8Shield the week we launched it, half expecting a clean pass. It came back with three missing headers, a cookie without Secure or SameSite set, and an exposed .git/config file sitting at the root of the domain — readable by anyone who knew to ask for it. Nobody had touched that server in months. Nothing was "hacked." The information had just always been there, waiting for someone to look.

That's the case for passive scanning in one story. We built Flux8Shield to answer a narrow question — is this website leaking things it shouldn't, without us ever having to poke at it — and pointed it at enough sites that a pattern emerged. Not a dramatic one. A boring, structural one. Here's how it's built and what 65,000+ scans have actually shown us.

What "Passive" Actually Means — and Why It's the Whole Product

Most website "security scanners" people picture actively probe a target: they fuzz inputs, try known exploit payloads, attempt SQL injection strings in query parameters. That's real vulnerability scanning, and it needs permission — running it against a site you don't own without authorization is illegal in most jurisdictions, full stop.

Flux8Shield never does any of that. It sends the same request a normal browser tab sends, then reads what comes back: response headers, the TLS certificate chain, cookie attributes, CORS configuration, and a small set of well-known paths (/.env, /.git/config, /wp-config.php.bak) that should return a 404 and, on a surprising number of servers, don't. No login attempts, no payloads, no write requests. If a passive scan can find it, so can anyone with curl and five minutes — that's precisely why it matters.

This constraint shaped every other decision in the product. We didn't set out to build "a lightweight scanner." We set out to build one that's legal to run against any public URL with zero authorization step, because that's the only version of this tool regular site owners will actually use.

The 40+ Factors We Check

The checks fall into five groups. None of them require anything beyond a normal HTTP request cycle:

• Security headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — presence, and whether the value is actually restrictive or just present for show.
• TLS/SSL: certificate validity window, protocol version (flagging TLS 1.0/1.1 still in the wild), and whether HTTP silently redirects to HTTPS or serves content over both.
• Exposed files: .env, .git/config, .git/HEAD, common backup file suffixes (.bak, ~), and directory listing left switched on by default.
• CORS configuration: whether Access-Control-Allow-Origin: * is paired with credentialed requests — the specific combination that turns an open CORS policy into a data-exfiltration path.
• Cookie flags: Secure, HttpOnly, and SameSite on every cookie the server sets, checked individually rather than as one pass/fail bucket.

How We Built It — and the One Thing We Got Wrong

The scan itself runs server-side — a Node process fetches the target URL and its known sub-paths, parses headers and certificate data, and scores the result. Nothing about the target site's response ever gets stored beyond the session that requested it.

The part we underestimated was abuse. Within the first week of launch, a handful of IPs were firing the scanner at the same third-party domains dozens of times a minute — not our users checking their own sites, but someone using Flux8Shield as a free reconnaissance proxy against targets that weren't theirs. A passive scanner is still a tool that can be pointed at someone else's infrastructure at scale, and "we don't exploit anything" doesn't mean "we can't be misused as a fingerprinting tool for a later attack."

The fix was a hard rate limit: 3 free scans per day per IP, no signup, no way to raise it by creating throwaway accounts. It's a blunt instrument, and it does mean a legitimate user auditing five client sites in one sitting hits the wall. We chose that trade-off on purpose — the alternative was building account gating and CAPTCHA flows before we'd validated anyone wanted the tool at all. Rate limiting first, everything else only if the abuse pattern demanded it.

What Scanning Actually Taught Us

Across 65,000+ scans, the failures are almost never exotic. The single most common finding is a missing or empty Content-Security-Policy header — not because CSP is hard to write, but because most stacks don't set one by default and nobody adds it after launch. Close behind: cookies set without SameSite, which was a non-issue before browsers started defaulting to Lax and silently changing behavior instead of throwing an error anyone would notice.

The exposed-file category is the one that actually alarms people. It's rare, but it isn't rare enough — a live .env file at the domain root means database credentials, API keys, and session secrets sitting in plaintext behind nothing but the assumption that nobody would think to ask for that path. Every time Flux8Shield flags one, the underlying cause is the same: a deploy script that copies the whole project directory instead of a build output folder.

None of this requires a sophisticated attacker. It requires someone who read the same public checklist we built the scanner from. That's the actual argument for running a passive scan before anything more expensive: the low-hanging findings are the ones actually getting picked, because they cost an attacker nothing to check.

Three things worth doing today if you haven't: add a Content-Security-Policy header even a permissive one is better than none, set SameSite=Lax on every cookie your app controls, and confirm your deploy pipeline never copies .env or .git into the served directory. All three take under an hour combined. If you want the full picture for your own site, run it at security.flux8labs.com — no signup, results in under 10 seconds. For teams that need continuous monitoring rather than a one-off check, that's closer to what ekmire is built for, and if you're weighing that trade-off we're happy to talk it through — reach out.

---

Frequently Asked Questions

• Q: Is it legal to scan a website I don't own with Flux8Shield? Yes — Flux8Shield only sends normal, read-only HTTP requests that any browser would send, the same as visiting the page. It never attempts exploits, logins, or write operations, so it doesn't cross into the territory that requires authorization.

• Q: How is passive scanning different from a penetration test? A penetration test actively tries to exploit vulnerabilities with the target's permission — sending crafted payloads, attempting authentication bypasses, and simulating real attacks. Passive scanning only reads publicly exposed information: headers, certificates, cookie flags, and known file paths. It won't catch everything a pentest would, but it needs no authorization step and no risk of disrupting the target.

• Q: Why is Flux8Shield limited to 3 free scans per day? The limit exists because of abuse, not monetization — early usage showed the scanner being fired repeatedly at third-party domains as a free reconnaissance tool. The per-IP daily cap keeps it usable for anyone checking their own sites while making it impractical to run at the volume an automated recon script would need.