The Complete Guide to Security Scanning: Browsers, Websites, Files and Privacy

Security scanning is the practice of checking a browser, a website, a file or an online account against a list of known weaknesses before an attacker checks it for you. Scans come in four kinds: browser, website, file and privacy. Each finds a different class of problem, none finds everything, and the value is in reading the results correctly and fixing the right thing first.

What security scanning is, and what it is not

Every scanner works the same way underneath. It has a catalogue of things that are known to be wrong: a missing header, a retired protocol version, a file structure that only malware uses, a domain that imitates a bank. It examines the target, compares what it finds against the catalogue and reports the matches with a severity.

The strength is coverage. A scanner checks hundreds of things in seconds, consistently, without getting tired or skipping the boring ones. Most real-world compromises begin with something mundane and well understood: a server that still accepts TLS 1.0, a .env file left in the web root, a login page framed inside an attacker's site, a document with a macro. A scanner finds those reliably.

The limit is novelty. A scanner cannot find a flaw nobody has described yet, and it cannot reason about what your application is supposed to do. It will not notice that user 1001 can read user 1002's invoices by changing a number in the URL, because from the outside that looks like a page loading normally. Those problems need a person: a code review or a penetration test, which is a different activity with a different price tag. A scan is the thing you run first, often and cheaply, so that the expensive human time is spent on the problems only humans can find.

The four kinds of scan

People say "scan" for four activities that have almost nothing in common technically. They examine different targets, use different methods and produce findings that need different fixes. Scan.now organises its tools and guides around these four, and the rest of this guide follows the same shape.

Browser scanning: the program you trust with everything

Your browser is the one program that runs code from strangers all day. Every page you open executes JavaScript written by someone you have never met, and the browser's job is to keep that code inside a box. A browser scan asks whether the box is intact. It checks that the version is current, because browser vendors ship security fixes every few weeks and the gap between a fix and your update is when you are exposed. It measures how identifiable you are through fingerprinting, tests whether WebRTC reveals the IP address a VPN is supposed to hide, and probes whether the browser actually enforces the policies a site sends it, such as Content-Security-Policy and X-Frame-Options.

The Browser Security & Privacy Check runs entirely inside your browser: nothing about your session is uploaded, because the tests only make sense from the inside. Two narrower tools sit beside it. The WebRTC & IP Leak Test compares the address your connection presents with the addresses WebRTC can enumerate from inside a page, which is the single most common way a VPN fails silently. The Browser Extension Analyzer takes an extension package and reads its manifest and code for the permissions and behaviours that matter: host access to every site, remote code loading and calls to external endpoints. The browser security hub covers the security model, the leaks and the settings in depth.

Website scanning: what a stranger can see from outside

A website scan looks at a site the way an attacker doing reconnaissance does: without an account, from the public internet, reading what the server volunteers. That turns out to be a great deal. The TLS handshake reveals which protocol versions and cipher suites the server accepts and whether the certificate chain is valid. The HTTP response reveals every security header the server sends and every one it forgot. Set-Cookie lines show whether session cookies carry Secure, HttpOnly and SameSite. The HTML reveals which JavaScript libraries the page loads and in what versions, whether any are fetched over plain HTTP, and whether the CMS announces itself. A handful of well-known paths show whether the deployment left .git, .env or a backup archive reachable. DNS reveals whether the domain has SPF and DMARC, which decide whether anyone can send email as you.

The Website Vulnerability Scanner runs all of this in one pass and grades the result from A to F, and four focused tools each go deeper on one area: the SSL / TLS Checker for certificates and protocol support, the Security Headers Checker for the header set, the Email Security Checker for SPF, DKIM, DMARC, DNSSEC and CAA, and the JavaScript Library Vulnerability Scanner, which matches detected library versions against the Retire.js database and lists the CVEs. The website security hub explains each area, how it is tested and what a fix looks like.

File scanning: judging a document before it runs

A file scan answers a narrower question: is this particular file dangerous to open? A modern file scanner layers three methods. Signature matching compares the file, or characteristic byte sequences in it, against a database of known malware and is nearly free of false positives but blind to anything new. Structural analysis parses the file as its format and looks for constructs that legitimate files rarely need: a VBA project inside an invoice, JavaScript inside a PDF, an executable hidden behind a .pdf.exe double extension, an archive nested twelve levels deep. Behavioural heuristics look at scripts and executables for what they would do: download and execute, decode a hidden payload, disable protection.

The File Malware Scanner accepts a file up to 64 MB, analyses it in memory and does not store it. The malware and file scanning hub explains each layer, the file types that carry most malware and a repeatable way to judge a file you are unsure about.

Privacy scanning: the link and the password

