Wer kümmert sich eigentlich um die Sicherheit deiner Webseite?

Eine Frage, die sich die wenigsten stellen

Wenn du ein KMU führst, hast du eine Webseite. Vermutlich seit Jahren. Sie wurde irgendwann von einer Agentur, einem Freelancer oder jemandem aus dem Bekanntenkreis aufgesetzt, und seither läuft sie. Meistens denkst du nicht an sie, und das ist eigentlich ein gutes Zeichen.

Bis zu dem Tag, an dem du in den Nachrichten liest, dass eine kritische Sicherheitslücke «Millionen Webseiten» betrifft. Dann stellt sich plötzlich eine Frage, die vorher nie jemand gestellt hat: Wer kümmert sich eigentlich um die Sicherheit deiner Webseite?

Wenn die ehrliche Antwort «niemand so richtig» lautet, bist du nicht allein. Es ist bei kleinen und mittleren Unternehmen der Normalfall.

Ein Beispiel: die PHP-Lücke vom Oktober 2026

Im Oktober 2026 wurden zwei kritische Sicherheitslücken in PHP bekannt, der Programmiersprache, auf der rund 70 Prozent aller Webseiten laufen. Die Lücken erlaubten es Angreifern, auf verwundbaren Servern eigenen Code auszuführen, also die Kontrolle über die Webseite zu übernehmen.

In der Schweiz nahm der Kanton Basel-Stadt seine Webseiten vom Netz. Die Universität Genf und die EPFL Lausanne waren über Nacht nicht erreichbar. Ein grosser Schweizer Hoster schaltete vorsorglich über 100'000 Kundenseiten ab. Das Bundesamt für Cybersicherheit (BACS) stufte die Lage als kritisch ein.

Bei mir liefen an diesem Tag mehrere Anfragen von Kund:innen ein, alle mit derselben Frage: «Ist unsere Webseite betroffen?» Die Antwort war jedes Mal: Nein. Für meine Kund:innen war es ein entspannter Tag, für mich ein ruhiger. Warum, dazu komme ich gleich.

Diese Lücke war weder die erste noch wird sie die letzte sein. Log4j, Heartbleed in OpenSSL, unzählige WordPress-Plugin-Lücken: Die Liste ist lang, und sie wird länger. Der Oktober 2026 ist nur ein besonders anschauliches Beispiel dafür, was passiert, wenn die Frage nach der Zuständigkeit vorher nie geklärt wurde.

Warum es so oft WordPress trifft

WordPress ist nicht unsicher. Das vorweg, denn es wird gerne behauptet. Ein sauber gewartetes WordPress auf aktuellem Server ist ein solides System. Das Problem ist nicht die Software, sondern die Art, wie sie bei KMU in der Praxis betrieben wird:

• Die Webseite wurde vor Jahren erstellt, und die Agentur von damals gibt es nicht mehr.
• Updates werden aufgeschoben, weil nach dem letzten Mal etwas kaputtging.
• Es laufen 20 bis 40 Plugins, jedes von einem anderen Entwickler, jedes mit eigenem Update-Rhythmus.
• Die Serverversion ist veraltet, weil ein Plugin mit der neuen nicht mehr funktioniert.
• Niemand im Unternehmen weiss, wer zuständig ist.

Das gilt nicht nur für WordPress. Joomla, Typo3, Drupal und viele andere Systeme funktionieren nach demselben Prinzip: Du bekommst eine Software, und ab dann bist du für deren Betrieb verantwortlich. Ob du das weisst oder nicht.

Ein Sicherheitsexperte brachte es nach der PHP-Lücke in der NZZ auf den Punkt: Das grösste Risiko liegt bei kleinen Firmen, um deren Webseite sich niemand explizit kümmert.

Was sich grundlegend verändert hat

Früher hatte eine solche Lücke einen gewissen Vorlauf. Sie wurde bekannt, Fachleute analysierten sie, und es dauerte Tage oder Wochen, bis daraus ein funktionierender Angriff wurde. In dieser Zeit konnte man patchen.

Diese Zeit gibt es nicht mehr. Der IT-Sicherheitsverantwortliche der Universität Basel sagte es in der NZZ so:

