Website-Sicherheit prüfen: passive Checks ohne Hacking

Passive Sicherheitschecks für Onlineshops: Ablauf des TLS-Zertifikats, HSTS, CSP, nosniff, Cookie-Flags, Mixed Content, altes jQuery, security.txt, DMARC.

FixReports Redaktion10 Min. Lesezeit

Vieles an der Sicherheitskonfiguration eines Onlineshops können Sie von außen prüfen, indem Sie lesen, was die Website ohnehin jedem Besucher schickt: ihr TLS-Zertifikat, Weiterleitungen, HTTP-Response-Header, Cookies, die geladenen Skripte und ihre öffentlichen DNS-Einträge. Diese passiven Prüfungen senden keinen Angriffstraffic und brauchen keinen Login, sie belasten einen Shop also nicht stärker als ein normaler Besuch. Sie decken Konfigurationslücken auf, etwa ein bald ablaufendes Zertifikat, fehlendes HSTS, unsichere Cookies, Mixed Content oder eine jQuery-Version mit bekannten Schwachstellen. Sie sind kein Penetrationstest und können nicht beweisen, dass ein Shop sicher ist.

Das Wichtigste in Kürze

  • Öffentlich vertrauenswürdige TLS-Zertifikate, die seit dem 15. März 2026 ausgestellt werden, dürfen höchstens 200 Tage gültig sein; im März 2027 sinkt die Grenze auf 100 Tage und im März 2029 auf 47 Tage (CA/Browser Forum (öffnet in einem neuen Tab)).
  • Browser ignorieren den HSTS-Header, wenn er über unverschlüsseltes HTTP gesendet wird (MDN (öffnet in einem neuen Tab)).
  • Die CSP-Direktive frame-ancestors funktioniert nicht in einem <meta>-Tag; sie muss als Response-Header gesendet werden (MDN (öffnet in einem neuen Tab)).
  • jQuery-Versionen vor 3.5.0 sind von zwei XSS-Schwachstellen betroffen, und die CISA hat eine davon, CVE-2020-11023, am 23. Januar 2025 in ihren Katalog Known Exploited Vulnerabilities aufgenommen (NVD (öffnet in einem neuen Tab)).
  • Eine security.txt-Datei muss die Felder Contact und Expires enthalten und unter /.well-known/security.txt liegen (RFC 9116 (öffnet in einem neuen Tab)).

Was gilt als passive Sicherheitsprüfung?

Eine passive Prüfung liest nur, was die Website oder ihr DNS auf eine gewöhnliche Anfrage zurückgibt.

Das heißt: öffentliche Seiten laden, Zertifikat und Response-Header lesen, die Cookies und Skripte einer Seite auflisten und öffentliche DNS-Einträge abfragen. Eine passive Prüfung errät keine Passwörter, sendet keine Injection-Payloads, tastet keine Admin-URLs ab und scannt keine Ports. Alles im Folgenden lässt sich mit einem Browser, curl, openssl und dig erledigen.

Wie prüfen Sie Ihr TLS-Zertifikat und dessen Ablaufdatum?

Lesen Sie die Daten und Namen des Zertifikats direkt aus und stellen Sie sicher, dass die Verlängerung automatisiert ist.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Prüfen Sie, ob notAfter mit ausreichendem Abstand in der Zukunft liegt, ob das Zertifikat sowohl example.com als auch www.example.com abdeckt, falls Sie beide nutzen (der Zertifikatsbetrachter des Browsers listet die Namen auf), und ob der Browser keine Warnungen anzeigt. Die Laufzeiten von Zertifikaten werden nach den Baseline Requirements des CA/Browser Forum (Abschnitt 6.3.2, Version 2.3.1, Stand Oktober 2026) schrittweise verkürzt, gemäß dem am 11. April 2025 angenommenen Ballot SC-081v3 (öffnet in einem neuen Tab):

Zertifikat ausgestelltMaximale Gültigkeit
Vor dem 15. März 2026398 Tage
15. März 2026 bis 14. März 2027200 Tage
15. März 2027 bis 14. März 2029100 Tage
Ab dem 15. März 202947 Tage

Kurze Laufzeiten machen eine manuelle Verlängerung riskant. Vergewissern Sie sich daher, dass Ihr Hoster oder Ihr Zertifikatstool automatisch verlängert. Prüfen Sie außerdem, ob unverschlüsseltes HTTP auf HTTPS weiterleitet:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Sie erwarten eine Antwort 301 (oder 308) mit einem location-Header, der mit https:// beginnt.

Welche Security-Header sollte ein Onlineshop senden?

Eine kleine Gruppe von Response-Headern blockiert verbreitete Angriffe im Browser, fast ohne Aufwand.

