METHODOLOGY

How Nandix Scans

Nothing passes without inspection. This page documents exactly what Nandix does — and does not — do when it scans, so security professionals can trust every finding.

SECTION 01

What Nandix is

Nandix is an automated external security assessment. You paste a URL; it inspects what any internet user can already see — response headers, TLS configuration, exposed paths, cookie flags, DNS records — and returns a graded report with fixes. No installation, no agent, no access to your code or servers. Like Nandi at the threshold, nothing passes without inspection.

SECTION 02

Scanning philosophy

Every Nandix check is external, unauthenticated, and passive. We send ordinary HTTP requests from the public internet and analyze the responses — the same traffic your site already answers thousands of times a day. We never exploit a finding, never extract data, never attempt to break authentication, and never send load designed to degrade a service. There is no active attack, no payload execution, no denial-of-service testing. If a check cannot be performed safely and passively, Nandix does not perform it. Scanning is gated behind explicit consent: you confirm you own or are authorized to test the target before any request is sent.

SECTION 03

What Nandix is NOT

Nandix is not a penetration test. A pentest uses a human operator who actively exploits weaknesses, chains findings, and probes business logic — Nandix does none of that. It is not SAST or DAST: it never sees your source code and never fuzzes your application with malicious input. It is not an APM or uptime monitor. Nandix is the fast, automated security check you run before you engage those heavier tools — a first-pass gate that catches the common, externally-visible misconfigurations early, so the expensive human review starts from a cleaner baseline. A clean Nandix report means the checks we run found nothing — not that the target is secure.

SECTION 04

How a scan works

  1. You submit a target URL and affirm you are authorized to scan it (consent is recorded).
  2. The scan is queued and picked up for processing.
  3. Each probe is sent to the target, one at a time, with a per-request timeout.
  4. Every response is analyzed against the scanner's detection rules.
  5. Findings are scored into an A–F grade and returned as a report.

Request identity

