What an attacker sees before they touch your site

Passive scanner, DAST, or pentest: which one do you actually need?

You searched for a way to check your site's security and got hit with three categories that all sound the same: a free scanner, a "DAST," and a penetration test that costs more than your monthly revenue. They are not the same thing, and picking the wrong one means either paying for depth you don't need yet or trusting a check that was never going to find your real problem.

Here's the honest version, from someone who runs the passive kind. The three differ on one axis: how hard they push on your site. That single difference decides what they find, what they can break, and what they cost.

What each one actually does

A passive external scan looks at your site the way a stranger on the open internet does. It requests your pages, reads the headers and the JavaScript you already serve, checks your public DNS, and looks at what your server volunteers. It never sends an attack. It never logs in. It can't, by design, and that's the whole point: it sees exactly what an unauthenticated outsider sees, nothing more.

A DAST (dynamic application security testing) tool is active. It crawls your app and then fires real, if non-destructive, payloads at it: injection strings, malformed inputs, the moves a real attacker would try. Good ones log in first so they can test the parts of your app that live behind authentication. Detectify, Probely, and Intruder sit here. A DAST finds things a passive scan categorically cannot, because it pokes the application instead of just reading it.

A penetration test is a human. A skilled tester uses tools, including the two above, plus judgment, creativity, and an understanding of your business logic that no scanner has. They chain small issues into a real breach, find the flaw that only matters because of how your specific app grants access, and write it up. It's the deepest option and the most expensive, usually by an order of magnitude.

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
The line a passive scan does not cross. Everything on the right needs an active tool or a human.

What each one finds, and what it can't

The capability gap is real, so let's be precise about it rather than hand-wave.

A passive external scan reliably finds exposure and misconfiguration: a secret key sitting in your JavaScript bundle, a reachable /.env or /.git, a missing Strict-Transport-Security header, a session cookie without HttpOnly, an SPF record that lets anyone spoof your domain, an expired TLS certificate, a dangling subdomain. These are things you can see from outside because the server is already showing them to everyone. It will not find SQL injection, broken access control, or a logic flaw in your checkout, because finding those means sending something hostile, and a passive scan never does.

A DAST adds the active layer. It can surface injection-class bugs and, with authenticated scanning, problems on logged-in pages. What it's weaker at is your specific business logic: it doesn't know that order_id 1002 belongs to a different customer, so it usually won't catch that you can read it.

A pentest is where business logic and creative chaining get caught, because a person is reasoning about your app, not pattern-matching it. The trade-off is cost and cadence: a pentest is a point-in-time snapshot you buy occasionally, not something you run on every deploy.

So which one do you need

It depends on where you are, and the honest answer is usually "more than one, in sequence."

If you're shipping an MVP and have never checked anything, start passive. The exposure problems a passive scan finds are the ones attackers exploit first, at scale, with bots, and they're the cheapest to fix. There's no reason to pay for a pentest to tell you your .env is public when a free external scan finds it in seconds. Close the outside-visible holes before you pay anyone to look deeper.

If you're handling real user data or money and your app has meaningful authenticated functionality, you want active testing. A DAST in your pipeline catches injection-class regressions, and a pentest before a big launch or compliance milestone catches the logic flaws a tool never will. The passive scan still earns its place underneath both, as the continuous check that nothing got exposed between the expensive assessments.

That last part is where a passive scanner does its real work. It's the cheap, constant layer that watches the surface every day, so the expensive human time gets spent on the hard problems instead of re-discovering a leaked key.

SurfaceCheckr is that layer. The exposed secret, the broken header, the dangling subdomain are all things a stranger can already see, so we read them the same way, grade A through F, and re-run on a schedule so a new leak shows up the same day it ships. We won't pretend to be more than that. When the thing you're worried about lives behind a login or hides in your checkout logic, you need a real pentest instead, and we'll say so. But if the question is "what am I leaking to the open internet right now," this is the right tool, and you can run it before you finish reading this.

Find it before someone else does.

Paste your domain. The grade and issue count are free, and you'll see in a couple of minutes exactly what's reachable from outside.