External Security Check · Methodology
How the External Security Check works
We look at your organization the way an outsider (including an attacker) can: public DNS, public certificate logs, and the pages any visitor receives. Every check is passive and rule-based. No AI is used, and nothing is ever submitted, logged into or tested for weaknesses.
What we never do
- Submit, fill in or test any form
- Log in, or try passwords
- Request hidden or private paths (for example /.env, /.git, admin pages, plugin readme files)
- Scan ports, send attack payloads, fuzz, or try to exploit anything
- Test whether subdomains can be taken over
- Accept or reject cookie banners, or click anything on your pages
We only request: your homepage, the http version of your homepage, /.well-known/security.txt, and up to five donation, contact and form pages linked from your homepage. Requests are identified with the user agent OST-SecurityCheck/1.0 (+https://ost.agency/tools/external-security-check/methodology/).
Who receives the full report
A detailed list of weaknesses for someone else's website would help attackers, so:
- If your email address is at the scanned domain (for example [email protected] checking charity.org or donate.charity.org), you receive the full technical report: exact versions, records, headers and evidence.
- Otherwise you receive the summary report: the score, the areas and general fixes, without exploitable specifics. Only the summary is stored for these requests.
The eight areas we check
| Area | Weight | What we check | Source |
|---|---|---|---|
| Email spoofing risk | 20% | SPF (present, ending, 10-lookup limit), DMARC (policy, pct, reporting address), DKIM on common selectors (Google, Microsoft, Mailchimp, SendGrid, Mailgun, Amazon SES and others), MTA-STS, TLS-RPT, BIMI. | Public DNS (Cloudflare 1.1.1.1 and Google 8.8.8.8). |
| Known vulnerabilities | 20% | Website platform version (WordPress generator tag), plugin and theme versions in page source, and JavaScript library versions (jQuery, Bootstrap, Lodash, Moment and others) matched to published vulnerabilities. | WordPress.org core version list and the OSV.dev vulnerability database, cached for 24 hours. |
| Website security settings | 15% | http to https redirect, HSTS, Content Security Policy (and whether it allows inline or eval scripts), clickjacking protection, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, cookie flags (Secure, HttpOnly, SameSite) and server version banners. | Response headers from your homepage. |
| Donor and visitor data exposure | 15% | On your homepage and up to five donation, contact and form pages: which advertising and social media companies receive requests, session-recording tools on pages with forms, Meta Pixel advanced matching, trackers that start before a cookie choice when a consent banner is shown, and outside scripts on payment pages. | A real browser loading each page, recording the network requests it makes. |
| Domain and certificates | 10% | DNSSEC, CAA records, certificate validity, expiry and issuer, and how many hostnames appear in public certificate logs. | Public DNS, the TLS handshake, and crt.sh certificate transparency logs. |
| Third-party scripts | 8% | How many outside domains run scripts on your pages, scripts from public code CDNs without Subresource Integrity, and scripts loaded over http. | A real browser loading your pages. |
| Form security | 7% | Visible bot protection (CAPTCHA, hidden trap fields), https form submission, anti-forgery tokens, personal details sent with GET. | The same rule set as our Website Health & Form Security Check. |
| Security maturity signals | 5% | A valid /.well-known/security.txt (RFC 9116, with a Contact and an unexpired Expires date) and a privacy policy link. | /.well-known/security.txt and your homepage. |
How the score works
- Every finding has a severity: critical, high, medium, low or info, based on real risk. For example, email anyone can fake in your name ranks above a missing Permissions-Policy header.
- Each area starts at 100 and loses points once per type of issue: critical 45, high 25, medium 12, low 5, info 0 (minimum 0).
- The overall score is the weighted average of the eight areas, using the weights above.
- A serious problem is never hidden by a good average: any critical finding caps the overall score at 59, and any high finding at 79.
- Grades: A is 90 or more, B 80 to 89, C 70 to 79, D 60 to 69, F below 60.
Recognised standards
Every finding is mapped to the OWASP Top 10 (2021) where it applies, a CIS Controls v8 safeguard, and a NIST Cybersecurity Framework 2.0 function (Govern, Identify, Protect, Detect, Respond, Recover), so your IT team or auditor can place it in their own framework.
Limits
- Protections that run on your server (rate limiting, server-side validation, spam filtering) cannot be seen from outside. Where that matters we say "no visible protection detected".
- We only see software versions your pages reveal. Hidden versions are not checked, and plugin versions are listed without matching them to specific vulnerabilities.
- DKIM uses selector names your provider chooses. If yours is uncommon, we may not find it.
- Results are cached for 24 hours per domain, and a domain can be checked up to five times a day.
For a deeper look
These free specialist tools go further in one area each: internet.nl (email and web standards), Mozilla Observatory (headers), SSL Labs (https), and Blacklight (trackers). For a hands-on review, talk to OST.