Sicherheit
Prüfen Sie die Sicherheitskonfiguration Ihrer Website
Jede Website erzählt der Außenwelt, wie sie eingerichtet ist, lange bevor jemand ein Passwort eintippt. Die Header, die sie sendet, die TLS-Versionen, denen sie zustimmt, die Attribute auf ihren Cookies, die Einträge ihrer DNS-Zone und die Versionsnummern, die ihr Server von sich aus nennt: All das liest, wer höflich fragt. VeriFixScan fragt höflich, liest die Antwort und meldet die vorgefundene Konfiguration.
Was sich von außen lesen lässt — und was nicht
Dies ist eine Prüfung der Konfiguration, keine Jagd auf Schwachstellen. Alles Gemeldete stammt aus gewöhnlichen Anfragen, wie sie jeder Browser stellt: Antwort-Header, der TLS-Handshake, Set-Cookie-Zeilen, öffentliche DNS-Antworten und veröffentlichte Dateien. Nichts wird eingeschleust, nichts gefuzzt, kein Formular abgeschickt und keine Anmeldung versucht. Diese Grenze ist keine Folge des Scan-Budgets, sondern die gewollte Form des Werkzeugs.
Header sind der Teil, den Browser wirklich durchsetzen
Eine Content-Security-Policy entscheidet, welche Ressourcen ein Browser lädt; Framing-Regeln entscheiden, ob Ihre Seiten in fremden eingebettet werden dürfen; eine Referrer-Richtlinie entscheidet, wie viel Ihrer URLs an Dritte abfließt. Das sind Anweisungen, die der Browser stellvertretend für Ihre Besucher befolgt — ein fehlender Header ist damit eine echte Lücke und keine Stilfrage. Jeder erscheint als gesendet oder fehlend, mit dem beobachteten Wert.
TLS ist keine Ja-oder-Nein-Antwort
Ein Schloss in der Adressleiste besagt, dass ein Handshake gelungen ist. Es besagt nichts darüber, welche Protokollversionen der Server noch annimmt, ob das Zertifikat sowohl den Apex als auch den www-Hostnamen abdeckt, oder ob überhaupt ein Strict-Transport-Security gesendet wird. Das sind getrennte Antworten, und eine Website kann die erste bestehen und die übrigen verfehlen, ohne dass sichtbar etwas schiefgeht.
Cookies tragen die Sitzung, die Attribute entscheiden, wer sie liest
Ein sitzungsartiges Cookie ohne HttpOnly liest jedes Skript auf der Seite mit. Ohne Secure reist es womöglich über unverschlüsseltes HTTP. Mit fehlendem oder ungültigem SameSite verhält es sich je nach Browser und Version anders. Die tatsächlich gesetzten Attribute erscheinen so, wie sie beobachtet wurden — getrennt vom Cookie-Inventar, das der Scanner erstellt.
Die Zone, die Mail und was der Server von sich aus preisgibt
DNSSEC-Signierung, eine veröffentlichte Sicherheitskontakt-Richtlinie, die Anfälligkeit einer Domain ohne Mail-Dienst für gefälschte Absender, und die exakten Softwareversionen, die ein Server in einem Header nennt: Nichts davon zeigt sich in einem Browserfenster, alles davon in einer Anfrage. Sie vervollständigen das Bild, das die Konfiguration jedem Betrachter bietet.
Die gelesene Sicherheitskonfiguration
Jeder dieser Punkte ist eine echte Prüfung, und jede meldet, was die Antwort wirklich enthielt, statt was erwartet wurde.
HSTS
Die Website sendet den Strict-Transport-Security-Header.
Content-Security-Policy
Eine Content Security Policy beschränkt, welche Ressourcen der Browser laden darf.
Clickjacking-Schutz
Das Einbetten der Website ist beschränkt (X-Frame-Options oder CSP frame-ancestors).
TLS-Protokollversionen
Welche TLS-Versionen der Server annimmt (TLS 1.0/1.1 veraltet, 1.2/1.3 erwartet).
Zertifikatsabdeckung der Hostnamen
Apex und www-Hostname schließen beide einen HTTPS-Handshake ab.
Secure-Attribut
Sitzungsartige Cookies und SameSite=None-Cookies tragen das Attribut Secure.
HttpOnly-Attribut
Cookies mit Bezug zu Sitzung oder Anmeldung tragen das Attribut HttpOnly.
SameSite-Attribut
Beobachtete SameSite-Werte auf Cookies: Strict, Lax, None, ungültig oder fehlend.
Preisgabe von Server-Informationen
Der Server nennt keine detaillierten Softwareversionen.
DNSSEC
Die Zone ist mit DNSSEC signiert (ein DS-Eintrag existiert).
Web Application Firewall
WAF-Erkennung beschränkt auf herstellerspezifische öffentliche Signaturen. Es wird nie eine Nutzlast gesendet.
security.txt
Eine Sicherheitskontakt-Richtlinie ist veröffentlicht.
Anfälligkeit für gefälschte Absender
Kombinierte Sicht auf SPF und DMARC bei einer Domain ohne Mail-Dienst.
VeriFixScan prüft die von außen beobachtbare Konfiguration. Es ist kein Penetrationstest, kein Schwachstellenscanner, kein Malware-Scanner und kein CVE-Scanner: Es sondiert keine Schwächen, sendet keine Nutzlast, schickt kein Formular ab und versucht keine Anmeldung. Ein sauberer Bericht bedeutet, dass die lesbaren Einstellungen stimmig wirken — nicht, dass Ihre Website unangreifbar wäre.
Geben Sie Ihre Website-Adresse ein, und VeriFixScan prüft sie sofort. Ohne Konto, ohne Installation, ohne Änderung an Ihrer Website.
Häufige Fragen
- Was leistet eine Sicherheitsprüfung für Websites?
- Sie liest die Konfiguration, die Ihre Website öffentlich zeigt — Antwort-Header, TLS-Handshake, Cookie-Attribute, DNS-Einträge und veröffentlichte Dateien — und meldet deren Inhalt. Das Ergebnis beschreibt, wie Ihre Website eingerichtet ist, von außen gesehen.
- Ist das ein Scan auf Sicherheitslücken?
- Nein. Nichts wird sondiert, eingeschleust oder gefuzzt, keine Nutzlast gesendet, kein Formular abgeschickt und keine Anmeldung versucht. VeriFixScan liest, was Ihr Server jeder gewöhnlichen Anfrage übergibt, und meldet genau das.
- Wie prüfe ich, ob meine Website sicher eingerichtet ist?
- Starten Sie einen Scan und lesen Sie die Sicherheitsbefunde. Sie benennen die gesendeten und die fehlenden Header, die noch angenommenen TLS-Versionen, die Attribute Ihrer Cookies und das, was Ihr Server über die eigene Software preisgibt.
- Versucht VeriFixScan, in meine Website einzudringen?
- Niemals. Es verhält sich wie ein höflicher Besucher: Es fordert Seiten an, liest die Antworten und hört dort auf. Es beachtet die robots.txt, umgeht keinen Bot-Schutz und besitzt bei Ihnen keine Zugangsdaten.
- Welche Sicherheits-Header sollte meine Website senden?
- Jene, die Browser stellvertretend für Ihre Besucher durchsetzen: eine Content-Security-Policy, eine Framing-Beschränkung, Strict-Transport-Security und eine Referrer-Richtlinie. Jeder erscheint als vorhanden oder fehlend, samt beobachtetem Wert.
- Werden Zertifikat und TLS-Version geprüft?
- Ja. Die noch angenommenen Protokollversionen erscheinen getrennt von der Frage, ob das Zertifikat Apex und www abdeckt — zwei verschiedene Antworten, die ein Schloss-Symbol nicht liefert.
- Kann es mir sagen, ob meine Website kompromittiert wurde?
- Nein. Eine Kompromittierung festzustellen verlangt den Blick in Code, Protokolle und gespeicherte Daten — nichts davon ist von außen lesbar. Hier geht es um Konfiguration, und eine gut eingerichtete Website kann dennoch übernommen worden sein.
- Sind die Sicherheitsbefunde im kostenlosen Scan enthalten?
- Der kostenlose Scan berichtet über die erreichte Stichprobe an Seiten, Sicherheitsbefunde eingeschlossen. Ein vollständiger Durchlauf deckt weit mehr der Website ab und damit mehr der wirklich ausgelieferten Cookies und Header.