What a security scan can and can't tell you (we're honest about it)

Most security tools sell you certainty they can't deliver. "Fully secure." "Complete coverage." "Enterprise-grade protection." You've read enough of these to know the words mean nothing.

So here's the straight version. SurfaceCheckr is a passive external scanner. We look at your site the way a stranger on the internet does, with no login and no access to your code or your servers, and we report what's visible from there. That's a real and useful slice of your risk. It's a slice, though, and a tool that won't tell you where its own line is can't be trusted on the things it does find. Here's the line.

What "from outside" actually means

Stand where an anonymous attacker stands. You have a URL. You have no password, no API token, no shell on the box. Everything you can learn, you learn by sending requests and reading responses.

That's our exact position. We don't install an agent. We don't get database access. We don't get a login. We send the same kinds of requests a crawler or an attacker sends, and we read what comes back. The upside of that constraint is honesty: anything we find, an attacker can also find, by definition, because we found it the same way they would, from the same place, with the same lack of access.

we check thisvisible from outside

+Exposed /.env, /.git/config, /backup.sql
+Secrets in your JS bundle and source maps
+Open admin panels: Adminer, Grafana, Kibana
+Missing HSTS, CSP, HttpOnly cookies
+SPF, DMARC, dangling CNAME takeover
+Expired or expiring TLS certificates

we don'tneeds a real pentest

-Whether a logged-in user can read another user's data
-SQL injection in a form behind a password
-Broken access control on /account/123
-Race conditions in your checkout flow
-Logic bugs in how you grant entitlements
-Anything that needs valid credentials to reach

What we can tell you

Plenty lives on the outside of your perimeter, and most of what gets fresh products hit is right there. Concretely, a passive external scan reports:

• Exposed files. We request /.env, /.git/config, /backup.sql, /.aws/credentials, /wp-config.php.bak and the rest, and tell you which return a 200 instead of a 404.
• Secrets in your frontend. We read the JavaScript you actually shipped and search it for sk_live_, AKIA…, ghp_, a Supabase service_role JWT, and private key blocks. Source maps in prod, too.
• Reachable admin surfaces. Adminer, phpMyAdmin, Grafana, Kibana, Jenkins, a Symfony profiler or Django debug toolbar sitting on a path or subdomain.
• Debug pages. A Werkzeug console, a Whoops page, Rails dev errors, DEBUG=True leaking a stack trace.
• Transport and headers. No HTTPS redirect, mixed content, an expiring TLS cert, TLS 1.0, missing HSTS, no CSP, a session cookie without HttpOnly or Secure.
• Email and DNS. Missing SPF, a p=none DMARC policy, no CAA record, a dangling CNAME that's a subdomain takeover waiting to happen.

Every one of those is a fact about your public surface, checkable without your cooperation, which is exactly why it's worth checking. This is the same outside-in look as the 10-minute pre-launch pass, run for you and repeated on a schedule.

What we can't tell you, and won't pretend to

Here's the part the marketing pages skip. A passive external scan does not test anything that requires being a logged-in user, and it does not reason about whether your application logic is correct. So we cannot tell you:

• Whether one user can read another's data. Broken access control on /account/123 versus /account/124 is found by logging in as one user and requesting the other's resource. We don't log in, so we don't see it.
• Whether your forms are injectable. SQL injection, command injection, and the like usually live behind authentication and require crafted input against real endpoints. That's active testing, not passive observation.
• Whether your business logic holds. Can someone get the paid tier without paying? Skip a step in checkout? Apply a coupon twice? Those are logic bugs, specific to how you built it, and no external scanner infers them.
• Race conditions, and anything stateful. Two requests at the same time doing something one request can't. That needs deliberate, active testing.

For all of that, the right tool is a human pentest: someone with credentials, time, and permission to actively probe your authenticated surface. We're not that, and we'll never tell you a green result means you don't need one. A clean external scan tells you your perimeter is clean. What happens once someone is logged in is a separate question, and only a pentest answers it.

Why a narrow, honest scan still beats a broad, dishonest one

You might read all that and think the scope sounds small. It isn't, for one specific reason: the cheap, catastrophic mistakes almost all live on the outside. A 200 on /.env, a sk_live_ in the bundle, an open Adminer with default credentials. These need no skill to exploit and they're the ones that get fresh products owned. A pentest finds the subtle stuff. An external scan finds the stuff that's subtle to nobody, and it finds it in minutes, repeatedly, for free of a consultant's calendar.

The other reason is trust. A tool that claims to find everything will quietly miss the access-control bug and let you believe you're covered. We'd rather tell you exactly the shape of what we check so the gap is visible and you can fill it deliberately, with a pentest, before it matters.

The 200 on /.env and the sk_live_ in your bundle are visible to anyone with a browser, which is exactly why we can read them too, in minutes, without a credential or an agent on your box. That's the whole job: the outside-in view, reported honestly, with the line drawn where it actually falls. Book the pentest for the rooms behind the login. Run us for the front door, and run us again next month. If you want the concrete list of perimeter holes to fix first, start with what a fresh MVP leaves exposed.