Was sich geändert hat

Der Scan heißt jetzt Hullwise und läuft unter hullwise.co. Prüfungen, Preise, Berichte und Konten bleiben, wie sie sind. Gekaufte Berichte öffnen Sie weiter über Ihren Link, die alte Adresse leitet auf die neue um.

Der MCP-Server meldet sich jetzt als hullwise, der Scanner als HullwiseScanner/1.0. Bestehende API-Schlüssel gelten weiter.

Die Content-Security-Policy zählt jetzt nach ihrem Inhalt, so wie beim CSP Evaluator von Google und beim Mozilla Observatory. Regelt sie keine Skripte, erlaubt sie 'unsafe-inline' ohne Nonce oder Hash oder Skripte von beliebigen Adressen, gibt es statt 25 nur 10 Punkte und einen Hinweis, was fehlt. Manche Seiten bekommen dadurch eine schlechtere Note. Die Seite hat sich nicht verändert, die Bewertung ist genauer geworden.

Ob Tabellen in Supabase offen sind, sieht kein Check von außen. Dafür gibt es jetzt einen Selbstcheck: eine SQL-Abfrage, die nur liest, für den SQL Editor im eigenen Projekt. Sie listet jede Tabelle ohne Row Level Security und jede Regel, die allen alles erlaubt. Im Bericht kopieren Sie sie mit einem Klick.

Unter jedem Befund im Bericht können Sie jetzt einen Fehlalarm melden. Die Mail enthält schon Prüf-ID und Domain.

Neue Prüf-ID header.csp.weak (Stufe info) mit dem Feld reasons: no_script, unsafe_inline, wildcard. Der Hinweis code.supabase.rls_check verweist auf den Selbstcheck.

Jede Prüfung ist jetzt anerkannten Standards zugeordnet: CWE von MITRE, OWASP Top 10:2025, OWASP ASVS 5.0.0 und der passende Baustein aus dem BSI IT-Grundschutz, beim Datenschutz die Rechtsgrundlage. Die Zuordnung steht bei jedem Befund im Bericht und im PDF, damit Sie ihn in Audits, für NIS2 oder gegenüber Prüfern einordnen können.

Wir verweisen nur auf Kennungen, die es in der jeweiligen Fassung wirklich gibt, und prüfen das bei jeder Änderung automatisch gegen die Originalquellen.

Neues Feld standards je sichtbarem Befund in /api/v1/scan: cwe, owasp, asvs, bsi, law. Gesperrte Befunde haben es nicht. Im MCP-Ergebnis steht die Zuordnung hinter jedem Befund.

Neu ist ein Datenschutz-Check für typische Abmahn-Gründe: Google Fonts von Google-Servern, Tracking-Cookies und Tracker vor der Einwilligung, eingebettete Videos und Karten sowie fehlende Links zu Impressum und Datenschutzerklärung. Er zählt nicht zur Note, die misst weiter die Angriffsfläche.

Neu ist auch der Bereich Domain und DNS: Wir erkennen Adressen, die per CNAME auf einen nicht mehr vorhandenen Dienst zeigen und von Fremden übernommen werden können, und prüfen CAA, DNSSEC, security.txt, MTA-STS sowie SPF-Einträge mit mehr als 10 DNS-Abfragen.

Die Schlüsselsuche nutzt zusätzlich über 100 Regeln aus dem Open-Source-Projekt gitleaks, etwa für Atlassian, Cloudflare, Datadog, Doppler, Heroku, Mailgun, Pulumi und Square. Im Testlauf mit über 100 echten Seiten gab es damit keinen einzigen Fehlalarm.

Der Scan liest jetzt bis zu 40 nachgeladene Code-Teile, auch solche, die erst von anderen Teilen geladen werden, bei Next.js die Code-Teile aller Seiten aus dem Build-Manifest, Konfigurationsdateien wie /config.json, die der Code beim Start abruft, und Base64-kodierte Schlüssel. In unserem Testparcours mit 13 typischen Leck-Stellen finden wir damit alle 13 statt vorher 7.

Neue Felder findings.privacy und findings.dns (in älteren Berichten nicht vorhanden). Neue Prüf-IDs: privacy.*, dns.*, email.spf.too_many_lookups, email.transport.unprotected. Weitere Anbieter erscheinen unter code.secret.service_token.

Der Scan erkennt jetzt 16 Arten geheimer Schlüssel, neu etwa Konto-Token von Supabase, Mail-Dienste wie Resend und Brevo sowie Zugänge zu Shopify-Admin, Notion, Airtable und Sentry. Gesucht wird auch im Seitenquelltext und in eingebetteten Daten, nicht nur in den JavaScript-Dateien.

Fremde Skripte ohne Prüfsumme melden wir nur noch, wenn eine Prüfsumme dort überhaupt möglich ist. Cookies prüfen wir nur noch, wenn sie nach Anmeldung oder Sitzung aussehen. Eine Content-Security-Policy im HTML zählt jetzt mit. Das hat in unserem Testlauf mit über 100 echten Seiten rund 60 Fehlalarme entfernt.

Neu sind Hinweise zu Firebase-Regeln, zu Supabase-Projekten mit dem neuen Schlüsselformat und zu Seiten, die über http nicht auf https weiterleiten. Wo wir die Plattform erkennen, nennt der Befund den passenden Weg zur Behebung, etwa für Vercel, Netlify oder Lovable.