HeaderFunktionTypischer WertQuelle
Strict-Transport-SecurityWeist Browser an, nur HTTPS zu verwenden, und verhindert, dass Nutzer Zertifikatsfehler wegklickenmax-age=31536000; includeSubDomainsMDN (öffnet in einem neuen Tab)
Content-Security-Policy: frame-ancestorsLegt fest, welche Websites Ihre Seiten einbetten dürfen, und schützt so vor Clickjackingframe-ancestors 'self'MDN (öffnet in einem neuen Tab)
X-Frame-OptionsÄltere Steuerung für das Einbetten in Frames; laut OWASP macht frame-ancestors den Header in unterstützenden Browsern überflüssigDENY oder SAMEORIGINOWASP (öffnet in einem neuen Tab)
X-Content-Type-OptionsUnterbindet MIME-Sniffing und blockiert Skripte und Stylesheets, die mit falschem Typ ausgeliefert werdennosniffMDN (öffnet in einem neuen Tab)
Referrer-PolicyBegrenzt, wie viel von Ihren URLs an andere Websites übermittelt wirdstrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader für den XSS-Filter des Browsers; laut OWASP kann er in ansonsten sicheren Websites XSS-Schwachstellen erzeugenNicht setzen, oder 0OWASP

Prüfen Sie, was Ihr Shop sendet:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Zwei Hinweise. includeSubDomains blockiert jede Subdomain, die nur über HTTP funktioniert; prüfen Sie daher zuerst Ihre Subdomains. HSTS-Preloading erfordert ein max-age von mindestens 31536000 und includeSubDomains; ergänzen Sie preload also erst, wenn jede Subdomain für HTTPS bereit ist. Eine vollständige CSP, die Skripte einschränkt, lohnt sich, doch OWASP weist darauf hin, dass sie aufwendig zu konfigurieren und zu pflegen ist, und Shops mit vielen Apps müssen sie sorgfältig testen.

Sind Ihre Cookies mit Secure, HttpOnly und SameSite gesetzt?

Session- und Warenkorb-Cookies sollten alle drei Attribute tragen, und Sie sehen sie in den Set-Cookie-Response-Headern.

AttributWirkung (laut MDN (öffnet in einem neuen Tab))Wo es darauf ankommt
SecureWird nur über HTTPS gesendet; Websites mit unverschlüsseltem HTTP können es nicht setzenJedes Cookie in einem HTTPS-Shop
HttpOnlyJavaScript kann das Cookie nicht über document.cookie lesen, was gegen XSS hilftLogin-Sessions und Warenkörbe
SameSite=Lax oder StrictBegrenzt, wann das Cookie bei websiteübergreifenden Anfragen gesendet wirdSessions; Strict eignet sich für Authentifizierungs- und Warenkorb-Cookies
SameSite=NoneWird bei websiteübergreifenden Anfragen gesendet; muss mit Secure kombiniert werdenNur eingebettete Funktionen von Drittanbietern, die es benötigen

Ist kein SameSite-Attribut gesetzt, behandeln Browser das Cookie als Lax. Cookies, die Ihre eigenen Skripte lesen müssen, können nicht HttpOnly sein; konzentrieren Sie sich daher auf die Cookies, die einen eingeloggten Kunden oder einen Admin identifizieren.

curl -sI https://example.com/ | grep -i "^set-cookie"

Die Entwicklertools des Browsers zeigen dieselben Informationen, einschließlich der Cookies, die Skripte nach dem Laden der Seite setzen.

Wie finden Sie Mixed Content?

Mixed Content (gemischte Inhalte) ist jede Ressource, die auf einer über HTTPS ausgelieferten Seite über HTTP geladen wird, und die Browserkonsole listet sie auf.

MDN (öffnet in einem neuen Tab) unterscheidet zwei Gruppen. Bilder, Audio und Video sind „upgradable“ (aktualisierbar): Browser fordern sie automatisch über HTTPS an. Skripte, Stylesheets, iframes, Schriften und fetch()-Anfragen sind „blockable“ (blockierbar): Browser blockieren sie, wodurch alles, was davon abhängt, nicht mehr funktioniert. Aktualisierte Anfragen an eine reine IP-Adresse werden ebenfalls blockiert.

Um Mixed Content zu finden, öffnen Sie die Konsole auf Ihren wichtigsten Templates (Startseite, Kollektion, Produkt, Warenkorb) und durchsuchen Sie Theme-Code, Seiteninhalte und App-Einstellungen nach http://. Laut Shopify Help Center gilt jede Shopseite mit einem Asset, das nicht über HTTPS ausgeliefert wird, als unsicher (öffnet in einem neuen Tab), und Shopify empfiehlt, Assets bei Shopify zu hosten oder über HTTPS auszuliefern. Bei WooCommerce prüfen Sie alte Beitragsinhalte und Theme-Optionen, falls die Website jemals unter http:// lief.

