# Website-Sicherheitscheck in unter einer Minute. Website-Sicherheitscheck für Websites kleiner Unternehmen. Prüfen Sie HTTPS, Sicherheits-Header, E-Mail-Einträge und Tracker und laden Sie ein PDF mit den Lösungen herunter. ## Was prüft ein Website-Sicherheitscheck? Der Scan führt 28 Prüfungen auf Ihrer Startseite durch. Er deckt HTTPS und Weiterleitungen, Sicherheits-Header, Cookies, E-Mail- und DNS-Einträge, Skripte von Drittanbietern, Tracker und veraltete Bibliotheken ab. Jedes Ergebnis sagt, was zu beheben ist, was Sie sich ansehen sollten und was wir nicht prüfen konnten. ### HTTPS-Verbindung Antwortet die Website verschlüsselt und weist sie Browser an, künftig HTTPS zu verwenden? ### Schutz im Browser Kann die Website fremde Skripte blockieren, das Einbetten durch andere Websites verhindern und Browser daran hindern, Dateitypen zu raten? ### Cookies, Tracker und Software Wir prüfen Cookie-Einstellungen, Tracker, die laden, bevor Besucher zustimmen, veraltete JavaScript-Bibliotheken und Softwareversionen, die die Website preisgibt. ## Mehr aus Ihrem Website-Sicherheitscheck machen ### Was ein Website-Sicherheitscheck zeigt Ein Website-Sicherheitscheck zeigt die Einstellungen, die Ihre Startseite an jeden Besucher sendet. Wir prüfen HTTPS, Sicherheits-Header, Cookies, E-Mail-Einträge, Tracker und die Software, die die Website preisgibt. Nutzen Sie Ihren Website-Sicherheitscheck, um Fragen für Ihren Entwickler vorzubereiten und vor Änderungen einen datierten Stand festzuhalten. ### Ergebnisse des Website-Sicherheitscheck verstehen Ihr Website-Sicherheitscheck ordnet die Ergebnisse in dringende Prüfungen für den Hoster, Einstellungen zum Beheben und Punkte, die von Ihrer Website abhängen. Ein fehlender optionaler Header ist kein Zeichen für einen Angriff. Die Website-Bewertung in einem Website-Sicherheitscheck reicht von 0 bis 100 und zählt bestandene Prüfungen. Die Farben zeigen, was Sie zuerst ansehen sollten. ### Vor und nach dem Website-Sicherheitscheck Führen Sie einen Website-Sicherheitscheck durch, bevor Sie Hosting oder Sicherheitseinstellungen ändern, damit Sie einen Vergleich haben. Prüfen Sie Zahlungsseiten, Logins und eingebettete Dienste, bevor Sie Regeln verschärfen. Danach machen Sie einen neuen Website-Sicherheitscheck, vergleichen ihn mit dem alten Bericht und testen die Website in einem echten Browser. Halten Sie Software-Updates und Kontosicherheit in Ihrer regelmäßigen Wartung. ### Website-Sicherheitscheck mit dem Entwickler teilen Ein Website-Sicherheitscheck lässt sich leichter umsetzen, wenn die Person, die die Arbeit macht, ihn sehen kann. Laden Sie das PDF herunter oder senden Sie Ihrem Entwickler den Link. Jeder Website-Sicherheitscheck zeigt, wann er durchgeführt wurde. Der Eigentümer der Website kann den Bericht außerdem veröffentlichen, nachdem er nachgewiesen hat, dass er die Website kontrolliert. ## Fragen zur Sicherheit Ihrer Website ### Beweist ein Website-Sicherheitscheck, dass meine Website sicher ist? Nein. Geprüft wird eine Auswahl öffentlicher Einstellungen. Damit lassen sich nicht alle Schwachstellen, Malware, Programmierfehler oder gehackten Zugänge finden. Ein vollständiges Sicherheitsaudit geht viel weiter. ### Beeinflusst der Website-Sicherheitscheck meine Website? Kaum. Der Scan fragt Ihre DNS-Einträge ab, ruft die Startseite über HTTPS und einfaches HTTP auf, folgt bis zu fünf Weiterleitungen, liest security.txt und lädt die Startseite einmal in einem Cloud-Browser. Er besucht keine anderen Seiten, sendet keine Formulare, meldet sich nicht an und versucht keine Angriffe. Blockiert Ihre Website den Scan, erhalten Sie ein unvollständiges Ergebnis. ### Warum ist der Website-Sicherheitscheck auf zwei Prüfungen täglich begrenzt? Das Limit hält das Tool kostenlos und vermeidet unnötigen Traffic auf Websites. ### Was bedeuten die Farben im Website-Sicherheitscheck? Rot heißt, Ihr Hoster sollte etwas dringend prüfen, etwa eine alte PHP-Version mit einer bekannten kritischen Lücke. Orange heißt, eine Einstellung sollte behoben werden. Blau heißt, ein genauerer Blick lohnt sich. Grün heißt, die Prüfung ist bestanden. Grau heißt, wir konnten es nicht prüfen. Keine dieser Farben bedeutet, dass Ihre Website gehackt wurde. ### Erkennt ein Website-Sicherheitscheck PHP2Shell? Er kann eine PHP-Version melden, die älter ist als die korrigierten Versionen. Versions-Header können falsch, verborgen oder verändert sein, und manche Hoster patchen ältere Versionen. Lassen Sie Ihren Hoster die installierte PHP-Version und Patches bestätigen. Wir senden nie Angriffsanfragen. Ein fehlender PHP-Header heißt nicht, dass PHP fehlt oder gepatcht ist. ### Warum meldet der Website-Sicherheitscheck Software-Header? Versionsangaben machen es leichter, Websites mit verwundbarer Software zu finden. Entfernen Sie sie, wo es geht. Das Verbergen behebt nichts, halten Sie also die Software selbst aktuell. ### Was folgt nach einem Website-Sicherheitscheck? Beginnen Sie mit den roten Punkten und gehen Sie dann die orangen mit Ihrem Entwickler oder Hoster durch. Testen Sie Header-Änderungen vor dem Livegang, denn strenge Regeln können Zahlungen, Formulare und eingebettete Inhalte stören. Laden Sie das PDF herunter, um die Ergebnisse zu teilen. Mecanik Dev hilft bei der Wahl der richtigen Lösungen und setzt sie um. ### Sind meine Website-Sicherheitscheck-Ergebnisse öffentlich? Nein. Scans sind privat. Nur der Eigentümer einer Website kann ihren Bericht veröffentlichen, nachdem er mit einem DNS-Eintrag oder einer Datei nachgewiesen hat, dass er die Website kontrolliert. Sie können trotzdem einen privaten Link oder das PDF teilen. Konto oder E-Mail sind nicht nötig. ## Diese Prüfungen enthält Ihr Bericht ### Verschlüsselte Verbindung HTTPS verschlüsselt die Daten zwischen der Website und ihren Besuchern. Das zeigt, dass der Scanner sicher verbunden war. Der Rest der Website wird damit nicht getestet. ### Einfaches HTTP auf HTTPS umleiten Wer die Adresse ohne https:// eingibt, sollte direkt zur sicheren Website kommen. HSTS hält den Browser danach bei HTTPS. ### Besucher auf HTTPS halten Setzen Sie Strict-Transport-Security mit einem max-age von mindestens sechs Monaten. Prüfen Sie Ihre Subdomains, bevor Sie includeSubDomains oder preload hinzufügen. ### Ausführbare Inhalte begrenzen Content-Security-Policy legt fest, welche Skripte und Inhalte die Seite laden darf. Die richtigen Regeln hängen von der Website ab, und eine fehlende Richtlinie ist für sich keine Schwachstelle. Setzt die Seite die Richtlinie im HTML, liest die Browserprüfung sie aus. Report-only-Richtlinien blockieren nichts. ### Irreführende Einbettungen verhindern Nutzen Sie CSP frame-ancestors oder X-Frame-Options und erlauben Sie nur Websites, die Ihre Seiten wirklich einbetten müssen. ### Dateityp-Erkennung begrenzen Setzen Sie X-Content-Type-Options auf nosniff, damit Browser jede Datei als den Typ behandeln, den der Server angibt. ### Weitergegebene Daten begrenzen Eine ausdrückliche Referrer-Policy macht das Verhalten klar. Moderne Browser begrenzen das bereits standardmäßig, ein fehlender Header heißt also nicht, dass Daten abfließen. ### Sensible Browserfunktionen begrenzen Permissions-Policy kann Kamera, Mikrofon und Standort für Ihre Website abschalten. Die richtigen Einstellungen hängen davon ab, was die Website tut. ### Offengelegte X-Powered-By-Daten Entfernen Sie Laufzeitangaben, wo es geht. Das erschwert das Erkennen der Software, Updates bleiben aber trotzdem nötig. ### Offengelegte Serverversion Bitten Sie Ihren Hoster, Versionsnummern auszublenden und den Server aktuell zu halten. Ein Servername ohne Version ist in Ordnung. ### PHP-Patchstatus PHP2Shell ist der Name für zwei kritische Lücken in PHP selbst. Der Header meldet nur eine Version, die falsch sein kann oder Korrekturen Ihres Hosters nicht zeigt. Lassen Sie Ihren Hoster die installierte Version mit den aktuellen PHP-Hinweisen abgleichen. Das Verbergen des Headers behebt nichts. ### Cookies nur über HTTPS Secure bedeutet, dass das Cookie nur über HTTPS gesendet wird. Wir sehen nur Cookies aus der Antwort der Startseite. Cookies nach dem Login oder aus Skripten sind nicht erfasst, und Cookie-Werte erscheinen nie in Ihrem Bericht. ### Schutz von Sitzungscookies HttpOnly verhindert, dass Skripte auf der Seite das Cookie lesen. Wir erkennen Sitzungs-Cookies am Namen, lassen Sie es daher von Ihrem Entwickler bestätigen. ### Regeln für websiteübergreifende Cookies SameSite legt fest, wann Cookies bei Anfragen von anderen Websites mitgesendet werden. None kann für manche Integrationen richtig sein, und Browser setzen einen Standard, wenn der Wert fehlt. ### Websiteübergreifender Zugriff CORS wird oft für APIs und geteilte Dateien gebraucht. Ein Platzhalter allein legt keine privaten Daten offen. Diese Prüfung der Startseite kann nicht erkennen, ob eine API jedem Ursprung vertraut. ### Isolation von Browserfenstern COOP trennt die Seite von Fenstern, die andere Websites geöffnet haben. Zahlungs- und Login-Popups brauchen eventuell eine lockerere Einstellung. Ohne COOP ist die Website nicht automatisch angreifbar. ### Einbettung von Ressourcen Cross-Origin-Resource-Policy legt fest, welche Websites Ihre Dateien einbetten dürfen. Öffentliche Bilder und geteilte Dateien müssen eventuell offen bleiben. Die meisten Seiten brauchen das nicht. ### Absenderrichtlinie für E-Mails (SPF) SPF hilft Mailservern, gefälschte E-Mails im Namen Ihrer Domain abzulehnen. Sendet die Domain nie E-Mails, veröffentlichen Sie v=spf1 -all. Wir prüfen die Hauptdomain. ### Schutz vor E-Mail-Fälschung (DMARC) DMARC sagt Mailservern, was mit E-Mails passieren soll, die SPF und DKIM nicht bestehen. Beginnen Sie im Beobachtungsmodus, lesen Sie die Berichte und wechseln Sie dann zu quarantine oder reject. ### Regeln für Zertifizierungsstellen (CAA) CAA-Einträge nennen die Zertifizierungsstellen, die für die Domain Zertifikate ausstellen dürfen. Sie verringern das Risiko eines versehentlich ausgestellten Zertifikats. Nehmen Sie jeden Anbieter auf, den Sie nutzen. ### Signiertes DNS (DNSSEC) Mit DNSSEC erkennen Resolver gefälschte DNS-Antworten. Schalten Sie es bei DNS-Anbieter und Registrar gemeinsam ein, denn eine fehlerhafte Einrichtung kann die Domain lahmlegen. ### Sicherheitskontakt (security.txt) Veröffentlichen Sie /.well-known/security.txt mit Contact und Expires, damit Menschen, die ein Problem finden, wissen, wie sie Sie erreichen. ### Unsichere Seitenressourcen Unsichere Dateien können auf dem Weg zum Besucher verändert werden, und Browser blockieren sie eventuell, was die Seite beschädigt. Stellen Sie diese Adressen auf HTTPS um. Wir haben nur die Startseite geprüft. ### Dienste von Drittanbietern Jedes externe Skript und jeder externe Dienst kann Ihre Besucher sehen und die Seite verändern. Halten Sie die Liste kurz, entfernen Sie, was Sie nicht mehr nutzen, und prüfen Sie, was jeder Anbieter erhält. Externe Dienste sind für sich keine Schwachstelle. ### Tracking vor der Einwilligung Datenschutzgesetze wie die DSGVO verlangen in der Regel eine Einwilligung vor nicht notwendigem Tracking. Der Scanner lädt die Seite einmal von unseren Servern und akzeptiert nichts. Einwilligungstools können je nach Land anders reagieren, prüfen Sie also auch Ihre eigene Einrichtung. ### Veraltete JavaScript-Bibliotheken Wir erkennen jQuery, jQuery UI, Bootstrap, AngularJS, Lodash und Moment.js, wenn sie ihre Version zeigen. Aktualisieren Sie die betroffene Bibliothek oder das Theme bzw. Plugin, das sie enthält, und testen Sie dann die Website. ### Integritätsprüfung für Skripte Mit Subresource Integrity lehnen Browser eine veränderte Kopie einer Skriptdatei ab. Das funktioniert für versionierte Dateien aus einem CDN. Für Skripte, die sich absichtlich ändern, etwa Tag-Manager, passt es nicht. ### Version der Website-Plattform Ein Generator-Tag mit Versionsnummer macht die Website leichter zum Ziel automatisierter Angriffe. Entfernen Sie es, wo es geht, und halten Sie Plattform, Themes und Plugins aktuell. Das Verbergen der Version behebt nichts. ## Datenschutzhinweis Um Missbrauch zu verhindern und Beschwerden oder rechtliche Anfragen zu beantworten, führt Mecanik Dev Ltd ein Protokoll über jeden Scan. Es enthält die Website, den Zeitpunkt, die Version des Hinweises, Ihre IP-Adresse, Ihre Browser- und Geräteangaben und Ihren ungefähren Standort anhand Ihrer IP-Adresse. Wir bewahren diese Daten 30 Tage auf und löschen sie dann. Wir verwenden sie nicht für Marketing und geben sie nur weiter, wenn das Gesetz es verlangt. Unser Hosting- und Sicherheitsanbieter verarbeitet Ihre IP-Adresse, um den Dienst und die Bot-Prüfung bereitzustellen, und führt eigene Protokolle. Die Zustimmung zu einem Scan ist keine Zustimmung zu Werbung. Ihr Browser erstellt das PDF selbst. Kontaktdaten des Verantwortlichen, Datenschutzrechte und Angaben zu Dienstleistern finden Sie in unserer Hauptdatenschutzerklärung. Wenn Sie einen Bericht veröffentlichen, speichern wir die Domain, die Scanzeit und die Ergebnisse bis zu 90 Tage. Das öffentliche Verzeichnis zeigt den neuesten Bericht je Website. Private Scans werden dort nie gespeichert. Frühere öffentliche Berichte bleiben online, bis sie ablaufen oder entfernt werden. Öffentliche Berichte enthalten nie IP-Adressen, Browserdaten, Freigabedaten oder Cookie-Werte von Besuchern. Die Designauswahl wird in diesem Browser gespeichert. Der aktuelle Bericht bleibt im Sitzungsspeicher dieses Tabs, damit ein Sprachwechsel keine neue Prüfung erfordert. Löschen Sie den Browserspeicher, um Einstellungen und Ergebnisse zu entfernen.