Security-Scan

Verstehen Sie, wie der Security-Scan Ihre Website prüft — und was die Ergebnisse bedeuten.

Der Security-Scan ist passiv: Er simuliert einen normalen Browser-Besuch und analysiert die Antworten des Servers. Es werden keine Angriffe durchgeführt, keine Passwörter ausprobiert und keine Daten verändert.

Scan starten

1
Domain verifizieren (einmalig)

Für Security-Scans müssen Sie einmalig nachweisen, dass Ihnen die Domain gehört. Das schützt vor Missbrauch. Unter Domains können Sie Ihre Domain in wenigen Minuten verifizieren.

Anleitung: Domain verifizieren →

2
Neuen Scan starten

Im Dashboard auf Neuer Scan klicken, URL eingeben und „Security-Scan" oder „Full Scan" wählen.

  • Quick Scan — ~10 Sekunden, die wichtigsten Checks, kein Crawler
  • Full Scan — ~1–3 Minuten, alle Prüfungen, mehrere Seiten gecrawlt, inkl. Lighthouse-Performance
3
Ergebnisse lesen

Nach dem Scan sehen Sie einen Gesamt-Score (A–F) und eine Liste aller Findings, sortiert nach Schweregrad.

Was wird geprüft?

SSL/TLS-Zertifikat

  • Ist ein gültiges HTTPS-Zertifikat vorhanden?
  • Läuft das Zertifikat bald ab? (Warnung ab 30 Tagen)
  • Werden schwache Verschlüsselungsalgorithmen verwendet?
  • Wird HTTP automatisch auf HTTPS umgeleitet?

HTTP-Sicherheitsheader

Sicherheitsheader sind Anweisungen, die der Server an den Browser schickt und die viele Angriffe automatisch blockieren. Geprüft werden:

  • Content-Security-Policy (CSP) — Schützt vor Cross-Site-Scripting (XSS)
  • Strict-Transport-Security (HSTS) — Erzwingt HTTPS dauerhaft
  • X-Frame-Options — Verhindert Einbettung in fremde Seiten (Clickjacking)
  • X-Content-Type-Options — Verhindert MIME-Sniffing
  • Referrer-Policy — Kontrolliert, welche Informationen bei externen Links übertragen werden
  • Permissions-Policy — Schränkt Browser-APIs ein (Kamera, Mikrofon etc.)

Cookie-Sicherheit

  • Sind Session-Cookies mit HttpOnly geschützt? (Verhindert Zugriff per JavaScript)
  • Sind Cookies mit Secure markiert? (Nur über HTTPS übertragen)
  • Ist das SameSite-Attribut gesetzt? (Schutz vor CSRF-Angriffen)

Exponierte Informationen

  • Verrät der Server seine Version in Antwort-Headern? (z. B. Server: Apache/2.4.51)
  • Sind sensible Dateien öffentlich erreichbar? (z. B. /.env, /wp-config.php, Git-Repositories)
  • Sind Fehlerseiten informativ genug, um Angriffe zu erleichtern?

CMS-Erkennung (WordPress, Shopware etc.)

  • Wird ein bekanntes CMS erkannt?
  • Ist die CMS-Version öffentlich sichtbar? (Angreifer nutzen das für gezielte Suche nach Schwachstellen)
  • Sind bekannte unsichere Plugin-Pfade erreichbar?

Befallsprüfung (Malware-Spuren)

  • Jede gecrawlte Seite wird auf Spuren im ausgelieferten HTML/JS geprüft: versteckte iframes, verschleierte Skripte, Weiterleitungen auf fremde Adressen, versteckte Links/Spam-Texte, Cryptominer, Passwortformulare mit fremdem Ziel
  • Seitenvergleich: fremde Skriptquellen, die nur auf wenigen Seiten vorkommen
  • Cloaking-Vergleich: Abruf als Besucher, Googlebot und Mobilgerät aus der Google-Suche
  • Bei Treffern wird die Note abgewertet; der Bericht nennt Zahl und Beispiele der betroffenen Seiten
Grenze: Es wird geprüft, was der Server ausliefert. Dateibefall (Webshells, veränderte Dateien) erkennt das Code-Audit.

Abdeckung der Prüfung

Jeder Bericht zeigt, wie viele Seiten entdeckt und tatsächlich geprüft wurden, und warum die Prüfung gegebenenfalls früher endete (Seitenlimit oder Zeitlimit von 30 Minuten).

Den Score verstehen

Der Score (A bis F) ergibt sich aus der Anzahl und dem Schweregrad der Findings:

A Keine kritischen Findings, maximal 2 mittlere Probleme
B Keine kritischen Findings, einige mittlere Probleme
C 1 kritisches Finding oder viele mittlere Probleme
D 2–3 kritische Findings
F 4 oder mehr kritische Findings — dringender Handlungsbedarf

Häufige Findings und wie man sie behebt

„Content-Security-Policy fehlt"

Fügen Sie in Ihrem Webserver einen CSP-Header hinzu. Bei Apache in der .htaccess:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'"

Achtung: Eine zu restriktive CSP kann externe Skripte (Analytics, Chat-Widget) blockieren. Testen Sie die Einstellung gründlich.

„HSTS nicht gesetzt"

Bei Apache in der .htaccess (nur wenn HTTPS durchgängig funktioniert!):

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

„Zertifikat läuft bald ab"

Erneuern Sie Ihr SSL-Zertifikat. Bei Let's Encrypt: Certbot auf dem Server ausführen (certbot renew). Viele Hosting-Anbieter erneuern das Zertifikat automatisch — prüfen Sie die Einstellung in Ihrem Hosting-Panel.

„Server-Version in Header sichtbar"

Bei Apache: ServerTokens Prod und ServerSignature Off in der httpd.conf. Bei nginx: server_tokens off; in der Konfiguration.

„.env-Datei öffentlich erreichbar"

Das ist ein kritischer Fund! Sperren Sie sofort den Zugriff auf .env-Dateien und setzen Sie alle darin enthaltenen Passwörter und API-Keys zurück. Bei Apache in der .htaccess:

<Files .env>
  Order allow,deny
  Deny from all
</Files>

Scan-Ergebnis exportieren

Sie können den vollständigen Bericht als PDF herunterladen — z. B. um ihn intern weiterzugeben oder als Nachweis zu archivieren. Mit aktivierter KI-Analyse enthält der Bericht zusätzlich eine priorisierte Handlungsempfehlung.

Guide: Berichte & Reports erstellen →

Regelmäßige Scans empfohlen: Sicherheitslücken entstehen auch durch Updates von Plugins oder Serversoftware. Mit Scheduled Scans können Sie Ihre Website automatisch täglich oder wöchentlich prüfen lassen.

Guide: Scheduled Scans einrichten →