Wie erkennen Sie veraltete JavaScript-Bibliotheken mit bekannten CVEs?

Listen Sie die Bibliotheken auf, die jede Seite lädt, lesen Sie ihre Versionen aus und gleichen Sie sie mit der National Vulnerability Database ab.

Beginnen Sie mit jQuery. In der Browserkonsole gibt $.fn.jquery die geladene Version zurück (jQuery API (öffnet in einem neuen Tab)). Diese Versionen sollten Sie markieren:

CVEBetroffene VersionenProblemNVD-Score (v3.1)
CVE-2020-11022 (öffnet in einem neuen Tab)1.12.0 bis vor 3.5.0Wird nicht vertrauenswürdiges HTML an Methoden wie .html() oder .append() übergeben, kann Code ausgeführt werden6,1 (mittel)
CVE-2020-11023 (öffnet in einem neuen Tab)1.0.3 bis vor 3.5.0Dasselbe für HTML mit <option>-Elementen; seit dem 23. Januar 2025 im KEV-Katalog der CISA6,1 (mittel)
CVE-2019-11358 (öffnet in einem neuen Tab)Vor 3.4.0Prototype Pollution über jQuery.extend(true, ...)6,1 (mittel)

Beide Probleme von 2020 sind in jQuery 3.5.0 behoben. Eine verwundbare Version bedeutet, dass der fehlerhafte Code vorhanden ist; ob er ausgenutzt werden kann, hängt davon ab, wie die Website Daten an ihn übergibt. WordPress liefert seit Version 5.6 (öffnet in einem neuen Tab) jQuery 3.5.1 mit. Ein altes jQuery in einem WooCommerce-Shop deutet daher auf ein veraltetes WordPress hin oder auf ein Theme oder Plugin, das eine eigene Kopie lädt. Bei Shopify prüfen Sie Ihre Theme-Dateien und die Apps, die Skripte einbinden.

Was ist security.txt, und braucht Ihr Shop eine solche Datei?

Es ist eine reine Textdatei, die Sicherheitsforschern mitteilt, wie sie Ihnen eine Schwachstelle melden können.

RFC 9116 (öffnet in einem neuen Tab) (April 2022, ein Informational RFC, die Umsetzung ist also freiwillig) legt fest, dass die Datei über HTTPS unter /.well-known/security.txt als text/plain ausgeliefert werden muss. Contact und Expires sind Pflichtfelder, und der RFC empfiehlt ein Expires-Datum, das weniger als ein Jahr in der Zukunft liegt.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Bei WooCommerce können Sie die Datei auf Ihrem Server ablegen. Prüfen Sie bei einer gehosteten Plattform, ob Sie unter diesem Pfad eine Datei veröffentlichen können; falls nicht, hilft trotzdem ein deutlich gekennzeichneter Sicherheitskontakt auf Ihrer Kontaktseite.

Wie schützt DMARC Ihren Shop vor E-Mail-Spoofing?

Mit DMARC können Sie Postfachanbieter bitten, E-Mails unter Quarantäne zu stellen oder abzuweisen, die Ihre Domain in der From-Adresse verwenden, ohne SPF oder DKIM mit Alignment zu bestehen.

Ein Eintrag mit p=none sammelt nur Berichte; gefälschte E-Mails stoppt er nicht. Kunden erwarten Bestellbestätigungen und E-Mails zum Zurücksetzen des Passworts von Ihrer Domain, deshalb lohnt es sich, Phishing-Nachrichten zu blockieren, die genau Ihre Domain zeigen. Prüfen Sie Ihre Policy mit dig +short TXT _dmarc.example.com; die Spezifikation finden Sie in RFC 9989 (öffnet in einem neuen Tab). DMARC deckt keine ähnlich aussehenden Domains ab, sondern nur die Domain, die den Eintrag veröffentlicht.

Was verwaltet Shopify, und was steuern Sie bei WooCommerce selbst?

Shopify betreibt die Server hinter seinen Storefronts, während ein selbst gehosteter WooCommerce-Shop die Servereinstellungen Ihnen und Ihrem Hoster überlässt.

PrüfungShopifyWooCommerce (selbst gehostet)
TLS-ZertifikatKostenlos für alle bei Shopify hinzugefügten Domains (öffnet in einem neuen Tab); bei Domains von Drittanbietern kann es bis zu 48 Stunden dauernIhr Hoster oder Ihre eigene Einrichtung
Weiterleitung von HTTP auf HTTPSPlattformEinstellungen von Webserver, CDN oder Hoster
Security-HeaderWerden von Shopifys Servern gesendetWebserver, CDN oder ein Plugin
Cookie-FlagsShopifys eigene Cookies setzt die Plattform; App- und Theme-Cookies liegen bei IhnenWordPress-Core, Plugins und Server
Mixed Content und JS-BibliothekenIhr Theme, Ihre Inhalte und AppsIhr Theme, Ihre Inhalte und Plugins
security.txt und DMARCIhre Domain und Ihr DNSIhre Domain und Ihr DNS

