Checks

What a finding looks like

A finding is a place where something is missing or stands out. Every finding in the response has this shape.

{
  "id": "code.secret.supabase_service_role",
  "sev": "warn",
  "critical": true,
  "label": "Supabase master key exposed (service_role, 1×)",
  "why": "With this key, any visitor can read, change and delete your entire database, bypassing all access rules. …"
}

The REST API writes label and why in German unless you ask for English with lang=en, see Language. The MCP server answers in English by default. Branch on id, not on the text. A finding always means "potentially affected". It proves nothing, because we only read what any visitor sees. For keys, we name the type and where it was found and show the value only shortened, for example sk_live_…9f2A. We never output the full value.

Locked finding

Without a paid plan, only 2 findings come in full. The others keep their position in the list, but only with severity and locked: true. Check locked before your code branches on id. Full reports are available with Business, see Shortened reports.

{
  "sev": "info",
  "label": "",
  "locked": true
}

Encryption and certificate

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. Findings appear in findings.https and findings.tls.

Browser security settings

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. Findings appear in findings.headers.

Protection against spoofed email

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. Findings appear in findings.email.

Domain and DNS

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. Findings appear in findings.dns.

Outdated software

Components of your site in versions with publicly known vulnerabilities. Findings appear in findings.versions.

Source code and JavaScript files

What any visitor can read in the source and JavaScript files of your app, for example keys for databases, AI services or payments. Findings appear in findings.exposure.

Data protection (GDPR)

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. Findings appear in findings.privacy.

Cookies

Whether the cookies on your site are protected against eavesdropping and third-party scripts. Findings appear in findings.cookies.

Mapping to standards

Every check is mapped to recognized standards, so a finding can be placed in audits, for NIS2 or for auditors. The mapping is in the table above, next to every finding in the PDF report and in the API field standards. It is our classification, not a certification.

• CWE (MITRE): the type of weakness. We only use IDs that MITRE allows for mapping. If none fits, the field stays empty.
• OWASP Top 10:2025: the category follows from the official CWE list per category. Only for checks without a CWE do we classify ourselves, then almost always A02 (Security Misconfiguration).
• OWASP ASVS 5.0.0: the requirement the finding violates, for example V3.4.1 for HSTS.
• BSI IT-Grundschutz (Compendium Edition 2023, German Federal Office for Information Security): the module, for example APP.3.1 web applications and web services, plus the technical guidelines TR-03116-4 (TLS) and TR-03108 (email transport).
• Law: for data protection, the provision, for example Section 25 TDDDG or Art. 13 GDPR. Not legal advice.

We only reference IDs and write the texts ourselves. OWASP publishes ASVS and the Top 10 under CC BY-SA 4.0, CWE comes from MITRE.

What we never do

The check stays on the surface. It loads the page and the JavaScript files the page includes itself, from the same domain only. It never does the following, no matter what the request says.

• 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 in the help article What we don't check.