The fourth kind is the least like the others because the target is not a system but a decision you are about to make: click this link, keep using this password. A phishing URL check reads a link the way a careful person would if they had time: it finds the registrable domain, checks whether it is a lookalike of a known brand, decodes punycode, follows the redirect chain to the real destination and notes whether the landing page asks for credentials. A password check answers two questions without ever receiving the password: is it in a known breach corpus, and how quickly would it fall to a modern cracking rig? The breach lookup uses the k-anonymity model, in which only the first five characters of the password's SHA-1 hash leave your browser.

The Phishing URL Checker and the Password Strength & Breach Checker cover those two decisions. The online privacy hub puts them in context with tracking, IP exposure, second factors and what to do after a breach.

Passive scanning, and why Scan.now never attacks

Every scan on this site is passive. That word has a precise meaning: the scanner sends only the requests a normal visitor, browser or DNS resolver would send, and reads what comes back. It does not submit crafted input to see whether a form is injectable, does not guess passwords, does not fuzz parameters and does not try to exploit anything it finds. It reads the Server header; it does not attempt to crash the server.

The boundary matters for three reasons. Legally, sending attack traffic to a system you do not own is an offence in most jurisdictions, whatever your intent. Ethically, an active scan can degrade or break a production service, and a passive one cannot. Practically, most of what an external attacker learns in the first hour comes from passive observation anyway. The passive versus active scanning guide draws the line in detail and explains what an active scanner such as ZAP adds when you do own the target and have permission.

How findings are scored

A scan report is a list of findings, each with a severity. Understanding where the severities come from prevents two common mistakes: panicking over an informational item because it is red-adjacent, and ignoring a medium because it is not red.

Scan.now uses the five CVSS qualitative bands: critical, high, medium, low and informational. Each check in the check registry carries a default severity chosen for the typical case, and the engine may raise or lower it based on what it sees. An exposed .git directory is critical because it usually hands an attacker the entire source tree and often credentials. A missing Referrer-Policy is low because the harm is leaking URL paths to third parties, which is real but rarely decisive on its own. Informational findings such as the third-party script inventory are not problems at all; they are context you need to interpret the problems.

For vulnerabilities in named software, the severity comes from the published CVSS score of the CVE. CVSS v3.1 and v4.0 measure how bad exploitation would be under standard assumptions: attack vector, complexity, privileges required, user interaction and impact on confidentiality, integrity and availability. What CVSS does not measure is whether anyone is exploiting the bug in the wild or whether your deployment is reachable in the way the score assumes. The CVE and CVSS guide explains the numbering and scoring and how to weigh a score against your own exposure.

The A-to-F grade on a website scan is a compression of the whole report into one letter. It exists so you can compare a site with itself over time and so that a non-specialist gets an honest first impression. Treat it as a headline, not a verdict; two sites can share a grade for entirely different reasons.

Reading a report and choosing what to fix first

Here is an abbreviated report of the kind the website scanner produces, with the noise removed so the shape is clear:

Grade: D

CRITICAL  exposed-env-file            /.env returns 200 with DB_PASSWORD=
HIGH      tls-deprecated-versions     server accepts TLS 1.0 and TLS 1.1
HIGH      outdated-javascript-library jquery 1.12.4 (CVE-2020-11022, CVE-2020-11023)
MEDIUM    hsts                        Strict-Transport-Security header missing
MEDIUM    cookie-httponly-flag        PHPSESSID set without HttpOnly
MEDIUM    content-security-policy     no Content-Security-Policy header
MEDIUM    dmarc-record                no _dmarc TXT record
LOW       server-header-disclosure    Server: Apache/2.4.29 (Ubuntu)
INFO      security-txt                /.well-known/security.txt not found

The temptation is to work top to bottom. That is roughly right but not exactly, because severity measures impact, not effort or urgency. A better order weighs three things: what an attacker could do with the finding today, how much work the fix is, and whether one fix removes several findings at once.

1. Stop the bleeding. Anything that leaks secrets or lets traffic be intercepted comes first, regardless of effort. In the example, the exposed .env file means the database password is public: remove the file, rotate the credential, and check the logs for who fetched it. That is an incident, not a to-do item.
2. Fix transport. Disable TLS 1.0 and 1.1, which have been formally deprecated since RFC 8996 in 2021, and add HSTS. These are configuration changes in one place that resolve two findings and harden every page at once.
3. Fix the session. Add HttpOnly, Secure and SameSite to the session cookie. A stolen session cookie is an account takeover with no password needed, and the fix is one line.
4. Remove known-vulnerable code. Upgrade jQuery. The two CVEs in the example are cross-site scripting bugs in htmlPrefilter, fixed in 3.5.0. Pin the new version and consider Subresource Integrity if it loads from a CDN.
5. Add the policies. A Content-Security-Policy and a DMARC record are both projects rather than switches, because a wrong CSP breaks the site and a wrong DMARC drops legitimate mail. Start both in report-only mode and tighten over weeks.
6. Tidy the rest. Hide the server version, publish a security.txt per RFC 9116 so researchers know where to report.

The guide to reading a scan report goes into false positives, which are common in header and cookie checks when a site is behind a CDN that rewrites responses, and into a triage method that holds up when the list is fifty items long instead of nine.

