Web Security: So gehen wir als Agentur damit um.

Erst die Daten, dann die Zuständigkeiten

Eine Unternehmenswebsite mit öffentlichen Informationen braucht einen anderen Prüfumfang als ein Portal, in dem Kund:innen Verträge und persönliche Dokumente abrufen. Den Unterschied machen die verarbeiteten Daten, die möglichen Zugriffe und das, was bei einem Ausfall oder Missbrauch passiert.

Deshalb beginnen wir mit konkreten Fragen: Welche Informationen sind schützenswert? Wer darf sie lesen, wer verändern? Welche Schnittstellen verbinden die Website mit anderen Systemen? Welche Abläufe im Unternehmen stehen still, wenn die Anwendung nicht verfügbar ist?

Aus den Antworten ergibt sich, wer was übernimmt. Eine mögliche Aufteilung: Der Provider betreut Betriebssystem und Datenbank, die Anwendung aktualisieren wir, und neue Benutzerkonten gibt das Unternehmen selbst frei. Welche tatsächlich gilt, hängt vom gewählten Dienst und vom Auftrag ab. Festgehalten wird sie bis hin zu Ansprechpersonen und Meldewegen.

Hosting und Infrastruktur: Zugänge bleiben beim Unternehmen

Bei der Auswahl eines Hosting- oder Cloud-Anbieters zählen für uns neben Leistung und Kosten die betreuten Softwareversionen, die Sicherungsverfahren, die Zugriffsmöglichkeiten und der Umgang mit Störungen. Datenstandort und vertragliche Vorgaben kommen dazu. Ein Rechenzentrum in Europa beantwortet allerdings noch nicht, wer eine falsch konfigurierte Anwendung korrigiert.

Wir betreiben keine eigene Kundeninfrastruktur und vermitteln keine Hostingverträge gegen Provision. Unsere Kund:innen schließen direkt mit den Anbietern ab; wir beraten bei der Auswahl und stimmen die technische Lösung mit allen Beteiligten ab. Der Grund ist einfach: Zugänge und Daten sollen beim Unternehmen bleiben, auch wenn sich die Zusammenarbeit einmal ändert.

Bei der Einrichtung zählt, welche Dienste tatsächlich erreichbar sind und mit welchen Rechten. Eine Datenbank muss nicht öffentlich erreichbar sein, nur weil die Website es ist. Testumgebungen bekommen einen Zugangsschutz, und produktive Kundendaten werden nicht ungeprüft in Entwicklungsumgebungen kopiert.

Container stellen eine Anwendung samt ihren Komponenten reproduzierbar bereit. Die Sicherheit der Umgebung hängt dann an gepflegten Basis-Images, begrenzten Prozessrechten und kontrollierten Netzwerkverbindungen. Dazu kommt die Wartung der Container-Laufzeit und des Betriebssystems darunter.

CMS, Frameworks und ihre Abhängigkeiten

Mit dem CMS oder Framework entscheidet sich, wie eine Anwendung in fünf Jahren gewartet werden kann. Uns interessieren deshalb nachvollziehbare Sicherheitsmeldungen, unterstützte Versionen, verfügbare Updates und ein realistischer Upgrade-Pfad. Bei TYPO3 etwa veröffentlicht ein eigenes Security Team Sicherheitsmeldungen für Core und Erweiterungen. Dieselbe Frage stellen wir für Bibliotheken und die Laufzeitumgebung, etwa PHP oder Node.js.

Eine kleine Bibliothek kann weitere Pakete mitbringen, die im Projekt niemand einzeln ausgewählt hat. Sie sind trotzdem Teil des Softwarebestands. Automatische Prüfungen finden bekannte Schwachstellen darin; die Bewertung bleibt Handarbeit: ob die betroffene Version überhaupt im Einsatz ist, ob die anfällige Funktion erreichbar ist und ob es eine Korrektur gibt oder eine Funktion vorübergehend abgeschaltet wird.

Frameworks unterstützen Berechtigungsprüfungen. Welche Person welches Dokument sehen darf, müssen wir für die Anwendung festlegen und testen. Ein Kundenportal darf ein Dokument nicht ausliefern, nur weil jemand angemeldet ist. Es prüft bei jedem Zugriff, ob diese Person dieses Dokument sehen darf. Ein in der Oberfläche ausgeblendeter Link ersetzt diese Prüfung nicht.

Zugangsdaten: Wo liegen sie, was können sie?

Für Passwörter, API-Schlüssel und Zugriffstokens zählen zwei Fragen: Wo sind sie gespeichert, und was lässt sich mit ihnen anrichten?

