Aufeinanderfolgende Sicherheitsvorfälle: „Angriffsabwehr" und „Schadensminderung" für Web-Systeme | Themen

Seit Anfang 2026 häufen sich vor allem in den letzten Monaten Meldungen über Cyberangriffe und Datenlecks auf Web-Systeme inländischer Unternehmen.
Am 8. Oktober veröffentlichte JPCERT/CC eine Sicherheitsmitteilung zu den gehäuften Angriffen auf inländische Organisationen, und am folgenden 9. Oktober rief die IPA zu Notfallmaßnahmen gegen Datenlecks durch Cyberangriffe auf.

Wenn man solche Vorfälle sieht, lenkt man den Fokus leicht auf Probleme alter Systeme und nicht aktualisierter Software.
Natürlich sind diese großen Risiken, aber es ist nicht so einfach, dass ein System sicherer wird, wenn man es modernisiert.

Ich glaube, es ist wichtig, Maßnahmen zur Vermeidung von Eindringlingen gründlich umzusetzen, und falls trotzdem ein Sicherheitsproblem auftritt, eine mehrschichtige Verteidigungsarchitektur, die den Schaden minimiert, bereitzuhaben.

Diesmal haben wir uns anhand von Cloudflare, Supabase und EmDash – das im September 2026 offiziell veröffentlicht wurde – Gedanken über die zukünftige Web-Sicherheit gemacht.

Illegale Zugriffe sind nicht nur auf bestimmte große Unternehmen beschränkt.

JPCERT / CC weist in dieser Sicherheitsmitteilung nicht nur auf Angriffe auf bekannte Schwachstellen hin, sondern auch auf eine Vielzahl von Angriffsverfahren wie Durchsuchung von Konfigurationsdateien und Sicherungsdateien, unerlaubte Anfragen an APIs, Missbrauch gestohlener API-Schlüssel sowie Eindringen in das interne Netzwerk über öffentliche Webserver als Einstiegspunkt.

Besonders bemerkenswert ist, dass neben Services für normale Benutzer auch Verwaltungssysteme und BI-Tools für Mitarbeiter angegriffen werden.
Heutzutage, mit der Entwicklung von AI, ist das alte Konzept, dass es ausreicht, nicht von Google indexiert zu werden, völlig verschwunden. Systeme, die im Internet veröffentlicht werden, können sofort und regelmäßig automatisierter Erkundung und Angriffen ausgesetzt sein.

Die Ansicht, dass kleine Systeme wie unseres nicht ins Visier genommen werden, ist längst nicht mehr haltbar.

Macht die Verwendung moderner Technologien es sicherer?

Alte PHP-Versionen, nicht mehr unterstützte Frameworks und jahrelang nicht aktualisierte CMS-Systeme bergen selbstverständlich Risiken.
Sind Systeme wirklich sicher, wenn sie mit Next.js oder Astro aufgebaut und auf Cloud-Services gehostet werden?

Leider nicht unbedingt. 😭

Auch moderne Frameworks können Sicherheitslücken aufweisen, und wenn die API-Autorisierung fehlerhaft ist, können Daten abgerufen werden, auf die eigentlich kein Zugriff bestehen sollte.
Wenn Authentifizierungsdaten oder API-Schlüssel falsch verwaltet werden, kann dies auch bei robusten Cloud-Services zu Schäden führen, daher sind die Aktualität der Technologie und die Sicherheit des Systems zwei unterschiedliche Probleme.

Cloudflare als Schutzschicht vor Ihrer Anwendung einsetzen

Cloudflare ist als CDN bekannt, spielt aber auch eine wichtige Rolle bei der Sicherheit von Webanwendungen.
Mit einer WAF (Web Application Firewall) können beispielsweise verdächtige Anfragen erkannt und blockiert werden, und mit Rate Limiting lassen sich massenhaft auftretende Zugriffe drosseln. Mit Cloudflare Access können Sie den Zugriff auf Admin-Dashboards für interne Nutzer auch auf authentifizierte, bestimmte Benutzer beschränken.

Doch auch das ist keine perfekte Lösung. 😭
Das Risiko liegt bereits darin, dass Admin-Dashboards, die gar nicht öffentlich sein sollten, für jeden zugänglich sind.

Eine WAF kann nicht alle Angriffe verhindern – Missbrauch von korrekt formatierten Anfragen oder anwendungsspezifische Autorisierungsmängel erfordern zusätzliche Maßnahmen.
Cloudflare ist ein System, das Schutz vor der Anwendung einrichtet, garantiert aber nicht die Sicherheit der Anwendung selbst.

Zugriffskontrolle auch auf Datenbankseite mit Supabase

Hier kommt RLS (Row Level Security) in Betracht, das Supabase bietet.
RLS ist eine PostgreSQL-Funktion, mit der Sie den Zugriff auf Datenbankzeilen kontrollieren können – beispielsweise in einem Geschäftssystem für mehrere Unternehmen können Sie auf Datenbankebene festlegen, dass Benutzer von Unternehmen A nur auf Daten von Unternehmen A zugreifen können.
Falls die Autorisierungslogik in der Anwendung fehlerhaft sein sollte, fungiert eine korrekt konfigurierte RLS als zusätzliche Schutzschicht.

Aber… auch RLS ist kein Allheilmittel, selbst wenn es konfiguriert ist. 😭

