Logo von nextlevels
Projekt anfragen

Website-Sicherheit prüfen Der kostenlose Security Check

Was jeder Angreifer von außen sieht: Zertifikat, Header, Cookies, offene Dateien und ob Fremde in deinem Namen mailen können.

  • Nur Lesezugriffe, keine Angriffe
  • Ohne Anmeldung
  • Ergebnis sofort

Nur öffentliche Websites. Wie der Port-Check abläuft und wer sein Ergebnis bekommt, steht in den FAQ.

  • BSI TR-02102
  • BSI TR-03108
  • RFC 7208
  • RFC 6376
  • MDN
  • Art. 32 DSGVO

Was der Security Check prüft

Ein defensiver Konfigurations-Check gegen die Adresse, die du einreichst. Keine Exploits, kein Angriff auf Zugangsdaten – nur, was dein Server jedem ausliefert.

  • HTTPS & TLS

    Sehen deine Besucher eine Browser-Warnung?

    Wir prüfen, ob deine Site per HTTPS erreichbar ist, ob HTTP sauber umleitet und ob das Zertifikat gültig ist, zum Hostnamen passt und nicht kurz vor Ablauf steht – read-only gegen deinen öffentlichen Host:443. Dazu kommt der CAA-Eintrag im DNS.

  • Security-Header

    Ist deine Seite gegen eingeschleusten Code und Clickjacking geschützt?

    HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy und Permissions-Policy fehlen in vielen Setups. Der Check zeigt, was die Startseite tatsächlich ausliefert, und erkennt typische Schwächen wie unsafe-inline in der CSP, eine zu kurze HSTS-Laufzeit oder CORS, das fremden Domains samt Login-Daten vertraut.

  • Cookie-Flags

    Können Sitzungs-Cookies abgegriffen werden?

    Sichtbare Set-Cookie-Header der Startseite: Secure, HttpOnly, SameSite – und ob die Seite mit Cookie trotzdem in geteilten Caches landen darf. Wir melden nur Flags – keine Cookies werden gespeichert oder wiederverwendet.

  • Info-Leaks

    Liegen Quellcode oder Zugangsdaten offen im Netz?

    Server-/X-Powered-By-Banner, Directory-Listing, öffentlich erreichbare .git-, .env- oder .DS_Store-Dateien, offene Apache-Statusseiten oder phpinfo(), ein aktiver Debug-Modus, geheime Schlüssel im Quelltext der Startseite und aktives HTTP TRACE. robots.txt und security.txt laufen als Info. Inhalte sensibler Dateien lesen wir nicht aus.

  • Inhalt & Skripte

    Lädt deine Seite unsichere oder manipulierbare Dateien?

    Per HTTP eingebundene Dateien auf der HTTPS-Startseite (Mixed Content) und externe Skripte ohne Subresource Integrity. Beides erkennen wir im ausgelieferten HTML, ohne die Dateien abzurufen.

  • E-Mail-Absender

    Kann jemand Phishing-Mails in deinem Namen verschicken?

    SPF und DMARC aus dem öffentlichen DNS: Ist festgelegt, wer im Namen deiner Domain mailen darf, und greift DMARC mit quarantine oder reject? DKIM suchen wir unter drei gängigen Selektoren.

So sieht dein Report aus

Ein Beispiel, gekürzt und mit erfundener Domain. Jeder Befund sagt, was er für dein Unternehmen bedeutet und wie du ihn behebst.

  • Note von A bis F und Score auf einen Blick
  • Jeder Befund mit Einstufung: Fehler, Warnung oder Hinweis
  • Zu jedem Befund eine konkrete Empfehlung
Jetzt prüfen
NoteC
Beispiel-Reportbeispiel-shop.de
Security-Score

72/100

/.env öffentlich erreichbar (HTTP 200)Fehler

Was das bedeutet: In dieser Datei stehen oft Datenbank-Passwörter und API-Schlüssel. Wer sie abruft, braucht keinen Angriff mehr.

So behebst du es: Versteckte Dateien im Webserver sperren und danach alle Zugangsdaten aus der Datei austauschen.