Ein verschlüsselt abgelegter Schlüssel kann trotzdem weitreichende Rechte haben. Eine Schnittstelle, die Produktdaten lesen soll, braucht kein Recht, Benutzerkonten zu verwalten oder Bestellungen zu löschen. Least Privilege bedeutet: nur die Rechte, die für die Aufgabe nötig sind. Das begrenzt den Schaden, wenn ein Zugang verloren geht.

Secrets Management heißt für uns: Zugangsdaten geschützt bereitstellen, bei Bedarf erneuern und wieder entziehen können. Im Klartext haben sie im Quellcode, in Container-Images und in Diagnoseprotokollen nichts verloren; auch ein privates Code-Repository ist kein Tresor. Für Menschen gilt: persönliche Konten statt Sammelzugänge, Mehrfaktor-Anmeldung, und wenn eine Aufgabe oder Zusammenarbeit endet, werden die erteilten Zugriffe überprüft.

CI/CD: Veröffentlichen mit Protokoll und Rückweg

Für automatisierte Veröffentlichungen setzen wir auf CI/CD-Pipelines: Sie bauen die Software aus dem Quellcode, führen Prüfungen aus und stellen eine eindeutig versionierte Fassung bereit. Veröffentlichungsprotokolle halten fest, welcher geprüfte Stand mit welchen Änderungen veröffentlicht wurde. Das gilt in der Cloud genauso wie auf einem klassischen Server.

Welche Sicherheitsprüfungen wir in diesen Ablauf aufnehmen, legen wir passend zur Anwendung fest. Dazu können Prüfungen auf bekannte Schwachstellen in Bibliotheken und Container-Images, auf versehentlich eingecheckte Zugangsdaten und auf auffällige Codestellen gehören. Ihre Ergebnisse muss jemand bewerten. Ein grüner Prüflauf bedeutet, dass die festgelegten Freigabekriterien erfüllt sind, nicht dass die Anwendung frei von Sicherheitsproblemen ist.

Die Pipeline selbst hat meist Rechte, mit denen sich produktive Systeme verändern lassen. Deshalb schützen wir sie mit Freigaben, begrenzten Zugängen und isolierten Ausführungsumgebungen. Code aus einer ungeprüften externen Änderung bekommt keine produktiven Zugangsdaten.

Zur Planung einer Veröffentlichung gehört ein Rückfallplan. Den vorherigen Code wieder einzuspielen, setzt eine bereits veränderte Datenbank nicht zurück; solche Abhängigkeiten klären wir vor dem Eingriff. Wie wir das bei einer Cloud-Migration angehen, steht im Beitrag TYPO3 in die Cloud.

OWASP: Top 10 zum Verstehen, ASVS zum Prüfen

OWASP stellt frei zugängliche Orientierung und Prüfkriterien für die Sicherheit von Anwendungen bereit. Die OWASP Top 10 benennen die wichtigsten Risikokategorien und sind als Einstieg gedacht. Als Prüfliste sind sie zu grob, als Gütesiegel für eine Website ungeeignet.

Für überprüfbare Anforderungen eignet sich der Application Security Verification Standard, kurz ASVS. Damit lässt sich festlegen, was bei Anmeldung, Sitzungen, Berechtigungen und Datenverarbeitung konkret geprüft wird; der Umfang richtet sich nach Anwendung und Risiko. Wer „getestet“ sagt, sollte deshalb auch sagen können: welche Bereiche, welche Version, nach welchem Maßstab.

Unabhängige Sicherheitsprüfungen

Ob ein unabhängiger Penetrationstest Teil eines Projekts ist, richtet sich nach der Anwendung, den Risiken und den Anforderungen des Unternehmens. Sicherheitsexpert:innen prüfen dabei die vereinbarten Systeme aus der Perspektive eines Angreifers. Ziele, Umfang, Zeitraum und Vorgehen werden vorher festgelegt, etwa, ob eine Webanwendung, ihre Schnittstellen oder auch Teile der Infrastruktur geprüft werden.

Mit bugshell haben wir bei Penetrationstests gute Erfahrungen gemacht. Für uns zählt dabei, dass Befunde verständlich dokumentiert, mit der Entwicklung besprochen und Korrekturen überprüft werden können. So lässt sich „geändert“ von „nachweislich behoben“ unterscheiden.

Ein Pentest ist eine Momentaufnahme mit definiertem Umfang. Neue Funktionen, geänderte Berechtigungen oder zusätzliche Schnittstellen können einen weiteren Test nötig machen; Umfang und Anlass vereinbaren wir passend zum Projekt. Die laufende Wartung ersetzt er nicht.

Betrieb: Updates, Monitoring, Wiederherstellung

In der laufenden Betreuung prüfen wir Updates und Sicherheitsmeldungen für die vereinbarten Systeme und Erweiterungen. Änderungen testen wir vor der Veröffentlichung in einer eigenen Umgebung, inklusive der wichtigen Funktionen und Schnittstellen. Größere Versionswechsel brauchen meist zusätzliche Anpassungen und werden eigens geplant.

