Early Access — All features free while spots last. Join Now
All articles
security scanner free tools TLS DNS HTTP headers DMARC SPF CAA SentriKat

Launching our free public security scanner — what it checks and why we built it

A free, non-intrusive security posture scan for any public domain. Five categories, a 0–100 score, a PDF report — and zero data retention. Here's what's under the hood.

Denis Sota · · 8 min read

We just shipped a free, no-signup security scanner for any public domain you own or are authorised to test. You give it a hostname, it gives you a 0–100 posture score, a category breakdown, and a downloadable PDF report. Try it at sentrikat.com/scan.

This post explains what the scanner checks, why we picked those five categories, and the design decisions behind it — including some opinionated ones (no result retention, PDF-by-email, one-shot links). If you’d rather just run a scan, head over there now; the rest is for the curious.

Why a free scanner

The SentriKat product is a continuous, agent-based vulnerability manager for SMBs and mid-market — version-verified CVE matching against installed software, KEV prioritisation, NIS2 / ISO 27001 evidence, SBOM exports, on-prem or managed cloud. None of that is what you need at 11pm when someone asks “is our public site configured correctly?”. You want a one-shot answer.

The free scanner exists for exactly that question. It’s also the most honest sales tool we have: if your public posture is solid, you don’t need us yet. If it’s not, the report tells you exactly what to fix — and whether it’s the kind of thing that benefits from continuous monitoring or whether a one-off cleanup is enough.

The five categories

The scanner runs five independent probes in parallel and a sixth banner-enrichment pass on top. Total runtime is about 30 seconds for a typical domain.

1. HTTP security headers

We fetch your root URL and inspect the response headers for the standard hardening set:

  • Strict-Transport-Security (HSTS) — present, sufficient max-age, includes-subdomains, preload-ready
  • Content-Security-Policy — present, no 'unsafe-eval' / 'unsafe-inline' unless intentional, no wildcards
  • X-Frame-Options (or frame-ancestors in CSP) — clickjacking protection
  • Referrer-Policy — set to something other than the lax browser default
  • Permissions-Policy — explicitly denies the features your site doesn’t use
  • X-Content-Type-Options: nosniff — MIME type confusion mitigation

We also flag version-disclosure headers (Server: Apache/2.4.41, X-Powered-By: PHP/7.4.3). Those are turned into CVE lookups against the NVD + CISA KEV mirror — the banner-enrichment pass mentioned above. A version-leaking header isn’t dangerous on its own, but combined with a public CVE feed it tells an attacker exactly which exploit to try first.

2. TLS configuration

Powered by sslyze, the same library Mozilla Observatory uses. We check:

  • Certificate validity, expiry window, issuer trust chain
  • Supported TLS protocol versions (TLS 1.0 / 1.1 deprecated, 1.2 and 1.3 expected)
  • Cipher suite quality (forward secrecy, AEAD modes, no RC4, no DES, no anonymous DH)
  • Common misconfigurations (Heartbleed if you’re somehow still running OpenSSL 1.0.1, ROBOT, Sweet32 with 3DES, …)

The score for this category is the most opinionated. A certificate that’s valid but expires in 10 days knocks 10 points off. A 90-day-or-better autorenew via ACME bumps it back up. Reasonable defaults: not perfect, no false positives that we know of.

3. DNS records

The boring ones that matter:

  • SPF — present, syntactically valid, no +all, lookup count under 10
  • DMARC — present, p= quarantine or reject, alignment configured, RUA / RUF endpoints
  • DKIM — selectors discoverable, key size ≥ 2048 bits
  • CAA — present at the apex; restricts which CAs can issue certificates for your domain

Missing CAA is the single most common finding in real-world scans. It’s a one-line DNS change that meaningfully shrinks the attack surface for certificate issuance abuse, and nobody does it because nobody learned about it. Putting it in our report (and in this blog post) is part of the fix.

4. TCP open ports

Standard ports only — 21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 465 (SMTPS), 587 (Submission), 993 (IMAPS), 995 (POP3S), 3306 (MySQL), 3389 (RDP), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB) — via TCP connect(), no SYN scanning, no banner grabbing.