# nginx
location ~ /\.(?!well-known) { deny all; }
Kein Strict-Transport-Security-HeaderWarnung

Was das bedeutet: Browser dürfen beim ersten Aufruf noch unverschlüsselt verbinden. In einem offenen WLAN lässt sich die Verbindung dabei umleiten.

So behebst du es: HSTS setzen, sobald alle Seiten per HTTPS laufen.

# nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
DMARC mit p=noneWarnung

Was das bedeutet: Gefälschte Mails in deinem Namen werden gemeldet, aber trotzdem zugestellt.

So behebst du es: Die DMARC-Reports zwei bis vier Wochen auswerten, dann auf quarantine umstellen.

# DNS
_dmarc.beispiel-shop.de  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel-shop.de"
Beispiel mit erfundener Domain. Im echten Report steht zu jedem Befund eine Empfehlung; die Konfigurationszeilen hier sind Beispiele für nginx und DNS.

E-Mail-Sicherheit prüfen: SPF, DKIM und DMARC

Drei DNS-Einträge entscheiden, ob Fremde Mails in deinem Namen verschicken können. Der Check liest alle drei – du gibst nur die Website-Adresse ein.

SPF-Check

SPF (Sender Policy Framework) legt fest, welche Server Mails für deine Domain verschicken dürfen. Der Check sucht den TXT-Eintrag, der mit v=spf1 beginnt. Fehlt er, gibt es eine Warnung: Dann kann jeder Server behaupten, in deinem Namen zu senden.

Beispiel-Eintrag

deine-domain.de  TXT  "v=spf1 include:_spf.google.com -all"

DKIM-Check

DKIM (DomainKeys Identified Mail) signiert jede ausgehende Mail, der öffentliche Schlüssel liegt im DNS. Der Check sucht ihn unter den Selektoren default, google und selector1. Nutzt dein Mailanbieter einen anderen, erscheint das als Hinweis, nicht als Fehler.

Beispiel-Eintrag

google._domainkey.deine-domain.de  TXT  "v=DKIM1; k=rsa; p=…"

DMARC-Check

DMARC sagt empfangenden Servern, was mit Mails passiert, die SPF und DKIM nicht bestehen. Der Check liest den Eintrag unter _dmarc deiner Domain. Erst mit p=quarantine oder p=reject werden Fälschungen aussortiert, p=none meldet sie nur.

Beispiel-Eintrag

_dmarc.deine-domain.de  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@deine-domain.de"
So läuft der CheckRead-only · 1 Origin

Ist deine Website so abgesichert, wie sie sein sollte? Der Check prüft in Sekunden, was jeder Besucher – und jeder Angreifer – von außen sehen kann: HTTPS und Zertifikat, Sicherheits-Header, Cookies, offene Dateien und ob Fremde E-Mails in deinem Namen verschicken können. Nur Lesezugriffe, keine Angriffe, kein Login.

Der Check ruft deine Startseite ab wie ein Browser, folgt Weiterleitungen bis zur finalen Adresse und bewertet dort jedes Signal einzeln. Dazu kommen eine TLS-Verbindung und öffentliche DNS-Abfragen für CAA, SPF, DMARC und DKIM. Jede Prüfung zählt gleich viel, eine versteckte Gewichtung gibt es nicht.

Score und Einstufung4 Stufen
  • Bestanden: Das Signal ist gesetzt oder unauffällig.
  • Warnung: Ein empfohlener Schutz fehlt oder ist zu schwach, etwa ein Security-Header, eine CSP mit unsafe-inline, der HTTPS-Redirect, ein Cookie-Flag oder DMARC mit p=none.
  • Fehler: Ein grundlegendes Problem: kein HTTPS, ein ungültiges oder in unter 7 Tagen ablaufendes Zertifikat, ein offenes Verzeichnis-Listing, eine öffentlich erreichbare .git- oder .env-Datei, ein aktiver Debug-Modus oder ein geheimer Schlüssel im Quelltext.
  • Hinweis: Nur zur Einordnung, etwa fehlende COOP-, CORP- oder COEP-Header, kein CAA-Eintrag, externe Skripte ohne SRI oder eine fehlende security.txt.