Als wir im Oktober 2026 mehrere bei Shopify gehostete Storefronts geprüft haben, enthielten ihre Antworten HSTS mit einem max-age von etwa 91 Tagen, X-Content-Type-Options: nosniff und eine CSP mit upgrade-insecure-requests, während sich frame-ancestors von Shop zu Shop unterschied. Shopify gibt an, nach PCI DSS Level 1 zertifiziert (öffnet in einem neuen Tab) zu sein. Ihr Theme und Ihre installierten Apps bleiben in Ihrer Verantwortung.

Für WooCommerce empfiehlt der Hardening-Leitfaden (öffnet in einem neuen Tab) von WordPress, WordPress und Plugins aktuell zu halten, nicht genutzte Plugins zu löschen und Ihren Hoster zu fragen, welche Sicherheitsvorkehrungen er trifft.

Warum ist das kein Penetrationstest?

Ein Penetrationstest unternimmt aktiv Angriffsversuche; passive Prüfungen beobachten nur.

NIST SP 800-115 definiert Penetrationstests als Sicherheitstests, bei denen Prüfer reale Angriffe nachahmen, um Wege zu finden, die Sicherheitsfunktionen eines Systems zu umgehen (NIST-Glossar (öffnet in einem neuen Tab)). Passive Prüfungen sehen keine serverseitigen Schwachstellen in Plugins, keine schwachen oder mehrfach verwendeten Admin-Passwörter, keine fehlende Zwei-Faktor-Authentifizierung, keine fehlerhafte Zugriffskontrolle und keinen verwundbaren Code, der nie im Seitenquelltext erscheint. Nutzen Sie sie als Basis, die Sie jederzeit wiederholen können. Für eine tiefergehende Absicherung beauftragen Sie einen Penetrationstest mit schriftlich festgelegtem Umfang, auf Systemen, die Ihnen gehören oder für deren Test Sie autorisiert sind.

Ein kostenloser Scan führt eine erste Prüfung Ihres Shops durch. Der Website-Sicherheitsreport deckt die passiven Prüfungen aus diesem Artikel ab, von TLS und Weiterleitungen über Header, Cookies, Mixed Content und veraltete Bibliotheken bis zu security.txt und DMARC, mit Lösungen für jeden Befund. Wie jede passive Prüfung kann er nicht garantieren, dass ein Shop sicher ist.

Häufig gestellte Fragen

Gefährden passive Sicherheitsprüfungen meinen Shop?

Nicht mehr als ein normaler Besuch. Sie rufen dieselben öffentlichen Seiten und DNS-Einträge ab wie jeder Browser oder Mailserver und versuchen weder, sich anzumelden, noch Angriffs-Payloads zu senden.

Kann ich bei Shopify Security-Header hinzufügen?

Die Response-Header der Storefront kommen von Shopifys Servern; wenden Sie sich daher an den Shopify-Support, wenn ein benötigter Header fehlt. Ein CSP-<meta>-Tag in Ihrem Theme kann einige Direktiven ergänzen, MDN weist aber darauf hin, dass frame-ancestors in <meta> nicht unterstützt wird.

Bedeutet eine alte jQuery-Version, dass mein Shop gehackt wurde?

Nein. Sie bedeutet, dass Code mit bekannten Schwachstellen geladen wird, was das Risiko erhöht, wenn die Website nicht vertrauenswürdiges HTML an die betroffenen Methoden übergibt. Aktualisieren Sie jQuery oder entfernen Sie das Theme oder Plugin, das die alte Version lädt.

Wie lange darf ein TLS-Zertifikat heute gültig sein?

Öffentlich vertrauenswürdige Zertifikate, die ab dem 15. März 2026 ausgestellt werden, dürfen höchstens 200 Tage gültig sein. Ab dem 15. März 2027 sinkt die Grenze auf 100 Tage und ab dem 15. März 2029 auf 47 Tage.

Ist eine security.txt-Datei Pflicht?

RFC 9116 ist ein Informational RFC, die Veröffentlichung der Datei ist nach dem Standard also freiwillig. Sie ist mit wenig Aufwand veröffentlicht und gibt Sicherheitsforschern einen klaren Weg, Sie zu erreichen.

Bedeutet ein unauffälliger passiver Scan, dass mein Shop sicher ist?

Nein. Er zeigt, dass die öffentliche Konfiguration korrekt aussieht. Serverseitige Schwachstellen, die Sicherheit von Konten und Fehler in der Geschäftslogik erfordern andere Tests.

Quellen

Alle Ratgeber