Why so conservative? Because a free public scanner has to err on the side of “polite to the target’s IDS”. A SYN scan on 65k ports is what shows up in your firewall logs and gets us blocked. A targeted TCP connect on 17 well-known ports is what your monitoring tool does every day and nobody notices.

If the scan finds 3306 or 6379 or 27017 open to the public internet, that’s a finding with severity: critical and a remediation that reads “close it now, before anyone else notices”. We’ve seen Redis and MongoDB hits in real scans more often than we’d like.

5. Discovery

A small set of well-known public paths:

  • robots.txt — present and parseable
  • /.well-known/security.txt — present, valid, includes a Contact and Expires field
  • /sitemap.xml — discoverable
  • Common misconfiguration markers (/.git/HEAD, /.env, /wp-admin/install.php — we look but don’t fetch the content; finding a 200 on those is the entire signal)

The presence of security.txt is one of the most positively correlated signals with a mature security programme that we’ve measured. If you don’t have one, securitytxt.org has a generator — we’d put that ahead of half the CSP tuning the average site needs.

Design decisions you can second-guess

One-shot PDF, with the email mailbox as canonical storage

If you provide an email address when you submit the scan, the PDF is attached to a transactional email and the on-disk copy on our VM is deleted as soon as the message is handed to our SMTP provider. Your inbox is the only place the report lives from then on — no expiring download link, no copy retained on our server, no way for us to leak the report later because we don’t have it.

If you don’t provide an email, you get a one-shot browser download instead. Same outcome: download it, the link returns 404 on the next click.

Why this is the right default: a report that says “port 3306 is open on prod” is exactly the kind of artefact you want to hand to your operations team once and never see hosted on a third party again. Building a “view your past scans” feature would mean retaining that artefact. We chose not to.

Free, but rate-limited two ways

Three scans per hour per IP, one PDF report per email per hour. The IP limit stops a single client from running 10000 scans in a loop; the email limit stops a botnet with many IPs from amplifying unsolicited mail to a victim’s inbox. Both return a clear 429 with a human-readable message; both reset on a one-hour rolling window.

Domains we refuse to scan

Suffix list, hard refusal: .gov, .mil, .gov.uk, .gouv.fr, .bund.de, .admin.ch, .gv.at, .belgium.be, .gob.es, plus .bank, .banque, .insurance. The marginal value of a free posture check on those does not offset the reputational cost of having our IPs end up on a sensitive-target blocklist. If your organisation is in one of those verticals and wants a real assessment, drop us a line — we’ll do it under contract instead.

Newsletter is separate from the report

The form asks twice: once for an email (delivers the PDF — transactional, no List-Unsubscribe) and separately for a newsletter opt-in (double opt-in, GDPR-style — you’ll get a confirmation link before you’re actually added to anything). Ticking the newsletter box without entering an email is rejected explicitly; entering an email without ticking the newsletter box doesn’t enrol you in anything. The audit pass that surfaced this design called it the single biggest UX win compared to “give us your email and we’ll figure out what to do with it” patterns.

What the scanner is not

It’s not a penetration test. It’s not a fuzzer. It doesn’t follow links, it doesn’t attempt to log in, it doesn’t probe for SQL injection, it doesn’t run JavaScript on your site. Everything it does, your browser or Googlebot does. The whole point of “public-data-only” is that running the scan should be indistinguishable from a normal visitor — and if it’s not, that’s a bug in our scanner, not a feature.

If you need an actual penetration test, hire a CREST-accredited team. We won’t sell you one and we won’t pretend the free scanner replaces one.

Try it

sentrikat.com/scan — give it a domain, get a score in 30 seconds, get a PDF in your inbox. Tell us what’s confusing and what’s wrong; the feedback from the first two days of testing already produced six pull requests and one new design decision.

If you want to follow what we ship next, the security advisories newsletter is double-opt-in and we send roughly two emails a month — KEV alerts that matter to SMBs, a quarterly “what we changed and why” digest, the occasional deep-dive like this one.

— Denis

Ready to automate your vulnerability management?

Deploy SentriKat on-premises in minutes. Track CISA KEV vulnerabilities, generate NIS2 compliance reports, and protect your infrastructure.

Request a Demo
Discuss this article: Community Forum