Der Score ist der Anteil bestandener Prüfungen an allen bewerteten. Hinweise zählen nicht mit.

Daraus ergibt sich die Note: A ab 90 von 100 Punkten, B ab 80, C ab 65, D ab 50, darunter F. Schon ein einziger Fehler begrenzt die Note auf C.

Report und Port-Checksofort + E-Mail

Ergebnis sofort. Für den vollständigen Report mit allen Detail-Findings brauchen wir nur deine E-Mail-Adresse.

  • Sofort sichtbar: dein Score und die Zahl der bestandenen Prüfungen, Warnungen, Fehler und Hinweise.
  • Mit deiner E-Mail: jede einzelne Prüfung mit Befund und Empfehlung, dazu der komplette Report per Mail.
  • Port-Check: 16 übliche Ports von Web über SSH, FTP und Mail bis MySQL, PostgreSQL und Remote Desktop. Wir bauen nur eine Verbindung auf, ohne Login und ohne Anfrage an den Dienst.
  • Das Port-Ergebnis bekommst du nur, wenn deine E-Mail-Adresse zur geprüften Domain gehört: in der Mail und, sobald du den Code aus der Mail eingibst, auch im Report. In den Score fließt es nicht ein.
Was der Check nicht abdecktGrenzen
  • Nur die Startseite: Unterseiten, Login-Bereiche, Checkout und APIs sehen wir nicht.
  • Keine Schwachstellensuche: CMS-, Shop- und Plugin-Versionen gleichen wir nicht mit bekannten Sicherheitslücken ab.
  • Header auf typische Schwächen: unsafe-inline, unsafe-eval, Platzhalter und eine kurze HSTS-Laufzeit erkennen wir. Eine vollständige Analyse deiner CSP ist das nicht.
  • E-Mail nur per DNS: SPF und DMARC lesen wir aus, DKIM nur unter drei gängigen Selektoren. DNSSEC und die tatsächliche Zustellung prüfen wir nicht.

Ein guter Score heißt: Die Grundkonfiguration stimmt. Was dahinter liegt, zeigt erst ein Blick in die Anwendung selbst.

Vom Befund zur Lösung

Die meisten Befunde sind Konfiguration, kein Umbau. Je nachdem, wer bei dir Server und DNS betreut, gibt es drei Wege.

Für Admins, Hoster und interne IT

Der Report nennt zu jedem Befund die Empfehlung. Header, Redirects und DNS-Einträge sind oft nur wenige Zeilen Konfiguration. Danach prüfst du einfach erneut.

Website prüfen
Profilbild von Slawa Ditzel, Executive Partner

Slawa Ditzel

Executive Partner

Antwort innerhalb eines Werktags

  1. Du schickst den Report oder die Domain
  2. Wir sagen, welche Befunde wirklich zählen
  3. Du bekommst Aufwand und den passenden Weg

30 Minuten · kein Pitch · ehrliche Einschätzung

Auch rechtlich zählt das: Art. 32 DSGVO verlangt technische Maßnahmen nach dem Stand der Technik, um personenbezogene Daten zu schützen. Verschlüsselte Verbindungen und eine gepflegte Server-Konfiguration gehören dazu. SPF, DKIM und DMARC schützen zusätzlich deine Marke vor Phishing in deinem Namen.

Passend dazu: Shopware-Audit · Legacy-Check · BFSG-Check · Hosting und Skalierung

Häufige Fragen zum Security Check

Deine Frage ist nicht dabei? Frag uns direkt