«Vor der KI-Zeit hätte man vielleicht ein bis zwei Wochen gehabt, bevor jemand auf einer Schwachstelle einen funktionierenden Angriff aufbaut. Heute sind es zehn oder fünfzehn Minuten.»

Die PHP-Lücke im Oktober 2026 wurde selbst mithilfe von KI gefunden. Die ersten Angriffe liefen, bevor die Patches überhaupt verfügbar waren. Cloudflare, einer der grössten Betreiber von Internet-Infrastruktur, zählte innert Stunden Millionen automatisierter Angriffsversuche.

Das verändert die Rechnung komplett. Wer mithalten will, braucht jemanden, der rund um die Uhr erreichbar ist, die Lage innert Minuten einschätzen kann und sofort handelt. Für ein Unternehmen mit eigener IT-Abteilung ist das machbar. Für ein KMU mit zehn Mitarbeitenden ist es das nicht. Das ist keine Frage des Könnens, sondern der Ressourcen.

Niemand ist völlig unabhängig

Ein Einwand, den ich oft höre: «Dann wechsle ich einfach auf eine andere Technologie.» So einfach ist es nicht, und das sage ich als jemand, der auf eine bestimmte Plattform setzt.

Fast jede Webseite steht auf einem Fundament, das von erstaunlich wenigen Leuten gepflegt wird. PHP hängt an der PHP Foundation, einer kleinen, spendenfinanzierten Organisation. Node.js, auf dem auch Webflow läuft, hängt an der OpenJS Foundation. OpenSSL, auf dem die Verschlüsselung des halben Internets beruht, wurde jahrelang von einer Handvoll Freiwilliger betreut. Es gibt keine Technologie ohne Sicherheitslücken.

Die eigentliche Frage lautet deshalb nicht «welche Technologie ist sicher», sondern: Wer reagiert im Ernstfall, und wie schnell?

Es geht um Risikoverteilung

Jedes Unternehmen mit einer Webseite trägt ein Sicherheitsrisiko. Die Frage ist nur, wer es trägt. Es gibt zwei saubere Antworten:

• Du trägst es selbst. Eigenes Hosting, eigenes CMS, eigene Plugins, eigene Updates. Volle Kontrolle, volle Verantwortung. Das ist sinnvoll, wenn du die Ressourcen dafür hast oder jemanden dafür bezahlst, der es verbindlich übernimmt.
• Du gibst es bewusst ab. Du setzt auf eine gewartete Plattform, bei der ein Team die Infrastruktur betreibt, überwacht und patcht. Du hast weniger Einfluss auf die Technik, dafür keine nächtlichen Updates und keine Krisensitzungen.

Beides ist legitim. Problematisch ist nur die dritte Variante, die in der Praxis am häufigsten vorkommt: das Risiko selbst tragen, ohne es zu wissen.

Weshalb wir bei KOMUNIQUE auf Webflow setzen

Ich will ehrlich sein: Webflow ist nicht für jedes Projekt die richtige Wahl. Wer einen komplexen Online-Shop mit ERP-Anbindung braucht, individuelle Serverlogik oder bestimmte Anforderungen an den Datenstandort hat, ist anderswo besser aufgehoben. Und bei Mehrsprachigkeit ist Webflow nicht günstig.

Für die grosse Mehrheit der Schweizer KMU, mit denen ich arbeite, stimmt die Rechnung aber. Ihre Webseite ist Visitenkarte, Informationsquelle und Kontaktpunkt. Niemand im Unternehmen will sich um Server kümmern. Texte und Bilder sollen selbst gepflegt werden können. Und die Seite soll mitwachsen, ohne dass alle paar Jahre ein Neubau nötig ist.

Was Webflow in Sachen Sicherheit konkret anders macht:

