Bei Web Systems entwickeln wir seit über zwanzig Jahren Webanwendungen. E-Commerce-Plattformen, B2B-Systeme mit tausenden Transaktionen pro Tag, umfangreiche Kundenportale – all das haben wir umgesetzt. Und aus jedem Projekt nehmen wir dieselbe Lektion mit: Die Sicherheit von Webanwendungen ist kein Feature, das man am Ende wie die Kirsche auf der Torte ergänzt. Sie ist ein Prozess. Kontinuierlich, sich weiterentwickelnd, in jede Phase eingebaut – vom ersten Architekturentwurf bis zur täglichen Wartung im Produktivbetrieb. Wenn Sie das vernachlässigen, kommt die Rechnung schnell. Ein Leck mit personenbezogenen Kundendaten? DSGVO-Bußgelder von bis zu 4% des Jahresumsatzes sind das eine. Aber der Vertrauensverlust bei Geschäftspartnern lässt sich nicht rückgängig machen. In unser Studio in Łódź kamen Projekte nach schweren Sicherheitsvorfällen. Der Wiederaufbau der Reputation und die Reparatur der Systeme kosteten ein Vielfaches dessen, was ein ordentlicher Schutz von Anfang an gekostet hätte. Deshalb teilen wir hier die konkreten Praktiken, die wir täglich anwenden, um Anwendungen zu bauen, die gegen aktuelle Bedrohungen bestehen.
Spis treści
Die Sicherheit von Webanwendungen beginnt bei der Architektur
Ohne solide Architektur gibt es keine sichere Anwendung. Punkt. Jedes neue Projekt bei Web Systems beginnt mit klaren Grenzen zwischen den Modulen – separation of concerns. In der Praxis bedeutet das eine Aufteilung in Schichten: Daten, Geschäftslogik, Präsentation. Jede Schicht erhält eine eigene Sicherheitsrichtlinie, eine unabhängige Validierung und eigene Zugriffsregeln. Wozu? Weil selbst dann, wenn ein Angreifer eine Schicht durchbricht, die übrigen die kritischen Ressourcen weiterhin schützen.
„Das wichtigste Architekturprinzip ist separation of concerns – die Aufteilung der Anwendung in Methoden, Klassen, Module und Schichten mit klar definierten Verantwortlichkeiten und Grenzen. Eine gut entworfene Architektur definiert deutliche Grenzen zwischen den Teilen der Anwendung und legt den Verantwortungsbereich jedes einzelnen fest.”
Das Prinzip ist aus allgemeinen Entwurfsmustern bekannt, doch bei der Sicherheit von Webanwendungen bekommt es ein völlig anderes Gewicht. Ich habe Projekte gesehen, in denen die Autorisierungslogik so mit der Geschäftslogik verflochten war, dass ein Nutzer mit eingeschränkten Rechten Dinge tun konnte, die dem Administrator vorbehalten waren. Warum? Weil die Rechteprüfung nur auf Ebene der Oberfläche stattfand. Ein weiterer Klassiker: keine Datenvalidierung an den Schichtgrenzen. Bösartige Eingabedaten wandern ungefiltert direkt in die Datenbank. Im Ernst, das passiert häufiger, als Sie denken.
Tipp: Entwerfen Sie die Architektur vom ersten Tag an mit Blick auf Sicherheit (security by design). Rüsten Sie Schutzmaßnahmen nicht im Nachhinein nach – definieren Sie die Sicherheitsrichtlinien für jede Schicht bereits in der Planungsphase. Bei uns enthält jedes Architekturdokument einen Abschnitt zum Bedrohungsmodell. So identifizieren wir mögliche Angriffsvektoren, bevor jemand die erste Zeile Code schreibt.
OWASP Top 10 – reale Bedrohungen, denen wir in Projekten begegnen
Die OWASP-Top-10-Liste ist keine akademische Theorie. Unser Entwicklungsteam trifft regelmäßig auf diese Bedrohungen – in Projekten, die wir auditieren, und in solchen, die wir von anderen Firmen übernehmen. Injection-Angriffe (SQL Injection, NoSQL Injection) sind nach wie vor sehr lebendig, besonders dort, wo jemand Datenbankabfragen durch das Zusammensetzen von Strings statt mit parametrisierten Abfragen baut. Broken Authentication? Noch häufiger. Von banalen Fehlern wie Passwörtern im Klartext bis zu subtileren Lücken im Mechanismus zum Zurücksetzen des Passworts, die die Übernahme beliebiger Konten erlauben.
Cross-Site Scripting (XSS) ist die Plage von E-Commerce-Anwendungen und CMS-Systemen – überall dort, wo Inhalte von Nutzern ohne Bereinigung auf Seiten landen. Wir haben einmal das Projekt eines Online-Shops übernommen, in dem sich über das Feld für die Produktbeschreibung JavaScript einschleusen ließ. Der Angreifer konnte die Zahlungskartendaten anderer Kunden abgreifen. Wirklich elegant. CSRF (Cross-Site Request Forgery) wiederum nutzt das Vertrauen des Servers in den Browser eines angemeldeten Nutzers aus und erzwingt nicht autorisierte Operationen.
- Injection (A03:2021) – verwenden Sie parametrisierte Abfragen und ein ORM, bauen Sie SQL-Abfragen nie durch das Verketten von Zeichenketten mit Eingabedaten
- Broken Authentication (A07:2021) – implementieren Sie Rate Limiting an den Login-Endpunkten, erzwingen Sie starke Passwörter und setzen Sie Mehrfaktor-Authentifizierung ein
- XSS (A03:2021) – bereinigen Sie alle Eingabedaten, setzen Sie eine Content Security Policy (CSP) ein und kodieren Sie Ausgaben kontextabhängig
- CSRF – erzeugen Sie eindeutige Tokens für jede Sitzung und prüfen Sie den Origin-/Referer-Header bei zustandsändernden Anfragen
- Security Misconfiguration (A05:2021) – deaktivieren Sie Standardkonten, entfernen Sie überflüssige Diagnose-Endpunkte, halten Sie die Serverkonfiguration aktuell
- Insecure Deserialization – validieren und begrenzen Sie die Typen deserialisierter Objekte, bevorzugen Sie Datenformate wie JSON gegenüber nativer Serialisierung
Verbreitete Web-Frameworks bringen eingebaute Schutzmechanismen mit, schützen aber nicht automatisch vor allem. Entwickler müssen sie bewusst nutzen und ihre Grenzen verstehen. Django schützt standardmäßig vor CSRF – aber das Abschalten dieses Mechanismus „der Bequemlichkeit halber” für eine API? Das haben wir vielfach gesehen. Und jedes Mal ging es schlecht aus.
Sicherer Softwareentwicklungszyklus (SDLC)
Sicherheit, die in den Softwareentwicklungszyklus eingebaut ist – das ist das Fundament unserer Arbeit bei Web Systems. Wir behandeln sie nicht als separate Phase vor der Einführung. Schutzpraktiken integrieren wir in jede Phase: Planung, Programmierung, Code-Reviews, Tests, Deployment, Wartung im Produktivbetrieb. Zu Beginn definieren wir ein Bedrohungsmodell (Threat Modeling) – wir identifizieren Angriffsvektoren, die für die jeweilige Geschäftsdomäne typisch sind. Beim Programmieren halten sich die Entwickler an die vereinbarten Muster für sichere Programmierung. Jede Änderung durchläuft ein verpflichtendes Code-Review. Ohne Ausnahme.
Automatische Sicherheitsscanner in der CI/CD-Pipeline sind die erste Verteidigungslinie. SAST (Static Application Security Testing) analysiert den Quellcode noch vor der Kompilierung auf bekannte Schwachstellenmuster. Es findet potenzielle SQL Injection, hartkodierte Geheimnisse, unsichere Verwendung von Kryptografie. DAST (Dynamic Application Security Testing) testet die laufende Anwendung und simuliert Angriffe von außen. Aber – und hier will ich ehrlich sein – kein automatisches Werkzeug ersetzt einen erfahrenen Entwickler. Scanner erzeugen Fehlalarme und übersehen Schwachstellen, die aus der Geschäftslogik entstehen. Wir betrachten sie als Ergänzung zur menschlichen Analyse, nicht als Ersatz.
Ein Code-Review unter Sicherheitsgesichtspunkten ist eine eigene Fähigkeit. Etwas völlig anderes als die Prüfung der Korrektheit der Geschäftslogik. Unsere Reviewer schauen auf die Verarbeitung von Eingabedaten, die Umsetzung der Autorisierung, die Aufbewahrung von Geheimnissen und das Sitzungsmanagement. Und dann ist da noch das Abhängigkeitsmanagement – wir überwachen regelmäßig CVE-Datenbanken (Common Vulnerabilities and Exposures) auf Schwachstellen in den Bibliotheken, die wir einsetzen. Dependabot, Snyk – diese Werkzeuge informieren uns automatisch über kritische Lücken. So reagieren wir schnell und aktualisieren gefährdete Komponenten, bevor jemand sie ausnutzt.
Authentifizierung, Autorisierung und Sitzungsmanagement
Authentifizierung und Autorisierung sind das am stärksten exponierte Element der Sicherheit einer Webanwendung. Welche Strategie sollten Sie wählen? Das hängt vom Projekt ab. OAuth 2.0 bewährt sich hervorragend, wenn Sie eine Integration mit externen Identitätsanbietern brauchen. Serverseitige Sitzungen bieten Einfachheit und volle Kontrolle in geschlossenen B2B-Systemen. Und JWT (JSON Web Tokens)? Enorm beliebt in Microservice-Architekturen, aber mit realen Risiken verbunden. Ein mit einem schwachen Algorithmus signiertes oder im localStorage abgelegtes Token ist ein Geschenk für Angreifer, die XSS ausnutzen. Bei Web Systems wählen wir die Strategie individuell – wir analysieren die geschäftlichen Anforderungen, die Größe des Systems und das Bedrohungsprofil.
Multi-Faktor-Authentifizierung (MFA) sollte Standard sein. Besonders in Systemen, die sensible oder finanzielle Daten verarbeiten. Die Kosten für die Einführung von TOTP (Time-based One-Time Password) oder die Integration mit Authenticator-Apps? Marginal im Vergleich zum Risiko einer Kontoübernahme durch Phishing oder Credential Stuffing. In unseren B2B-Projekten ist MFA die Standardanforderung für administrative Konten. Immer häufiger führen wir sie auch für Endnutzer ein – progressiv. Das System verlangt den zweiten Faktor bei Operationen mit erhöhtem Risiko, nicht bei jeder Anmeldung.
Das Berechtigungsmodell? Das hängt von der Komplexität der Organisationsstruktur des Kunden ab. RBAC (Role-Based Access Control) reicht aus, wenn Sie eine feste, überschaubare Zahl von Rollen haben – Administrator, Moderator, Nutzer. In komplexen Systemen jedoch, in denen die Rechte von Abteilung, Standort, Zugriffszeit oder Dokumentenklassifizierung abhängen, bietet ABAC (Attribute-Based Access Control) deutlich mehr Flexibilität. Tipp: Speichern Sie in SPA-Anwendungen Access-Tokens im Arbeitsspeicher (in einer JavaScript-Variablen) und Refresh-Tokens in HttpOnly-Cookies mit den Flags Secure und SameSite. Vermeiden Sie localStorage – er ist für jedes Skript auf der Seite zugänglich. Bei einer XSS-Schwachstelle bedeutet das die sofortige Übernahme der Nutzersitzung.
Datenschutz und DSGVO-Konformität in Webanwendungen
Der Schutz personenbezogener Daten ist nicht nur ein Häkchen bei der Checkbox „DSGVO-konform”. Es geht um das Vertrauen von Kunden und Partnern. Das Fundament? Verschlüsselung auf zwei Ebenen. Daten in der Übertragung – TLS 1.3 (ältere Protokollversionen schalten wir ab). Daten im Ruhezustand – Verschlüsselung auf Ebene der Datenbank oder des Dateisystems. Nutzerpasswörter speichern wir ausschließlich als Hashes, die mit brute-force-resistenten Algorithmen erzeugt werden – bcrypt oder Argon2id mit passend gewähltem Rechenaufwand. MD5? SHA-256 für Passwörter? Niemals. Ihre Rechengeschwindigkeit spielt den Angreifern in die Hände.
Privacy by design bedeutet, DSGVO-konforme Systeme vom ersten Architekturentwurf an zu planen, statt ein bestehendes System nachträglich zu flicken. Wie sieht das bei uns in der Praxis aus? Minimierung der erhobenen Daten (wir fragen uns: brauchen wir diese Information wirklich?), Pseudonymisierung wo immer möglich, Trennung identifizierender Daten von analytischen Daten. Jede Operation an personenbezogenen Daten wird in einem unveränderlichen Audit-Log protokolliert – wer wann welche Operation durchgeführt hat. Ein solches Log hilft, unbefugten Zugriff zu erkennen und die Konformität bei einer Prüfung durch die Aufsichtsbehörde nachzuweisen.
Das Recht auf Löschung (Art. 17 DSGVO) ist in komplexen B2B-Systemen erst recht eine Herausforderung. Die personenbezogenen Daten eines Kunden ziehen sich durch viele Tabellen, Dienste und Sicherungskopien. Eine vollständige Löschung erfordert eine durchdachte Strategie. Wir nutzen das Muster Soft Delete mit kaskadierender Anonymisierung – statt Datensätze physisch zu löschen, ersetzen wir identifizierende Daten durch unumkehrbare Werte. So bewahren wir die referenzielle Integrität der Datenbank und die Möglichkeit, aggregierte Daten weiter zu verarbeiten. Die Aufbewahrungsrichtlinie definieren wir gemeinsam mit dem Kunden, und den eigentlichen Löschvorgang nach Ablauf der Aufbewahrungsfrist automatisieren wir. Denn manuell schafft das niemand.
Monitoring, Reaktion auf Vorfälle und kontinuierliche Verbesserung
Sie haben die Anwendung in den Produktivbetrieb gebracht – und das war’s? Nein. Hier fängt es erst an. Kontinuierliches Monitoring und die Bereitschaft zur schnellen Reaktion – ohne das geht es nicht. Zentrale Protokollierung von Sicherheitsereignissen (SIEM) erlaubt es, Informationen aus verschiedenen Quellen zu korrelieren: Anwendungslogs, Webserver, Datenbank, Firewall. Wir konfigurieren Alarme für massenhaft fehlgeschlagene Logins (Brute-Force-Angriff?), unerwartete Muster im API-Verkehr (Scraping oder DDoS?) und Zugriffsversuche auf Ressourcen ohne Autorisierung. Monitoring bedeutet nicht, Daten zu sammeln. Es ist die Fähigkeit, das Signal aus dem Rauschen herauszufiltern. Und Rauschen gibt es reichlich.
Ein Plan zur Reaktion auf Sicherheitsvorfälle legt fest, wer im Krisenfall was tut. Wer entscheidet über die Abschaltung eines kompromittierten Systems? Wer kommuniziert mit dem Endkunden? In welcher Frist muss die Aufsichtsbehörde informiert werden? (Die DSGVO verlangt die Meldung einer Verletzung innerhalb von 72 Stunden.) Diese Fragen sollten nicht zum ersten Mal gestellt werden, wenn es bereits brennt. Wir führen regelmäßig Szenarioübungen durch – wir simulieren verschiedene Arten von Verletzungen, vom Datenleck bis zu Ransomware. Wir prüfen die Wirksamkeit der Verfahren und verkürzen die Reaktionszeit. Besser üben als live improvisieren.
Penetrationstests und Sicherheitsaudits führen wir zyklisch durch – die Häufigkeit passen wir dem Risikoniveau des Projekts an. Anwendungen, die Finanz- oder Medizindaten verarbeiten? Audit jedes Quartal. Systeme mit niedrigerem Risikoprofil? Alle sechs Monate. Zwischen externen Audits betreiben wir kontinuierliches automatisches Monitoring – DAST-Scanner in der CI/CD-Pipeline fangen Sicherheitsregressionen laufend ab, bevor der Code in den Produktivbetrieb gelangt. Und wir messen alles: die Zahl der gefundenen Schwachstellen, die durchschnittliche Zeit bis zu ihrer Behebung (MTTR), die Codeabdeckung durch SAST-Scans, den Anteil der Abhängigkeiten mit aktuellen Patches. Die regelmäßige Analyse dieser Kennzahlen zeigt Trends und macht deutlich, wo Ressourcen den größten Effekt bringen.
FAQ – häufig gestellte Fragen zur Sicherheit von Webanwendungen
Was kostet die Umsetzung umfassender Sicherheit in einer Webanwendung?
Das hängt von Umfang und Komplexität des Projekts ab – aber nach unserer Erfahrung erhöht von Anfang an eingebaute Sicherheit das Entwicklungsbudget um 15-25%. Viel? Nein, wenn Sie es mit den Kosten der Behebung nach einem Vorfall vergleichen. Das Beseitigen von Schwachstellen in einem laufenden Produktivsystem kann sogar zehnmal teurer sein als ihre Vermeidung in der Entwurfsphase. Rechnen Sie DSGVO-Bußgelder, Rechtskosten und den Verlust von Kunden hinzu. Sicherheit ist eine Investition, keine Ausgabe – eine gut geschützte Anwendung verursacht geringere Wartungskosten und verschafft einen echten Wettbewerbsvorteil.
Braucht auch eine kleine B2B-Anwendung fortgeschrittene Schutzmaßnahmen?
Ja. Die Größe einer Anwendung verringert das Risiko nicht – kleinere Systeme sind oft das leichtere Ziel, weil Angreifer schwächeren Schutz vermuten. Jede Anwendung, die personenbezogene, finanzielle oder geschäftliche Daten verarbeitet, braucht die Grundlagen: verschlüsselte Kommunikation, sichere Authentifizierung, Validierung der Eingabedaten, regelmäßige Aktualisierung der Abhängigkeiten. Fortgeschrittene Mechanismen (WAF, SIEM, Penetrationstests) wählen wir proportional zum Risikoprofil. Aber ein Sicherheitsminimum? Nicht verhandelbar. Unabhängig von der Größe des Projekts.
Wie oft sollte ein Sicherheitsaudit der Anwendung durchgeführt werden?
Mindestens einmal jährlich für jede Anwendung im Produktivbetrieb. Dazu eine zusätzliche Prüfung nach jeder größeren Architekturänderung oder der Einführung einer neuen kritischen Funktion. Systeme mit hohem Risiko – Fintech, Medtech, E-Commerce mit Zahlungen – jedes Quartal. Zwischen externen Audits betreiben Sie kontinuierliches automatisches Monitoring. DAST-Scanner in der CI/CD-Pipeline fangen Sicherheitsregressionen laufend ab, bevor der Code in den Produktivbetrieb gelangt.
Sicherheit von Webanwendungen ist ein Prozess, kein Produkt
Der Schutz einer Webanwendung erfordert ein stimmiges Vorgehen – durchdachte Architektur, sicheren Entwicklungszyklus, wirksames Monitoring, kontinuierliche Verbesserung der Verfahren. Kein einzelnes Werkzeug und kein einmaliges Audit sorgt für dauerhafte Sicherheit. Nötig ist eine Unternehmenskultur, in der jeder im Team seine Rolle beim Schutz des Systems versteht. Die Säulen? Eine Architektur auf Basis der Trennung von Verantwortlichkeiten, in den SDLC integrierte Sicherheitspraktiken, mehrschichtige Authentifizierung und Autorisierung, DSGVO-Konformität by design und ein kennzahlbasierter Ansatz für Monitoring und Reaktion auf Vorfälle.
Sicherheit ist heute ein echter Wettbewerbsvorteil. Kunden und Geschäftspartner prüfen immer häufiger die Datenschutzstandards, bevor sie eine Zusammenarbeit beginnen. Zertifikate, Auditergebnisse, eine transparente Sicherheitsrichtlinie – das schafft Vertrauen wirksamer als jedes Marketing. Die Investition in ordentlichen Schutz zahlt sich nicht nur dadurch aus, dass Sie die Kosten von Vorfällen vermeiden. Sie gewinnen auch leichter anspruchsvolle Unternehmens- und institutionelle Kunden, für die die Sicherheit des Technologiepartners eine Voraussetzung der Zusammenarbeit ist.
Planen Sie den Aufbau einer neuen Webanwendung? Brauchen Sie ein Sicherheitsaudit eines bestehenden Systems? Oder möchten Sie den Schutz Ihrer B2B-Plattform modernisieren? Nehmen Sie Kontakt mit dem Team von Web Systems auf. Seit 2006 helfen wir Unternehmen, Lösungen zu schaffen, die geschäftliche Funktionalität mit soliden Schutzstandards verbinden. Wir analysieren Ihr Projekt, identifizieren die Risiken und schlagen einen konkreten Aktionsplan vor, der zu Ihrem Budget und Ihren Prioritäten passt.