Monitoring richtet sich nach der Anwendung. Eine erreichbare Startseite sagt nichts darüber, ob Anmeldung, Datenimport oder Formularversand funktionieren. Welche Verfügbarkeit, welche Fehler und welche sicherheitsrelevanten Ereignisse überwacht werden und wer auf Meldungen reagiert, steht in der Betriebsvereinbarung. Die Protokolle selbst bleiben geschützt und sammeln keine unnötig sensiblen Inhalte.

Wiederherstellung ist ein erprobter Ablauf, kein Häkchen bei „Backup vorhanden“. Ob Dateien und Datenbank im passenden Stand vorliegen, ob sich die Sicherungen tatsächlich einspielen lassen und welche Daten im Ernstfall fehlen würden, zeigt sich erst beim Ausprobieren. Nach einem Sicherheitsvorfall muss auch die Ursache geklärt werden. Sonst geht mit der Wiederherstellung dieselbe Schwachstelle wieder in Betrieb.

Erreichbarkeit, Meldewege und Reaktionszeiten vereinbaren wir passend zum System. Ein Wartungsauftrag bedeutet nicht automatisch Betreuung rund um die Uhr. Und ein Bearbeitungsbeginn ist noch keine Zusage, wann eine Störung behoben ist. Mehr dazu auf unserer Seite zu Website-Wartung und Support.

KI: Angriffe werden schneller, die Prüfung nicht kürzer

KI unterstützt Angreifer:innen beim Auswerten von Informationen, beim Suchen nach Schwachstellen und beim Anpassen von Angriffscode. Das britische National Cyber Security Centre erwartet dadurch effizientere Angriffe und mehr Druck auf schlecht gewartete Systeme. In seiner Einschätzung von 2025 hält es anspruchsvolle Cyberangriffe, die über die gesamte Angriffskette vollständig automatisiert ablaufen, bis 2027 für unwahrscheinlich. Zugleich erwartet es, dass KI die Zeit zwischen dem Bekanntwerden einer Schwachstelle und ihrer Ausnutzung weiter verkürzt. Umso wichtiger, bekannte Lücken zeitnah zu bewerten und zu schließen.

Auf der Entwicklungsseite stellt sich dieselbe Frage nach Rechten. Ein Coding-Agent kann Dateien ändern, Abhängigkeiten installieren und Befehle ausführen, soweit seine Umgebung es zulässt. Welche Daten, Werkzeuge und Systeme er bekommt, ist deshalb Teil der Entscheidung über seinen Einsatz. Für einen Codevorschlag reicht eine Entwicklungsumgebung ohne produktive Zugangsdaten.

Bei einer KI-Funktion in der Anwendung selbst kommt ein weiterer Fall dazu: Fremde Dokumente oder Nachrichten können Anweisungen enthalten, die das Modell von seiner Aufgabe abbringen sollen. Solche Prompt-Injection-Versuche sind bei jedem Datenzugriff und jeder ausführbaren Aktion einzuplanen. Berechtigungen setzt deshalb die Anwendung durch, nicht das Modell.

Die Herkunft von Code ändert für uns nichts an seiner Prüfung. Ein plausibler Vorschlag muss zur Architektur passen, die vorgesehenen Rechte einhalten und sich testen lassen. Das gilt unabhängig davon, ob ihn ein Mensch geschrieben hat oder eine KI.

Wissen nach Rolle, Entscheidungen mit Begründung

Schulungen richten sich nach den tatsächlichen Aufgaben. Entwickler:innen brauchen sichere Implementierung und Prüfverfahren; Redaktionen brauchen Klarheit über Rollen, Freigaben und den Umgang mit Daten; wer Administratorrechte hat, braucht zusätzlich Kontenverwaltung und ein Auge für ungewöhnliche Zugriffsanfragen. Taucht ein Fehler wiederholt auf, gehen wir Ursache und Lösung gemeinsam mit dem Team durch.

Unsere technischen Empfehlungen vertreten wir auch dann, wenn sie zusätzlichen Aufwand bedeuten. Wir begründen, was dringend ist, welche Maßnahme zum Risiko passt und wo weitere Spezialist:innen gebraucht werden. Über Aufwand, Zuständigkeiten und verbleibende Risiken entscheiden wir gemeinsam mit dem Unternehmen, offen und mit Begründung. Bewusst ignorierte Sicherheitsprobleme begleiten wir nicht.

Bei einem neuen Projekt klären wir die Anforderungen; bei einer bestehenden Website prüfen wir zusätzlich den aktuellen Stand und die offenen Aufgaben.