Every request identifies itself with the User-Agent Nandix/1.0 (Security Scanner; https://nandixscan.com).

Rate limits (defaults)

Default per-plan scan limits, subject to your plan and to change — not a guarantee: FREE 5/hour · PRO 50/hour · TEAM 200/hour · FULL_FREE 1/hour · FULL_PRO 6/hour.

Why you can trust this

Every request Nandix sends is a standard, read-only HTTP request identified by our scanner user-agent. Requests run in isolated workers, separate from where results are stored. We inspect responses; we do not act on them, replay them, or store credentials found in them. Nothing is scanned without your prior consent.

SECTION 05

The 8 scanners

API security

SSRF Vulnerability Scanner

52 probes

Sends 52 crafted URL payloads through your endpoint's parameter and reports which ones reached internal, cloud-metadata, or file-scheme targets.

What it checks

  • Cloud metadata endpoints (AWS IMDS, GCP metadata.google.internal, Azure IMDS)
  • Internal network hosts — IPv4/IPv6 loopback and RFC 1918 private ranges across common ports
  • Scheme abuse — file://, gopher://, dict:// URLs
  • IP-obfuscation bypasses — decimal, hex, octal, shortened, URL-encoded, and @-embedded hosts
  • Redirect chains that follow through to an internal host
  • DNS-rebinding hostnames (nip.io style) that resolve to loopback

How it detects

Passive, response-only. After stripping the echoed payload from the body, it matches signatures that appear only in a successful SSRF response — /etc/passwd (root:x:0:0), AWS metadata markers (ami-id, instance-id, security-credentials), STS credential JSON (AccessKeyId / SecretAccessKey), GCP computeMetadata output, and leaked process-env dumps. A redirect the server followed to an internal host is treated as vulnerable; a leaked internal-connection error (ECONNREFUSED / EHOSTUNREACH / timeout, or an internal IP echoed back) is downgraded to a warning; a DNS-rebinding vector that times out is treated as safe. Nandix never exploits or extracts data — it only sends requests and reads the response.

Probe breakdown

Cloud Metadata 10 · Internal Network 18 · Bypass Techniques 10 · Scheme Abuse 6 · Redirect Chain 4 · DNS Rebinding 4

CORS Misconfiguration Checker

5 probes

Sends five Origin probes and evaluates whether your Access-Control headers would let a hostile site read authenticated responses.

What it checks

  • Reflection of an arbitrary attacker Origin in Access-Control-Allow-Origin
  • Wildcard origin (*) paired with Access-Control-Allow-Credentials: true
  • Acceptance of the forgeable null origin
  • Suffix/subdomain spoofing that defeats a naive substring allowlist
  • Unrestricted wildcard origin on non-public data

How it detects

Passive, response-only. It sends five Origin headers — three attack origins (arbitrary attacker, null, and a suffix-spoof of your host) plus same-origin and no-Origin controls — then inspects the returned Access-Control-Allow-Origin / Access-Control-Allow-Credentials to see whether an untrusted origin is reflected or credentialed. Only header behaviour is read; no request body is exercised.

Website security

Security Headers Checker

8 probes

Reads your response headers and grades the eight security headers that harden browsers against downgrade, clickjacking, and injection.

What it checks

  • Strict-Transport-Security (HSTS) — presence, max-age ≥ 1 year, includeSubDomains
  • Content-Security-Policy (CSP)
  • X-Frame-Options
  • X-Content-Type-Options
  • Referrer-Policy
  • Permissions-Policy
  • X-XSS-Protection
  • Cache-Control

How it detects

Passive. A single request is issued and each header is evaluated for presence and directive strength (for example, HSTS is only a full pass with a max-age of at least one year and includeSubDomains). Missing or weak directives become findings; no payloads are sent.

Exposed Files Scanner

85 probes

Requests 85 sensitive paths and confirms real exposure by matching file signatures while suppressing generic soft-404 pages.

What it checks

  • Environment & secrets files and application config
  • Version control and CI/build metadata (.git, CI manifests)
  • Database dumps, backups, and dependency manifests
  • Admin/debug endpoints, server-info, and OS/editor artifacts
  • Discovery files (robots.txt, sitemap.xml) — flagged only when they advertise internal/admin paths

How it detects

Passive GET requests. A 200 counts as exposed only when the body matches the file's expected signature AND is not the site's generic response. Genericness is decided by Jaccard token-similarity (≥ 0.9) against status-matched baseline samples, after echoed request paths are stripped — so hosts that 200 (or 401/403) every unknown path do not produce false positives. 404/410, redirects, and unmatched 200s are treated as safe.

Cookie Security Scanner

11 probes

Parses your Set-Cookie headers and checks each cookie's flags against session-security best practice.

What it checks

  • HttpOnly and Secure flags
  • SameSite policy (missing, or None without Secure)
  • Overly broad Domain scope and root Path
  • __Secure-/__Host- prefix violations
  • Excessive or persistent expiry, and technology-fingerprinting cookie names

How it detects

Passive. It parses the Set-Cookie headers returned by the target and evaluates each cookie's attributes — no cookies are forged or replayed. Session cookies missing HttpOnly or Secure are the most severe findings; weaker issues (long expiry, fingerprintable names) are informational.

SSL/TLS Audit

20 probes

Completes a TLS handshake and audits the certificate, protocol versions, cipher strength, and HSTS against 20 checks.

What it checks

  • Certificate validity — expired, self-signed, hostname mismatch, expiring within 30/90 days, weak signature algorithm, incomplete chain, weak key size, lesser-known CA
  • Protocol support — SSLv3 / TLS 1.0 / TLS 1.1 offered, TLS 1.3 unsupported, legacy ciphers
  • HSTS — missing, short max-age, no includeSubDomains, no preload
  • OCSP stapling and Certificate Transparency presence

How it detects

Passive. Nandix opens a TLS connection to gather facts — the presented certificate, the negotiated protocol and cipher, per-version protocol support, the HSTS header, and OCSP/CT signals — then compares them to the probe set. A port with no TLS is reported as a critical finding rather than an error. No traffic beyond the handshake is exchanged.

DNS Security Scanner

21 probes

Resolves your domain's DNS records and audits email authentication, nameserver posture, DNSSEC, and subdomain-takeover exposure across 21 checks.

What it checks

  • Email authentication — SPF (missing, multiple, +all, ~all, too permissive, ptr), DKIM, DMARC (missing, p=none, no rua/ruf)
  • CAA records and nameserver diversity/redundancy
  • DNSSEC, SOA serial format, and high SOA/record TTLs
  • AAAA presence and wildcard DNS
  • Dangling CNAME and subdomain-takeover exposure

How it detects

Passive. Records are gathered using only the Node.js built-in resolver — address, mail, TXT/SPF/DMARC/DKIM, NS, CAA, CNAME, SOA, DNSSEC, and wildcard facts — then evaluated against the probe set. Dangling-CNAME and takeover checks assess whether a target still resolves to a claimable service; nothing is registered or claimed.

Secret Key Leak Scanner

19 probes

Fetches your page's HTML and the JS bundles it links, then regex-scans them for 19 high-confidence credential types accidentally shipped to the browser — every finding masked.

What it checks

  • Cloud provider keys — AWS access key IDs (AKIA/ASIA), Google OAuth client secrets
  • Payment keys — Stripe secret/restricted (sk_live_/rk_live_); publishable (pk_live_) flagged as public-by-design
  • Version control tokens — GitHub (ghp_/gho_/…, github_pat_), GitLab (glpat-)
  • AI provider keys — OpenAI (sk-…/sk-proj-), Anthropic (sk-ant-)
  • Messaging — Slack tokens (xox…) and incoming-webhook URLs
  • Email/SMS — SendGrid (SG.), Twilio API key SIDs (SK…)
  • Package/e-commerce — npm (npm_), Shopify (shpat_/…), Square (sq0atp-/sq0csp-)
  • Private keys (PEM headers), database connection URIs with embedded passwords, and JWTs

How it detects

Passive — fetch, read, regex. It fetches the target HTML, extracts the <script src> bundles the page links (it never guesses secret paths — that's the Exposed Files scanner's job), fetches those bundles under strict size, timeout, and count caps, and matches distinctive-prefix credential patterns. A Shannon-entropy check plus a placeholder wordlist suppress or downgrade docs samples (EXAMPLE/XXXX) so they never surface as CRITICAL. Public-by-design keys (Stripe pk_live_, Google AIza, JWTs) are reported as WARNINGs to verify restriction, not as leaks. Every finding is masked at detection time — the raw credential never enters the report, the shareable URL, or the PDF.

SECTION 06

Scoring & grading

Every scan starts at 100 points. Each finding subtracts a severity-weighted penalty:

  • CRITICAL: −20 points
  • HIGH: −10 points
  • MEDIUM: −5 points
  • WARNING: −2 points

Grade bands

  • A: 90–100
  • B: 70–89
  • C: 50–69
  • D: 30–49
  • F: 0–29

SECTION 07

Accuracy engineering

Automated scanners are only useful if you can trust their findings, so Nandix invests in suppressing false positives. Many modern hosts (Next.js, Vercel, and similar) return HTTP 200 for paths that don't actually exist — a "soft 404" that naive scanners report as an exposed file. Nandix fingerprints each target's not-found behavior and uses Jaccard similarity to compare suspected findings against that baseline, discarding responses that merely echo the site's generic not-found page. Files that are meant to be public — robots.txt, sitemap.xml — are scored on their own terms rather than penalized as leaks. The goal is simple: if Nandix flags something, it should be real.

SECTION 08

Limitations & responsible use

Nandix inspects what is externally visible; it cannot see everything a full audit would. It does not test authenticated flows, business logic, or internal services, and it does not exploit findings to confirm impact — so results are strong indicators, not proof, and absence of a finding is not a guarantee of safety. Findings should be validated in your own environment before action. Nandix is intended only for targets you own or are explicitly authorized to test. Scanning systems without authorization may be unlawful; you are responsible for how you use it.

SECTION 09

Standards & references

Nandix's checks are grounded in established, publicly documented security standards. Header, CORS, and SSRF checks follow OWASP guidance and the relevant IETF RFCs; TLS and certificate evaluation follows widely-used industry conventions for grading protocol versions, cipher strength, and certificate validity. Nandix aims to align with the same well-understood best practices that security teams already rely on, so its findings are explainable and independently verifiable rather than opaque.

Only scan targets you own or are explicitly authorized to test. See our Acceptable Use policy.