Sicherheitsaudit für Websites

Eine Prüfung von außen, wie gut die Website ihre Besucher schützt: HTTPS und Zertifikat, Sicherheits-Header, Cookies, Mixed Content, CORS und Dateien, die ein Deployment nie veröffentlichen sollte.

• Alle Leistungen

Ein Sicherheitsaudit beantwortet eine praktische Frage: Was sieht ein Angreifer, wenn er Ihre Website von außen betrachtet, und welche Türen stehen offen, obwohl sie fast nichts kosten, sie zu schließen? SiteScan.top betrachtet die Website genau so, wie jeder Besucher oder Bot sie sieht — ohne Serverzugang, ohne Agenten und ohne Änderungen am Code — und macht aus den Befunden eine Liste konkreter Korrekturen mit einer Priorität für jede.

Was das Audit umfasst

HTTPS und Zertifikat. Wir prüfen, ob die Website über HTTPS antwortet und einfaches HTTP dorthin umleitet, ob das Zertifikat gültig ist, auf den richtigen Namen ausgestellt wurde und nicht in den nächsten Wochen abläuft, ob die Kette vollständig und die Signatur zeitgemäß ist. Wir zeigen, welche TLS-Versionen der Server noch akzeptiert: TLS 1.0 und 1.1 sind zurückgezogen, und ein Server, der sie noch spricht, besteht keine Compliance-Prüfung und ermöglicht Downgrade-Angriffe.

Sicherheits-Header. Die Antwort-Header entscheiden, wie weit der Browser der Seite vertrauen darf. Das Audit liest alle relevanten:

• Strict-Transport-Security — ob HSTS aktiv ist, wie lange der Browser es sich merkt, ob Subdomains abgedeckt sind und ob die Domain für die Preload-Liste der Browser in Frage kommt;
• Content-Security-Policy — ob es überhaupt eine Richtlinie gibt und ob sie Skripte wirklich einschränkt oder unsafe-inline und beliebige Hosts erlaubt;
• X-Frame-Options und frame-ancestors — Schutz vor Clickjacking, bei dem Ihre Seite unsichtbar in eine fremde eingebettet wird;
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy — kleine Header, die mit einer Zeile Konfiguration ganze Klassen von Problemen schließen.

Mixed Content und Cookies. Eine über HTTPS ausgelieferte Seite, die ein Skript oder Bild über HTTP lädt, ist nur so sicher wie ihre schwächste Ressource. Der Crawl meldet jede solche Ressource auf jeder besuchten Seite. Cookies werden auf die Flags Secure, HttpOnly und SameSite geprüft: Ohne sie kann ein Sitzungscookie über eine unverschlüsselte Verbindung gehen oder von einem eingeschleusten Skript gelesen werden.

CORS und gefährliche Methoden. Wir senden eine Anfrage von einem fremden Ursprung und prüfen die Antwort. Ein Server, der jeden Origin zurückgibt und Anmeldedaten erlaubt, lässt jede Seite, die ein angemeldeter Besucher öffnet, Ihre Website in seinem Namen lesen. Außerdem prüfen wir, ob der Server auf TRACE antwortet — eine Methode, die keine Website braucht.

Offenliegende Dateien. Manchmal veröffentlicht ein Deployment, was es nie sollte: .env mit Datenbankpasswörtern, den Ordner .git mit der gesamten Quellcode-Historie, SQL-Dumps und Archive, Verzeichnis-Listings, JavaScript-Source-Maps. Jeder Befund wird anhand des Antwortinhalts bestätigt, nicht nur am Statuscode, sodass eine „200 OK“-Seite mit dem Text „nicht gefunden“ nicht als Leck gemeldet wird.

Sicherheitskonventionen. Die Datei /.well-known/security.txt sagt Forschern, wohin sie eine Schwachstelle melden können; die Adresse change-password lässt Passwortmanager Nutzer direkt zum richtigen Formular schicken. Beides ist nicht Pflicht, aber ein Zeichen einer ausgereiften Website.

So funktioniert es

Sie geben die Adresse der Website ein und starten den Scan. Der Scanner öffnet die Seiten in einem echten Browser, folgt internen Links und führt die Serverprüfungen aus. Jede Anfrage ist eine gewöhnliche Anfrage, die auch ein Besucher stellen könnte: Das Audit errät keine Passwörter, sendet keine Exploits und belastet die Website nicht. Ein typischer Scan dauert ein bis zwei Minuten.

Was Sie erhalten

Das Ergebnis ist ein Bericht mit einer Gesamtbewertung der Sicherheit und einer nach Schwere sortierten Liste der Befunde. Jeder Befund sagt, was gefunden wurde, unter welcher Adresse, warum es wichtig ist und wie es sich beheben lässt — meist mit einer fertigen Konfigurationszeile für nginx, Apache oder die Anwendung. Befunde, die eine Frage der Wahl und kein Fehler sind (DNSSEC, CAA, HSTS-Preload), sind als optional markiert, damit sie die wichtigen nicht überdecken.

Den Bericht können Sie per Link teilen, als PDF für Kunden oder Dienstleister exportieren oder als Aufgabenbeschreibung für Entwickler kopieren. Nehmen Sie die Website ins Monitoring auf, und das Audit wird regelmäßig wiederholt: Entfernt ein Release einen Header oder nähert sich das Zertifikat dem Ablauf, erhalten Sie eine E-Mail oder eine Telegram-Nachricht, statt es von Nutzern zu erfahren.

Für wen es sich lohnt

Das Audit lohnt sich vor dem Start einer neuen Website, nach einem Wechsel des Hostings oder CDN, vor einem Penetrationstest (damit die Tester ihr Budget für echte Probleme statt für fehlende Header ausgeben) und als regelmäßige Kontrolle für Agenturen, die Dutzende Kundenseiten betreuen. Es ersetzt keinen vollständigen Penetrationstest, findet aber in Minuten und zu einem Bruchteil der Kosten die häufigsten Konfigurationsfehler.