1. What a check reads
- The page itself: the served HTML and the response headers, just like a normal visit.
- The files your page loads itself: JavaScript, lazy-loaded parts, stylesheets and configuration files, only from your own domain. Every browser loads these files too.
- The certificate: validity and expiry, through the same TLS handshake every browser performs.
- Public DNS records: email protection and domain settings, without talking to your server.
- Open vulnerability databases: matching detected software. Only the package name and version go there, never your address.
If we find a secret key, we never use it. The report states the type and where it was found, the value only shortened, for example sk_live_…9f2A.
2. What we never do
- Probe hidden paths or request files such as .env
- Load files your site does not include or fetch itself (except the public file /.well-known/security.txt), or read scripts from other domains
- Look for open ports (port scan)
- Submit forms or send attack payloads
- Log in or use keys it finds
- Show or store the full values of keys it finds
- Check internal or private addresses
More under What we don't check and in the acceptable use policy.
3. How the grade is calculated
Security headers add points, findings deduct points. The heaviest are an exposed secret key, an address strangers can take over, and a vulnerability that the US agency CISA lists as actively exploited. Data protection and DNS notices are in the report but don't change the grade. The grade measures the attack surface.
| Grade | Points |
|---|---|
| A | 90 to 100 |
| B | 75 to 89 |
| C | 60 to 74 |
| D | 40 to 59 |
| E | 20 to 39 |
| F | below 20, or no HTTPS |
Every finding means "potentially affected", not proof. 100 points mean that none of our checks triggered, not that the site is secure. What lies behind the surface, such as databases and access permissions, only a Security Audit can see.
4. What we check
| Area | What we look at |
|---|---|
| Encryption and certificate · 6 | Whether your site is reachable over an encrypted connection and the certificate is valid, the padlock in the browser. If either is missing, third parties can read along or visitors see a warning page. |
| Browser security settings · 9 | House rules your server sends to the browser with every response, for example: do not run scripts from elsewhere. Without them, the browser also runs injected code. |
| Protection against spoofed email · 6 | Whether a record at your domain provider defines who may send email in your name. Without it, fake invoices with your sender address get through more easily. |
| Domain and DNS · 5 | Public records of your domain: whether a dangling redirect hands your address to strangers, who may issue certificates, whether DNSSEC is active and where security researchers can report vulnerabilities. |
| Outdated software · 2 | Components of your site in versions with publicly known vulnerabilities. |
| Source code and JavaScript files · 28 | What any visitor can read in the source and JavaScript files of your app, for example keys for databases, AI services or payments. |
| Data protection (GDPR) · 5 | Common data protection mistakes that can be proven from the outside and often lead to legal warnings in Germany: Google Fonts from Google's servers, tracking before consent, embedded content and missing mandatory links. Not legal advice. |
| Cookies · 2 | Whether the cookies on your site are protected against eavesdropping and third-party scripts. |
Every finding is mapped to the recognised standards CWE, OWASP Top 10, OWASP ASVS and BSI IT-Grundschutz. Every check with its stable ID is listed under Checks.
5. Data sources
We match known vulnerabilities live against OSV.dev, actively exploited ones against the CISA catalog, the probability of exploitation against FIRST EPSS and end of support against endoflife.date. We detect software with the open rules of webappanalyzer and Retire.js, and keys with our own patterns and the gitleaks rules. Before release, we check every change against over 100 real sites for false alarms.
Technical details such as file limits, points per header and deductions are in the developer docs under Method.