Neue Prüf-IDs: code.secret.mail_api, code.secret.service_token, code.firebase.rules_check, https.no_redirect. Schlüssel-Befunde tragen found mit Fundstelle und gekürztem Wert.

Apps aus Lovable, Bolt, v0, Replit, Cursor, Claude Code oder Codex legen ihre Konfiguration oft in die JavaScript-Dateien, die jeder Browser beim Seitenbesuch lädt. Dort landen auch Schlüssel, die nie öffentlich sein sollten. Der Check lädt jetzt genau diese Dateien mit: nur die, die die Seite selbst einbindet, nur von derselben Domain, höchstens 10 Dateien und 6 MB.

Darin suchen wir nach 16 Arten geheimer Schlüssel und Zugangsdaten, etwa dem Supabase-Generalschlüssel (service_role), Schlüsseln für OpenAI, Anthropic und Stripe, AWS-Zugängen und Webhook-Adressen. Gemeldet werden Art, Anzahl und Fundstelle, der Wert nur gekürzt, etwa sk_live_…9f2A. Den vollständigen Wert zeigen und speichern wir nie. Ein solcher Fund zieht 40 Punkte ab.

Dazu erkennen wir, worauf eine App läuft, etwa Lovable, Vercel oder Supabase. Pfade probieren wir weiterhin nicht aus, und gefundene Schlüssel benutzen wir nie.

Neue Prüf-IDs wie code.secret.supabase_service_role, code.secret.openai, code.llm.browser_direct und code.supabase.rls_check. Der Bericht hat zwei neue Felder: platforms nennt die erkannten Plattformen, scripts die Zahl der geladenen JavaScript-Dateien. Befunde zu offen liegenden Schlüsseln tragen critical: true.

Ohne bezahlten Plan zeigt der Bericht die Note, die Punkte und die Zahl aller Befunde. Vollständig mit Erklärung sind die zwei dringendsten Befunde. Alle Befunde mit Anleitung enthält der Bericht ab dem Paket Business.

Gekürzt wird auf unserem Server. Gesperrte Befunde kommen also gar nicht erst im Browser oder beim Client an. Das gilt für die Startseite, die API und den MCP-Server.

Business kostet 149 € im Monat und prüft bis zu 10 Domains jede Woche.

Mit kostenlosem Schlüssel, mit dem Test-Schlüssel sc_test_demo und am MCP-Server ohne Schlüssel tragen gesperrte Befunde locked: true, ohne id und ohne Text. Das Feld locked nennt mit hidden die gesperrten und mit total alle Befunde. Mit einem Schlüssel aus einem Konto mit Business fehlt es.

Hullwise hat eine neue Website. Der Check läuft ohne Anmeldung direkt auf der Startseite, dazu kommen Hilfe-Center, Entwickler-Doku und diese Seite.

Neu ist die REST-API v1, bei der ein Aufruf den ganzen Check liefert. Sie braucht einen Schlüssel. Der ist kostenlos und erlaubt 100 Checks pro Stunde. Der MCP-Server funktioniert auch ohne Schlüssel, dann mit 20 Checks pro Stunde je IP-Adresse.

GET /api/v1/scan liefert den Bericht als JSON. Der MCP-Server bietet die Werkzeuge scan_website und list_checks für Claude, ChatGPT, Cursor, Codex und VS Code.

Der Check prüft jetzt, ob jemand Mails im Namen Ihrer Domain fälschen kann. Dafür lesen wir im öffentlichen DNS die Einträge für SPF und DMARC. Fehlt einer, erlaubt SPF jeden Absender oder steht DMARC nur auf Beobachten, steht es im Bericht.

Dazu kommt das Zertifikat: ob es gültig ist, wer es ausgestellt hat, wann es abläuft und ob die Verbindung noch über TLS 1.0 oder 1.1 läuft. Unter 14 Tagen bis zum Ablauf ist das eine Warnung, unter 30 Tagen ein Hinweis.

In API und MCP enthält der Bericht dafür die neuen Felder tls und email. Die Befunde tragen IDs wie email.dmarc.missing oder tls.expiring.

Leitet Ihre Seite weiter, etwa von der Domain ohne www auf die mit www, folgt der Check bis zu fünf Stationen. Jede Station prüfen wir vorher darauf, dass sie nicht auf eine interne oder private Adresse zeigt.

So kann eine öffentliche Seite unseren Check nicht auf Adressen umlenken, die nicht ins Internet gehören. Geprüft und benotet wird die Seite, auf der die Weiterleitung endet.

Über API und MCP nennt das Feld url im Bericht den Hostnamen, auf dem die Weiterleitung endet. Zeigt eine Station auf eine interne Adresse, kommt der Fehler blocked_host zurück.

Jeder der 63 Prüfpunkte hat jetzt eine feste ID, zum Beispiel header.csp.missing oder version.vulnerable. Die ID ändert sich nicht, auch wenn wir den Text eines Befunds verbessern.

Damit können Sie Befunde zählen, in Ihrer Pipeline gezielt auf einzelne reagieren oder sie bewusst ignorieren.

Das Feld id steht an jedem Befund, in der API-Antwort ebenso wie in den strukturierten Daten von scan_website.