Was wir nicht prüfen

Ein Check ist wie ein Rundgang ums Haus von der Straße aus. Wir sehen offene Fenster und Türen, gehen aber nicht hinein. Hineinschauen darf nur das Audit, und auch das erst mit Ihrer Erlaubnis.

Was ein Check macht

• Er ruft Ihre Startseite einmal auf, so wie es jeder Besucher tut.
• Leitet die Seite weiter, folgt er höchstens fünf Stationen. Jede prüft er vorher darauf, dass sie nicht auf eine interne oder private Adresse zeigt.
• Er lädt die JavaScript-Dateien, die Ihre Startseite selbst einbindet, so wie jeder Browser es beim Öffnen tut. Das sind zuerst höchstens zehn Dateien, nur von Ihrer Domain, je Datei bis 2 MB und zusammen bis 6 MB.
• In bis zu drei kurzen Runden lädt er höchstens 40 weitere Dateien von Ihrer Domain: weitere, die die Startseite einbindet, Teile, die diese Dateien beim Wechsel auf eine Unterseite nachladen (bei Vite-Apps auch Teile, die ihrerseits Teile nachladen), und bei Next.js die Code-Teile der anderen Seiten aus dem Build-Manifest. Auch die holt jeder Browser, sobald jemand klickt.
• Ruft der Code der Seite beim Start eine Konfigurationsdatei derselben Domain ab, etwa /config.json oder /api/config, lesen wir sie mit: höchstens vier, nur Adressen, die als fester Text im Code stehen, nur lesend.
• Er liest die Stylesheets der Seite von Ihrer Domain (für den Datenschutz-Check) und die Datei /.well-known/security.txt, die für Sicherheitsmeldungen gedacht ist.
• Er ruft Ihre Startseite einmal über http:// auf, so wie beim Eintippen der Adresse, und sieht nur nach, ob sie auf https umleitet.
• Beim Verbindungsaufbau liest er Ihr Zertifikat und die Version der Verschlüsselung.
• Im öffentlichen Verzeichnis Ihrer Domain (DNS) fragt er Einträge für Mail-Schutz und Domain ab: SPF, DMARC, MTA-STS, CAA, Weiterleitungen (CNAME) und, über DNS-over-HTTPS bei Cloudflare, DNSSEC. Mit Ihrem Server spricht er dafür nicht.
• Erkannte Software-Versionen gleicht er mit der Datenbank OSV.dev und einer kleinen eigenen Liste ab. Das passiert bei uns, Ihre Seite merkt davon nichts.

Gelesen wird nur, was dabei ohnehin zurückkommt: die Header der Antwort, das HTML der Startseite (die ersten 800 KB) und der Inhalt der geladenen JavaScript-Dateien. In diesen Dateien suchen wir nach Mustern von Zugangsschlüsseln. Was wir finden, benutzen wir nicht.

Was wir nie tun

• Versteckte Pfade ausprobieren oder Dateien wie .env abrufen
• Dateien laden, die Ihre Seite nicht selbst einbindet oder abruft (außer der öffentlichen Datei /.well-known/security.txt), oder Skripte von fremden Domains lesen
• Offene Ports suchen (Port-Scan)
• Formulare absenden oder Angriffs-Code schicken
• Uns anmelden oder gefundene Schlüssel benutzen
• Vollständige Werte gefundener Schlüssel anzeigen oder speichern
• Interne oder private Adressen prüfen

Finden wir etwas, das wie ein Schlüssel aussieht, nennen wir Art und Fundstelle und zeigen den Wert nur gekürzt, etwa sk_live_…9f2A, damit Sie den Schlüssel beim Anbieter zuordnen können. Den vollständigen Wert zeigen, speichern und benutzen wir nie.

Was wir deshalb nicht sehen

• Unterseiten, Login-Bereiche und alles hinter einer Anmeldung.
• Skripte von fremden Domains und Programmteile, die erst nach einer Anmeldung oder über unsere Grenze von 40 nachgeladenen Teilen hinaus geladen werden. Bei Next.js-Apps mit App Router sehen wir die Teile anderer Seiten nur, soweit die Startseite sie nennt.
• Datenbanken und Speicher, etwa ob eine Tabelle ohne Zugriffsregeln offen im Netz steht.
• Zugriffsrechte, Server-Einstellungen und Dateien, auf die nichts verlinkt.
• Ihr Git-Repository und die Umgebungsvariablen auf dem Server.
• Ob Ihr Server neben aktuellen auch alte Versionen der Verschlüsselung annimmt.
• Die Mail-Signatur DKIM, das Cookie-Merkmal SameSite und einzelne WordPress-Plugins.

Bei Apps aus Lovable, Bolt und ähnlichen Werkzeugen steckt das größte Risiko oft in der Datenbank. Einen öffentlichen Supabase-Generalschlüssel finden wir. Ob jede Tabelle Zugriffsregeln hat, sieht ein Check von außen nicht. Das klärt das Audit. Was Sie selbst prüfen können, steht in Zugriffsregeln in Supabase.

Check, Audit und Pentest

Bei einem Penetrationstest, kurz Pentest, versuchen Fachleute gezielt, in Ihr System einzudringen. Umfang und Regeln legen Sie vorher schriftlich fest. Das lohnt sich, wenn Sie sensible Daten verarbeiten oder Ihre Kunden so einen Test verlangen. Hullwise bietet keinen Pentest an. Wenn Sie nicht wissen, was Sie brauchen, schreiben Sie uns. Wir sagen Ihnen auch, wenn das Audit nicht reicht.

Das Audit buchen Sie unter Preise.

Noch Fragen? Schreiben Sie uns.