Website security checks from outside: what they cover

What an external check can read

Everything the server sends to any visitor:

• The page itself: the scripts and stylesheets it loads and where they come from, links, forms and their destinations, text, and redirects.
• Response headers: for example a Content Security Policy, HSTS (RFC 6797), cookie flags and caching rules.
• The certificate and the connection: the dates, the issuer, and the protocol versions the server accepts.
• DNS records: address, mail and authority records, and their changes over time.
• Public paths: whether a short list of well-known files or folders answers.
• Version hints: a generator tag, a script file name or a header can name a product and sometimes a version.

From these it can report what is there and what changed. A script from a new host, a header that disappeared, a redirect that was not there yesterday: each is a fact that anyone could verify in a browser.

What it can only estimate

Versions. A version string found in public output may be out of date, deliberately hidden or wrong. Linux distributions often fix a vulnerability in a library without raising its version number, so the same string can be safe on one server and vulnerable on another. An external check can say “this version has a known vulnerability, so the site may be affected”, and it should say “possibly”, not “yes”.

Matches against vulnerability lists. Public lists such as the CISA Known Exploited Vulnerabilities catalog and the National Vulnerability Database say which products have known problems. A match tells you a fix exists. It does not tell you whether the vulnerable code runs on your server, whether it is reachable, or whether anyone has used it against you. A list of exploited vulnerabilities is a stronger signal than a score, but still not proof about your site.

Importance. Severity scores describe a flaw in general, not in your setup. Treat them as a way to order the work.

What needs your code or your server

• The dependency list of the application. Which libraries and which versions run on the server is in files such as lock files, not in public output. A check from outside can only guess.
• Injection and access-control flaws. The OWASP Top 10 names the classes of weakness that matter most; testing most of them means sending crafted input to a running application or reading its code, with the owner’s permission, in a planned test.
• Anything behind a login, including admin areas and customer data.
• Server configuration: file permissions, open ports that are not web ports, outdated operating systems, secrets in the wrong place.
• Backups, logs and who has access. None of it is public.

For these, the right tools are a dependency audit run on the code, a review of the server and an authorised penetration test. The OWASP Web Security Testing Guide describes how such tests are done.

An example of the gap

A site shows “Powered by” a plugin in a script file name, with version 2.4. A vulnerability list says versions below 2.6 have a known flaw. The external check reports a possible match. On the server, the hosting company has patched the flaw in its own build of the plugin without changing the number, so the site is not affected. Next door, a site with the same string runs the plain 2.4 and is affected. The check saw the same thing in both cases. Only someone with access to the server could tell them apart, which is why the check words the finding as “possibly affected” and leaves the decision to a person.

Reading a result

• Something changed: look at it. The check can tell you what and where. You decide whether it was planned.
• Something possibly affected: confirm the real version on the server, then update or accept the risk with a note of why.
• Nothing found: it means the check found nothing in what it can read. It does not say the site is secure. If the check could not read part of the site, for example because a firewall blocked it, the honest result is “partly checked”, not “no problems”.
• The same alert again and again: decide, write the reason down, and set a date to look again. An ignored alert with no date is how a real problem gets lost.

A sensible split of work

1. Let an external check watch the public side every day. It costs little and catches visible changes.
2. Put a dependency audit into the release process of any site you build.
3. Update the platform and its plugins on a schedule, and remove what you do not use.
4. For high-value sites, book a test by someone who is allowed to attack them.

What Beamfar does

Beamfar’s security checks read your pages from outside, from the Solo plan, and alert you to new script hosts, hidden links, spam text and redirects away. Read security checks for what is covered and what is not. The checks only detect and alert; they do not block anything and do not read your server. A check that could not read part of a site has a partial result, not a clean one. You can try an outside read of one page with the free site check.

Sources

Read on 9 November 2026. Standards and vendor pages change; confirm the current text before you rely on it.

• OWASP Web Security Testing Guide (owasp.org)
• OWASP Top 10 (owasp.org)
• CISA, Known Exploited Vulnerabilities Catalog (www.cisa.gov)
• NIST, National Vulnerability Database (nvd.nist.gov)
• RFC 6797, HTTP Strict Transport Security (HSTS) (www.rfc-editor.org)