Rudra Analyzer

Kostenloser Website-Sicherheits-Checker

Prüfen Sie, wie Ihre Website ihre Besucher schützt: HTTPS und die Weiterleitung von http auf https, das SSL/TLS-Zertifikat, die Werte Ihrer Sicherheits-Header, Cookie-Flags, CORS und gemischte Inhalte. Es ist eine passive, rein lesende Konfigurationsprüfung, die nur normale GET- und HEAD-Anfragen sendet – kein Penetrationstest.

Geben Sie eine Seite ein, zum Beispiel https://ihrewebsite.de oder https://ihrewebsite.de/preise.

Was dieses Tool prüft

  • HTTPS und Weiterleitungen

    Ob die Seite nach Weiterleitungen auf https:// landet, die Zwischenschritte und ob http://ihredomain/ mit einer dauerhaften Weiterleitung (301 oder 308) auf HTTPS antwortet.

  • SSL/TLS-Zertifikat

    Ob das Zertifikat vertrauenswürdig ist und zu Ihrer Domain passt, welche TLS-Version verwendet wird, wer es ausgestellt hat und in wie vielen Tagen es abläuft.

  • HSTS-Wert

    Der Strict-Transport-Security-Header wird ausgewertet, nicht nur erkannt: ein max-age von mindestens 180 Tagen, keine fehlerhaften Direktiven, includeSubDomains und ob ein preload-Flag durch die Einstellungen gedeckt ist, die die Preload-Liste verlangt.

  • Content-Security-Policy-Direktiven

    Jede Direktive wird gelesen: ob Skripte überhaupt eingeschränkt sind, 'unsafe-inline' (nicht markiert, wenn eine Nonce oder ein Hash verwendet wird), 'unsafe-eval', weit gefasste Quellen wie *, https: oder data: in script-src, object-src, base-uri und ob die Richtlinie nur Report-Only ist.

  • Clickjacking-Schutz

    X-Frame-Options (einschließlich ungültiger Werte und des veralteten ALLOW-FROM) oder eine CSP-Regel frame-ancestors, die nicht * oder nur ein Schema ist.

  • Weitere Schutz-Header

    X-Content-Type-Options muss genau nosniff lauten; Referrer-Policy wird auf unsafe-url und unbekannte Werte geprüft, Permissions-Policy auf offen gelassene Funktionen. Header zur Cross-Origin-Isolation werden zur Information aufgeführt.

  • Versionsangaben und Source Maps

    Server-, X-Powered-By-, X-AspNet-Version-, X-AspNetMvc-Version- und X-Generator-Header, die Versionsnummern verraten, sowie öffentliche Source Maps für bis zu drei Ihrer eigenen Skripte.

  • Cookie-Flags

    Von der Seitenantwort gesetzte Cookies, nur nach Name: Secure bei HTTPS, HttpOnly bei Cookies, deren Namen auf eine Sitzung oder ein Token hindeuten, SameSite=None ohne Secure, fehlendes SameSite und Cookies, die für eine übergeordnete Domain gelten.

  • CORS

    Eine zusätzliche Anfrage mit einem harmlosen, erfundenen Origin (https://rudra-audit.invalid), um zu sehen, ob Ihr Server jeden Origin zurückgibt – und ob er zusätzlich Anmeldedaten erlaubt, was die riskante Kombination ist.

  • Gemischte Inhalte

    Skripte, Stylesheets oder Frames über http:// auf einer HTTPS-Seite (aktive gemischte Inhalte) sowie Bilder oder Medien über http:// (passive).

  • security.txt

    Ob /.well-known/security.txt existiert und eine Contact-Zeile sowie ein Expires-Datum in der Zukunft enthält, damit Sicherheitsforscher wissen, wie sie Sie erreichen.

  • Technologien und sichtbare Angriffsfläche

    Frameworks und Dienste, die an Headern und HTML erkennbar sind, sowie Login-Formulare, in der Seite erwähnte API- oder Dokumentations-URLs und öffentliche Dateien wie robots.txt. Zur Kenntnis aufgeführt; kostet keine Punkte.

  • Clientseitige Muster (manuelle Prüfung)

    Inline-Event-Handler wie onclick und Skripte von Drittanbietern, die ohne Subresource Integrity geladen werden. Das sind Hinweise mit niedriger Priorität zur Prüfung, keine bestätigten Schwachstellen.

So funktioniert die Prüfung

Wir senden eine normale GET-Anfrage an Ihre Seite, folgen etwaigen Weiterleitungen und lesen die Antwort: Header-Werte, die gesetzten Cookies (nur Namen und Flags) und das HTML. Daneben stellen wir eine kleine, feste Zahl rein lesender Anfragen: eine TLS-Verbindung zur Prüfung des Zertifikats, ein GET mit harmlosem Test-Origin für CORS, eine Anfrage an http://ihredomain/, um die Weiterleitung zu sehen, die freigegebenen Dateien /.well-known/security.txt, robots.txt, sitemap.xml, humans.txt und das Manifest, auf das Ihre Seite verlinkt, sowie – für bis zu drei Ihrer eigenen Skripte – das Dateiende plus eine HEAD-Anfrage für die dort genannte Source Map.

Es wird nichts abgeschickt, es werden keine Anmeldedaten gesendet, keine Angriffs-Payloads verwendet und keine Pfade erraten. Anfragen an private oder interne Netzwerkadressen werden blockiert. Antwortet die Seite mit einem Serverfehler (5xx), analysieren wir ihre Header nicht, weil Fehlerseiten oft von der echten Website abweichen; diese Prüfungen werden als nicht ausgeführt statt als nicht bestanden markiert.

Die Bewertung beginnt bei 100, und jeder Abzug steht im Bericht. Kein HTTPS kostet 40 Punkte, ein ungültiges oder abgelaufenes Zertifikat 40, eine fehlgeschlagene TLS-Verbindung 30, CORS, das jedem Origin mit Anmeldedaten vertraut, 25, ein fehlender HSTS-Header 15 und eine fehlende CSP 12. Schwächere Einstellungen kosten weniger – zum Beispiel keine Weiterleitung von http auf https 10, aktive gemischte Inhalte 8, eine CSP nur im Report-Only-Modus 8, 'unsafe-inline'-Skripte 6, Cookies ohne Secure 6 und ein kurzes HSTS max-age 5. Viele informative Befunde, etwa eine fehlende security.txt, kosten nichts, und dasselbe Problem wird nie doppelt abgezogen.

Nachweise, die Sie sehen

Jeder Header wird mit seinem tatsächlichen Wert und einer verständlichen Bewertung (gut, schwach oder fehlt) angezeigt; CSP-Befunde enthalten die ausgewertete Direktiven-Tabelle; Cookie-Befunde listen Cookie-Namen und ihre Flags auf, nie Werte; das CORS-Ergebnis zeigt den Test-Origin und die Antwort. Jeder Befund nennt, was wir erwartet haben, die betreffende URL, wie sicher die Prüfung ist und die Quelle – die HTTP-Antwort, das HTML oder die TLS-Verbindung.

Was dieses Tool nicht prüft

  • Es ist kein Penetrationstest

    Keine Ausnutzung, keine Angriffs-Payloads, kein Brute-Forcing und kein Erraten versteckter Pfade. Es liest die Konfiguration, die jeder Browser erhält.

  • Seiten hinter einem Login

    Wir melden uns nie an und senden keine Anmeldedaten, daher werden geschützte Seiten, Admin-Bereiche und Kontoeinstellungen nicht getestet.

  • Ihr Code und Ihre Abhängigkeiten

    Keine Prüfung des serverseitigen Codes und kein Schwachstellenscan Ihres CMS, Ihrer Plugins, Bibliotheken oder Serversoftware.

  • Malware oder eine kompromittierte Website

    Es sucht nicht nach Malware, Verunstaltung, eingeschleustem Spam oder geleakten Konten.

  • Jedes Cookie Ihrer Website

    Erfasst werden nur Cookies aus der Antwort der Seite selbst – nicht solche, die später per JavaScript, von anderen Seiten oder von Drittanbietern hinzugefügt werden. Cookie-Werte werden nie gelesen.

  • Wie sich Ihre Formulare verhalten

    Formulare werden erfasst, aber nie abgeschickt, daher lassen sich serverseitige Validierung, CSRF-Schutz und Ratenbegrenzung nicht testen.

Häufige Probleme, die wir finden

  • HSTS fehlt oder ist zu kurz

    Sehr verbreitet, selbst auf Websites, die alles auf HTTPS weiterleiten – und ein max-age von wenigen Minuten, übrig geblieben aus Tests, bietet fast keinen Schutz.

  • Keine CSP oder eine, die zu viel erlaubt

    Der am häufigsten fehlende Header. Ist er vorhanden, heben 'unsafe-inline', 'unsafe-eval' oder ein * in script-src oft den Großteil seines Schutzes auf.

  • Kein Clickjacking-Schutz

    Weder X-Frame-Options noch eine frame-ancestors-Regel.

  • Bald ablaufende Zertifikate

    Meist, weil die automatische Verlängerung nach einer Server- oder DNS-Änderung nicht mehr funktioniert.

  • Sichtbare Serverversion

    Header wie „Server: Apache/2.4.41“ oder „X-Powered-By: PHP/7.4“, die Angreifern verraten, wonach sie suchen müssen.

  • HTTP ohne Weiterleitung

    http://ihredomain/ liefert weiterhin Seiten aus oder leitet nur vorübergehend (302) weiter, sodass Besucher, die nur die Domain eingeben, unverschlüsselt surfen können.

  • Sitzungs-Cookies ohne Secure oder HttpOnly

    Login- oder Sitzungs-Cookies, die Skripte lesen können oder die über unverschlüsseltes HTTP gesendet werden könnten.

So beheben Sie sie

  1. Header dort setzen, wo Ihre Website ausgeliefert wird

    Header werden in Ihrem Webserver (Nginx add_header, Apache Header set), Ihrem CDN oder in den Einstellungen bzw. der Header-Datei Ihres Hosters konfiguriert. Führen Sie die Prüfung erneut aus, um den Wert zu bestätigen, der tatsächlich beim Browser ankommt.

  2. HSTS aktivieren, sobald HTTPS überall funktioniert

    Verwenden Sie Strict-Transport-Security: max-age=31536000 (180 Tage ist das Minimum, das wir akzeptieren). Fügen Sie includeSubDomains nur hinzu, wenn jede Subdomain HTTPS unterstützt, und preload zuletzt.

  3. CSP schrittweise verschärfen

    Beginnen Sie mit Content-Security-Policy-Report-Only und setzen Sie die Richtlinie dann durch. Ersetzen Sie 'unsafe-inline' durch Nonces oder Hashes, entfernen Sie 'unsafe-eval', nennen Sie genaue Skript-Origins statt * oder https: und fügen Sie object-src 'none' und base-uri 'self' hinzu.

  4. Die einfachen Header hinzufügen

    X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin und X-Frame-Options: DENY (oder SAMEORIGIN) machen selten etwas kaputt.

  5. Zertifikatserneuerung und Weiterleitungen automatisieren

    Nutzen Sie verwaltete Zertifikate oder Let's Encrypt mit automatischer Erneuerung und leiten Sie jede http://-Anfrage mit 301 oder 308 auf dieselbe https://-URL weiter.

  6. Versionsnummern verbergen

    Schalten Sie Versionsangaben ab (zum Beispiel server_tokens off in Nginx, expose_php = Off in PHP) und veröffentlichen Sie Source Maps in der Produktion nur, wenn Sie das wirklich wollen.

  7. Cookies mit Flags versehen

    Geben Sie auf einer HTTPS-Website jedem Cookie Secure, ergänzen Sie HttpOnly bei Sitzungs- und Login-Cookies und setzen Sie SameSite=Lax (oder Strict) ausdrücklich. SameSite=None erfordert immer Secure.

Häufig gestellte Fragen

Ist das ein Penetrationstest oder ein Schwachstellenscan?

Nein. Er liest die Konfiguration, die jeder Browser erhält – HTTPS, das Zertifikat, Header-Werte, Cookie-Flags, CORS – und verwendet nur normale GET- und HEAD-Anfragen. Er versucht nicht, Schwachstellen zu finden oder auszunutzen. Dafür beauftragen Sie einen qualifizierten Sicherheitstester und erteilen ihm die Erlaubnis schriftlich.

Kann es mir sagen, ob meine Website gehackt wurde?

Nein. Er sucht nicht nach Malware, verunstalteten Seiten oder kompromittierten Konten. Eine gute Bewertung bedeutet, dass die sichtbaren Teile Ihrer Transport- und Browsersicherheit gut konfiguriert sind – nicht, dass die Website in jeder Hinsicht sicher ist.

Beurteilt es, wie gut meine Header sind?

Ja, bei den wichtigsten. HSTS wird auf ein max-age von mindestens 180 Tagen und fehlerhafte Direktiven geprüft; CSP wird Direktive für Direktive auf 'unsafe-inline', 'unsafe-eval', weit gefasste Skriptquellen und fehlendes object-src oder base-uri ausgewertet; auch die Werte von X-Frame-Options, X-Content-Type-Options und Referrer-Policy werden validiert.

Warum wird HSTS auf meiner HTTP-Website nicht geprüft?

HSTS wirkt nur über HTTPS. Wenn Ihre Website kein HTTPS nutzt, ist das das größere Problem – und wird stattdessen gemeldet.

Können Sicherheits-Header meine Website kaputtmachen?

Die meisten Header lassen sich gefahrlos hinzufügen. Eine Content-Security-Policy kann Skripte, Styles oder Einbettungen blockieren, auf die Ihre Website angewiesen ist – testen Sie sie daher zuerst im Report-Only-Modus. Secure oder SameSite bei Cookies kann Anmeldungen über mehrere Domains beeinflussen, testen Sie danach also die Anmeldung.

Ist die CORS-Prüfung für meine Website sicher?

Ja. Es ist eine gewöhnliche GET-Anfrage mit einem Origin-Header für eine Domain, die es nicht geben kann (rudra-audit.invalid). Es werden keine Cookies oder Anmeldedaten gesendet und nichts geändert; wir lesen nur, welche CORS-Header zurückkommen.

Warum sind manche Befunde zur manuellen Prüfung markiert?

Muster wie Inline-onclick-Handler oder Skripte ohne Subresource Integrity können je nach Kontext harmlos oder riskant sein. Wir markieren sie mit geringer Sicherheit, damit Sie entscheiden können, statt sie als bestätigte Probleme darzustellen.

Hilfreiche Ratgeber

Ähnliche kostenlose Tools

Soll lieber jemand anderes es beheben?

Diese Prüfungen sind kostenlos, ebenso die Ratgeber. Wenn ein Mensch die Änderungen vornehmen soll, bietet unser Team kostenpflichtige Hilfe an.

Professionelle Hilfsangebote ansehenSo testen und bewerten wirAlle kostenlosen Tools