A worked example: what a well-configured response looks like

It helps to know what "good" looks like before you start. The following is a response header set that passes every transport, header and cookie check the website scanner runs.

HTTP/2 200
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' 'nonce-4f9a1c'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
cross-origin-opener-policy: same-origin
cross-origin-resource-policy: same-origin
set-cookie: __Host-session=9d2f...; Path=/; Secure; HttpOnly; SameSite=Lax
cache-control: no-store

A few of these deserve comment. The HSTS value is the minimum the Chromium preload list accepts: a year, subdomains included and the preload token. The CSP uses a per-response nonce rather than 'unsafe-inline', which is the difference between a policy that stops injected scripts and one that merely looks like it does. frame-ancestors 'none' makes X-Frame-Options redundant on modern browsers, but keeping both costs nothing. The cookie uses the __Host- prefix, which forces Secure, forbids a Domain attribute and requires Path=/, so it cannot be overwritten from a subdomain.

The DNS side of the same site would carry records like these:

example.com.          TXT  "v=spf1 include:_spf.google.com -all"
_dmarc.example.com.   TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"
example.com.          CAA  0 issue "letsencrypt.org"

SPF (RFC 7208) with -all says only the listed servers may send as this domain; DMARC with p=reject tells receivers to act on that; CAA restricts which certificate authorities may issue for the name. Each is a single record, and together they close the two ways a stranger could impersonate the domain: by email and by certificate.

What scanners miss

An honest guide has to spend as long on the gaps as on the coverage, because the gaps are where people get hurt while holding a clean report.

• Everything behind a login. A passive external scan sees only public pages. The admin panel, the user dashboard and the API that serves them are invisible, and that is usually where the valuable data lives.
• Logic and authorisation flaws. Broken access control is the top category in the OWASP Top 10:2021, and no scanner detects it, because it is a mismatch between what the application does and what it should do. See the OWASP Top 10 guide for which categories are scannable at all.
• Server-side injection. A passive scan cannot prove SQL injection exists because proving it means sending an injection. It can only note conditions that make injection more likely.
• New malware. A file with no signature, a clean structure and a payload that only activates on a specific date will pass a file scan. That is why sandbox detonation and endpoint protection exist alongside static scanning.
• Whether a phishing message is a lie. A URL check tells you the link goes to login-microsoft.example rather than Microsoft. It cannot tell you that the invoice attached to a message from a real, compromised supplier is fraudulent.
• Compromise that has already happened. A browser scan tests configuration, not whether a keylogger is present. A website scan tests exposure, not whether a web shell was uploaded last month.

None of this is a reason to skip scanning. It is a reason to place scanning where it belongs: as the first, cheapest and most frequent layer, with updates, backups, a password manager, second factors and, for anything that matters commercially, a periodic human assessment layered on top.

How often to scan

Frequency depends on how often the target changes and how bad a miss would be. The table gives a reasonable default; adjust it upward for anything handling payments or personal data.

Scan.now runs on demand rather than on a schedule, and that is deliberate: a scan is meant to be read by a person who then acts, not to add another unread alert to a channel. Signing in is optional and changes nothing about how a scan works. If you need continuous monitoring of a production site, run a scanner on your own infrastructure on a timer; the next section explains which.

The open-source tools behind the approach

Nothing in security scanning is secret, and the best tools are free. Scan.now's engines draw on the same techniques and, in several places, the same data as the well-known open-source projects, and it is worth knowing what each one is for. Nuclei from ProjectDiscovery runs YAML templates that describe how to detect a specific condition, and its community template library is the closest thing the field has to a shared checklist. ZAP, now maintained by Checkmarx, is a proxy-based dynamic scanner with both passive rules, which watch normal traffic, and active rules, which attack; it is the right tool once you own the target. OpenVAS, the scanner in Greenbone Community Edition, covers network services rather than web applications and uses a feed of network vulnerability tests. testssl.sh is a bash script that tests a TLS endpoint for protocols, ciphers and named vulnerabilities such as ROBOT and Heartbleed. Retire.js keeps a JSON repository of JavaScript libraries with known vulnerabilities and is the reference the JavaScript scanner matches against. ClamAV, maintained by Cisco Talos, is the open-source antivirus engine with daily-updated signature databases, and it anchors the signature layer of file scanning.

The comparison of open-source scanners explains when to reach for each, and the methodology page describes exactly which requests Scan.now sends and what it does with the responses.

Where to go next

If you have a specific worry, go to the hub that covers it. If you do not, run the three headline tools in this order: the browser check, because it takes seconds and affects everything else you do online; the website scanner against any site you are responsible for; and the file scanner the next time an attachment makes you hesitate. Then read the browser, website, file and privacy hubs in whatever order the results make urgent. Scanning is not a one-time audit; it is a habit that makes the boring, well-understood mistakes visible before someone else profits from them.