Supabase Secret Keys und traditionelle service_role Keys haben starke Berechtigungen, die je nach Verwendungsweise Row Level Security (RLS) umgehen können. Wenn die Verwaltung fehlerhaft ist, bietet RLS keinen echten Schutz.
Das Konfigurieren von Tabellenberechtigungen und das Testen von Richtlinien sind daher unerlässlich.

Entscheidend ist die Autorisierung nicht nur an die Anwendung zu delegieren, sondern der Datenbank auch unabhängige Kontrolle zu geben.

Das Vertrauen-nicht-Standard-Plugin-System von EmDash

Am 28. September 2026 wurde das von Cloudflare unterstützte CMS „EmDash 1.0" veröffentlicht, und auch die offizielle Plugin-Registry wurde freigegeben!
Wir folgen dem Projekt seit der Veröffentlichung und haben bereits Websites damit implementiert, daher freuen wir uns sehr.

So entstand ein mehrsprachiger Blog mit EmDash – SSR-Kosteneinsparungen bei der Übersetzungs-API
Migration von microCMS zu EmDash + Cloudflare

Das Interessante an EmDash ist sein Plugin-Sicherheitsmodell.
Bei traditionellen CMS können Plugins mit ähnlichen Berechtigungen wie der CMS-Kern arbeiten, und Schwachstellen in Plugins können das gesamte System beeinträchtigen. Plugins aus der offiziellen EmDash-Registry werden jedoch in einer Sandbox ausgeführt.
Durch die Einschränkung der verfügbaren Funktionen und Ressourcen von Plugins und die explizite Darlegung erforderlicher Berechtigungen wird der Einflussbereich minimiert.

Natürlich gibt es auch bei EmDash native Plugins, die keine Sandbox nutzen, und das bedeutet nicht, dass alle Plugins sicher sind. Außerdem ist EmDash selbst ein noch relativ junges CMS, daher ist es notwendig, die zukünftige Betriebserfahrung und die Sicherheitsmaßnahmen genauer zu beobachten.

Dennoch bleibt die Designphilosophie, Plugins von Anfang an nicht vollständig zu vertrauen, ein beachtenswertes Punkt bei der Überlegung zukünftiger CMS.

Das Gemeinsame ist die Denkweise „nichts blindlings vertrauen"

Cloudflare, Supabase und EmDash sind Dienste mit unterschiedlichen Funktionen, aber aus Sicherheitsperspektive wird ein gemeinsamer Ansatz sichtbar.

Cloudflare: Verdächtige Zugriffe werden bereits vor der Anwendung kontrolliert
Supabase: Zugriffe von der Anwendung aus werden auch auf Datenbankseite durch Berechtigungskontrollen gesteuert
EmDash: Plug-ins erhalten nur die minimal erforderlichen Berechtigungen und werden in einer isolierten Ausführungsumgebung ausgeführt

In all diesen Fällen wird nicht die gesamte Sicherheit auf einen Mechanismus gestützt, sondern der Bereich des Vertrauens wird begrenzt – ein Ansatz, der dem Zero-Trust-Prinzip und dem Prinzip der minimalen Berechtigung sehr ähnlich ist, nicht wahr?

Selbst wenn die Authentifizierung durchbrochen würde, bedeutet das nicht, dass alle Operationen erlaubt sind.
Selbst wenn es eine Sicherheitslücke in der API gäbe, bedeutet das nicht, dass alle Daten abgerufen werden können.
Selbst wenn ein Plug-in eine Sicherheitslücke hätte, bedeutet das nicht, dass das gesamte System manipuliert werden könnte.

Durch die Schaffung solcher Grenzen wird das Risiko verringert, dass ein einzelnes Problem zu Schäden im gesamten System führt.

Fazit: Eindringlinge abwehren und Schäden im Notfall minimieren

Zu React gewechselt! Zu Next.js gewechselt! In die Cloud migriert!
Solche technologischen Modernisierungen sind sinnvoll, doch (auch wenn es sich bereits wie aus alter Zeit anfühlt,) der bloße Austausch von Frameworks oder Infrastruktur ist noch keine echte Modernisierung. Wichtig ist es, die Verantwortung und Berechtigungen bei Authentifizierung, Autorisierung, API, Datenbank und externen Diensten klar zu definieren und eine Struktur zu schaffen, in der sich eine einzelne Sicherheitsverletzung nicht leicht auf andere Bereiche ausbreitet.

Es gibt keine absolute Sicherheit.
Daher sind mehrschichtige Abwehrmaßnahmen erforderlich, die Eindringversuche von vornherein verhindern und Schäden minimieren, falls Probleme auftreten.

Cloudflare, Supabase und EmDash sind zwar nicht allheilmittel, aber diese Technologien verfügen über Mechanismen, um nur die notwendigen Berechtigungen zu vergeben und Grenzen zwischen den Rollen zu setzen.

Bei Liberogic steht beim Aufbau von Websystemen nicht nur die Einführung neuer Technologien im Fokus, sondern auch die Verantwortungstrennung und mehrschichtige Verteidigung.

Angesichts der zunehmenden Sicherheitsvorfälle sollte man sich bei der Modernisierung von Websystemen nicht nur fragen, welche Technologien man einsetzt, sondern auch, wie weit das Vertrauen in die Architektur reicht.