What a passive website security check can see, and where it has to stop

Agencies and IT providers are often asked, or tempted, to look at the security of a website they do not yet look after. It is a strong way to start a conversation: a concrete exposure is far more persuasive than "have you thought about cyber security?" But there is a line between reading what a site publishes and probing it, and crossing it can turn a sales conversation into a legal one.

This is what a passive check can see, and where it should stop.

This article is general information, not legal advice. Laws differ by country, and if you are unsure whether an activity is lawful where you and the site owner are, ask a lawyer.

Passive versus active

A passive check reads what the site already sends to every visitor: the page, its headers, its certificate, its public DNS records, and the files it links to. It makes ordinary requests a browser would make and does nothing a normal visitor could not do.

An active check tries to make the site do something it was not designed to do for a stranger: guessing passwords, submitting payloads to forms, scanning for open ports across a network, or exploiting a known vulnerability to confirm it.

Unauthorised access to computer systems is a crime in most countries, such as under the Computer Misuse Act in the UK and the Computer Fraud and Abuse Act in the US, and active testing without written permission can fall on the wrong side of that. Passive observation of public information is a very different activity. Keep any assessment nobody asked you for passive and read-only, and save anything active for a signed engagement.

What a passive check can see

A surprising amount.

TLS and certificates. Whether the certificate is valid and trusted, when it expires, whether the full chain is served, and which protocol versions the server accepts. A certificate expiring in nine days is a finding with a date on it.

Security headers. Every response includes headers that tell the browser how to protect visitors. The important ones are Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, a framing policy (X-Frame-Options or CSP frame-ancestors), Referrer-Policy and Permissions-Policy. Missing headers are cheap to add and easy to demonstrate. Our free security headers checker reads them in a single request.

Secrets in the JavaScript. Everything a browser downloads is readable by anyone. API keys, access tokens and service credentials sometimes end up in the bundle, especially on sites built quickly. Matching the bundle against known key formats is passive: you are reading a file the site publishes. The exposed API key checker does this for free.

Known-vulnerable libraries. The JavaScript libraries a page loads often announce their version. Matching those versions against published vulnerability databases is passive, and outdated libraries with known issues are a common and concrete finding.

Exposed files. Configuration files, backups, version-control folders and debug pages left reachable at predictable paths. Requesting a public URL is passive; what you do with the contents is not. If a check finds something that should not be public, record that it is reachable and stop. Do not download, use or share the contents.

Email authentication. SPF, DKIM and DMARC are public DNS records. A missing DMARC record means anyone can send mail that appears to come from the business. We cover this in how to check SPF, DKIM and DMARC.

Reputation. Whether the domain or its hosting IP appears on public abuse or mail blocklists.

Where to stop

Even with passive checks, a few rules keep you on the right side:

• Never log in with anything other than your own credentials, and never test default passwords.

• Never submit data to forms, APIs or search boxes to see how they react.

• Never try to exploit a finding to prove it. "Reachable" is enough.

• Keep the volume normal. A handful of requests, not thousands. A check that burdens someone's server is not passive in any meaningful sense.

• Respect an instruction to stop. If the owner asks you not to assess their site, stop.

• Handle findings responsibly. Share an exposure with the business privately, not publicly, and not with anyone else.

How to present security findings

Security findings can alarm owners, so tone matters. State what was observed, what it could allow, and how to fix it, without drama:

Your site's JavaScript includes a key for your payment provider's API. Anyone visiting the site can read it. Depending on its permissions, it could allow someone to view or create transactions. It should be revoked and replaced today, and the new key kept on the server.

For lower-severity items such as missing headers, be proportionate. Not everything is urgent, and a report that treats everything as critical is easy to dismiss.

Honesty about limits

A passive check cannot tell you a site is secure. It can only tell you what is visible from outside. Say so in the report. It protects you, and it positions a proper, authorised assessment as the natural next step.

How SiteAssay approaches it

Every SiteAssay check is read-only: ordinary GET requests, nothing written, no payloads, no password guessing, and more intrusive checks stay off unless they are explicitly enabled. Our methodology lists each check and the standard behind it, and our security page sets out how we operate and what we do not claim.