Ist das ein Penetrationstest?
Nein. Ein Penetrationstest greift eine Anwendung gezielt an: Logins, Schnittstellen, Rechte, Eingaben. Der Security Check liest nur, was deine Website jedem Besucher ausliefert, und bewertet die Konfiguration. Keine Exploits, kein Angriff auf Zugangsdaten. Dazu kommt ein reiner Verbindungstest auf 16 übliche Ports, dessen Ergebnis nur an eine E-Mail-Adresse der geprüften Domain geht.
Was bedeutet meine Note?
Die Note fasst den Score zusammen: A ab 90 von 100 Punkten, B ab 80, C ab 65, D ab 50, darunter F. Der Score ist der Anteil bestandener Prüfungen, Hinweise zählen nicht mit. Ein einzelner Fehler, etwa fehlendes HTTPS oder eine offen erreichbare .env-Datei, begrenzt die Note auf C, auch wenn alles andere stimmt.
Brauche ich Zugangsdaten?
Nein. Wir rufen nur öffentliche Adressen ab: deine Startseite per HTTPS und HTTP, robots.txt und /.well-known/security.txt. Bei /.git/HEAD, /.git/config, /.env und /.DS_Store werten wir nur Statuscode und Dateityp aus, den Inhalt lesen wir nicht. Bei /server-status und /phpinfo.php prüfen wir nur, ob die typische Seitenüberschrift vorkommt, und speichern nichts davon. Dazu kommen eine zweite Anfrage an die Startseite mit fremdem Origin-Header (CORS), eine TRACE-Anfrage an die Startseite, eine TLS-Verbindung auf Port 443 und öffentliche DNS-Abfragen für CAA, SPF, DMARC und DKIM.
Brauche ich nach einem guten Ergebnis noch einen Penetrationstest?
Ein gutes Ergebnis zeigt, dass die öffentliche Grundkonfiguration stimmt. Logins, Schnittstellen und Geschäftslogik prüft nur ein Penetrationstest. Für Shops, Kundenportale und Anwendungen mit sensiblen Daten empfehlen wir ihn zusätzlich.
Warum eine E-Mail?
Score und die Zahl der Warnungen und Fehler siehst du sofort. Welche Punkte das genau sind und was du dagegen tun kannst, schaltest du mit deiner E-Mail frei. Den kompletten Report mit kurzer Einordnung schicken wir dir zusätzlich per Mail. Innerhalb eines Werktags meldet sich einmal ein Mensch aus dem Team, ohne Verkaufsdruck.
Kann ich nach einem Fix erneut prüfen?
Ja. Starte den Check einfach noch einmal, das Ergebnis ist sofort da. Pro Domain sind bis zu 20 Checks pro Stunde möglich. Sitzt ein CDN mit Seiten-Cache vor deiner Website, kann es kurz noch die alte Antwort ausliefern.
Was ist ein DMARC-Check?
Ein DMARC-Check liest den DMARC-Eintrag deiner Domain aus dem DNS und prüft, ob er gesetzt ist und wie streng er greift. Erst mit „quarantine“ oder „reject“ werden gefälschte Mails in deinem Namen tatsächlich aussortiert. Unser Security Check prüft DMARC zusammen mit SPF und DKIM.
Kann ich auch fremde Websites prüfen?
Den Web-Check ja, er nutzt nur öffentlich erreichbare Adressen und DNS-Einträge. Das Port-Ergebnis schicken wir aber nur an eine E-Mail-Adresse der geprüften Domain, für deine-domain.de also zum Beispiel an info@deine-domain.de. Im Report erscheint es erst, wenn du den Code aus dieser Mail eingibst.
Was passiert mit meinen Daten?
Ohne Freischaltung speichern wir weder URL noch Ergebnis in unserem CRM. Erst beim Freischalten legen wir dort deine E-Mail, freiwillige Angaben wie Name und Telefon und das Ergebnis ab. Hast du Statistik-Cookies erlaubt, erfasst unsere Produktanalyse, welche URL du geprüft hast. Details siehe Datenschutzerklärung.
Werden private Netze gescannt?
Nein. Private, Link-Local-, Loopback- und Cloud-Metadaten-Adressen blockieren wir, auch wenn eine Weiterleitung dorthin zeigt. Alle Abfragen gehen an die einmal geprüfte öffentliche IP.

Sicherheitslücken schließen lassen

Schick uns deinen Report oder die Domain. Wir sagen dir, welche Befunde zählen, was die Behebung kostet und wer sie übernimmt.

Profilbild von Slawa Ditzel, Executive Partner
Slawa Ditzel
Executive Partner