• Kein Anwendungsserver. Webflow liefert deine Webseite als statisches HTML, CSS und JavaScript über ein weltweites Netzwerk aus. Es gibt keinen Server, auf dem Angreifer Code einschleusen könnten. Deshalb waren unsere Kund:innen von der PHP-Lücke nicht betroffen.
• Kein Plugin-Modell. Design, CMS, SEO-Einstellungen und Formulare sind Teil der Plattform. Es gibt keine Dutzende Erweiterungen von Drittentwicklern, die einzeln gewartet werden müssen.
• Infrastruktur im Grundpreis. DDoS-Schutz, SSL-Zertifikate, Verschlüsselung, automatisches Patching und ein Versionsverlauf mit Wiederherstellung sind in jedem Plan dabei.
• Extern geprüft. Webflow ist nach SOC 2 Type 2 und ISO/IEC 27001 zertifiziert und lässt sich jährlich von unabhängigen Stellen testen. Die Berichte sind für Kund:innen einsehbar.
• Ein Team, das nichts anderes macht. Im Oktober 2026 hat Webflows Sicherheitsteam die eigenen Systeme geprüft, gepatcht, wo nötig, und den Vorgang öffentlich dokumentiert. Ohne dass ich oder meine Kund:innen etwas tun mussten.

Das ist der Grund, warum ich mich als Agentur auf das konzentrieren kann, was meinen Kund:innen wirklich Wert bringt, statt auf das Einspielen von Sicherheitsupdates. Das Risiko ist nicht weg. Es wird nur von Leuten getragen, die dafür ausgerüstet sind.

Ein Wort zum Thema Abhängigkeit, weil es oft kommt: Ja, bei Webflow bindest du dich an einen Anbieter. Bei WordPress kannst du den Hoster wechseln, bei Webflow nicht. Ein harter Lock-in ist aber kein Naturgesetz, sondern eine Frage der Umsetzung. Inhalte lassen sich exportieren, und wir achten bei jedem Projekt darauf, dass ein Wechsel möglich bleibt. Die Kehrseite des fehlenden Einflusses auf die Infrastruktur ist der fehlende Aufwand dafür.

Was du jetzt tun kannst

Unabhängig davon, auf welchem System deine Webseite läuft, hier die Fragen, die du beantworten können solltest:

1. Wer ist zuständig? Gibt es eine Person oder Firma, die verbindlich für Updates und Sicherheit deiner Webseite verantwortlich ist? Mit Vertrag, nicht mit «der macht das schon»?
2. Wie aktuell ist dein System? Frag deinen Hoster oder deine Agentur, welche Versionen von CMS, Plugins und Server laufen. Wenn die Antwort lange dauert, ist das bereits eine Antwort.
3. Was passiert im Ernstfall? Wer wird informiert, wer handelt, wie schnell? Wenn du das nicht weisst, weiss es vermutlich niemand.
4. Gibt es ein Backup? Und wurde schon einmal getestet, ob es sich wiederherstellen lässt?
5. Kennst du deine Pflichten? Das revidierte Schweizer Datenschutzgesetz verlangt bei einem Datenabfluss mit hohem Risiko für Betroffene eine Meldung an den EDÖB «so rasch als möglich». Für die rechtliche Einordnung im Einzelfall empfehle ich den Gang zu einer Fachperson.

Wenn du bei zwei oder mehr dieser Fragen ins Stocken gerätst, trägst du das Risiko selbst, ohne es zu wissen. Das ist kein Vorwurf, es ist bei den meisten KMU so. Aber es ist der Moment, in dem du entscheiden solltest, ob du es weiter selbst tragen oder bewusst abgeben willst.

Ein Angebot

Wenn du deine Webseite auf eine gewartete Plattform bringen möchtest: Wir übernehmen den 1:1-Transfer von WordPress zu Webflow zu fixen Pauschalpreisen. Design und Inhalte bleiben erhalten, Weiterleitungen werden sauber eingerichtet, und du kannst deine Texte danach selbst pflegen, direkt im Browser.

Schreib mir an philipp@komunique.com, ich schaue mir deine Webseite unverbindlich an.

Quellen

• NZZ: «Millionen von Hackerangriffen: So kam es zum Fiasko» (Oktober 2026)
• Webflow Blog: «How Webflow builds security into your site» (Ty Sbano, Josephine Cahill, aktualisiert 26. Oktober 2026)
• BBC: «PHP is the cyber equivalent of an unexploded bomb» (Zoe Kleinman, Oktober 2026)
• W3Techs: Nutzung serverseitiger Programmiersprachen, Stand August 2026
• EDÖB: Meldepflicht bei Verletzungen der Datensicherheit nach revidiertem DSG