Eine Webanwendung ist heute selten eine simple Seite mit Kontaktformular. Meistens ist sie das Herz des Unternehmens. In ihr zirkulieren Kundendaten, Rechnungen, ERP-Integrationen und die Geschäftslogik, von der die Umsätze abhängen. Und wenn ein solches System bei der Sicherheit versagt, endet das Problem nicht bei einer kurzen Nichtverfügbarkeit. Es reicht deutlich weiter. Bei Web Systems entwerfen und betreuen wir seit 2006 Webanwendungen, B2B-Systeme und API-Integrationen. Diesen Moment kennen wir also nur zu gut – wenn eine scheinbar kleine Nachlässigkeit zu einem teuren Vorfall wird.
Spis treści
Warum die Sicherheit von Webanwendungen über den Projekterfolg entscheidet
Jede Webanwendung ist ein Tor zu den Daten des Unternehmens und seiner Kunden. Ein einziges Leck der Datenbank mit Adressen, Passwörtern oder Bestellhistorie genügt, und die Verluste übersteigen die Kosten der gesamten Umsetzung. Denn dann zahlt man nicht nur für das Schließen der Lücke. Dazu kommen rechtliche Betreuung, die Benachrichtigung der Betroffenen und der Wiederaufbau von Vertrauen, das sich nicht in einem Paket Entwicklungsstunden kaufen lässt.
Der schlimmste Fehler, den wir immer wieder sehen? Schutz als Zusatz zu behandeln, kurz vor dem Start schnell angeklebt. Dabei ist Sicherheit eine Architekturentscheidung. Sie treffen sie am ersten Projekttag. Die Art der Passwortspeicherung, das Berechtigungsmodell, die Trennung der Schichten, die Sitzungsverwaltung – all das wirkt sich auf jede Codezeile aus, die später entsteht. Sicherheit an ein fertiges, schlecht entworfenes System anzukleben ist meist ein teures Refactoring und keine einfache Korrektur.
Und hier eine wichtige Sache aus Sicht des Dienstleisters: Das Risiko liegt nicht allein beim Kunden. Ein DSGVO-Verstoß, eine Geldstrafe oder eine öffentliche Imagekrise treffen auch den Software House, der das System gebaut hat. Deshalb betrachten wir Softwareentwicklung und Datenschutz als gemeinsames Interesse. Nicht als Posten, den man streicht, um ins Budget zu passen.
Es lohnt sich, zwei Arten von Kosten zu unterscheiden. Die erste ist eine planbare Investition in gute Praktiken – über die Zeit verteilt, kalkulierbar, im Voraus einplanbar. Die zweite ist eine Notfallausgabe nach einem Vorfall, wenn Zeitdruck und schlechte Presse die Sätze in die Höhe treiben. Ein solider Technologiepartner hilft dem Kunden, auf der richtigen Seite dieser Gleichung zu bleiben, bevor etwas schiefgeht. Die Entscheidung über die Prioritäten fällt ganz am Anfang. Und ihre Folgen ziehen sich durch den gesamten Lebenszyklus des Produkts.
Die häufigsten Sicherheitslücken in übernommenen Projekten
Wenn wir fremden Code übernehmen, stoßen wir meist auf denselben Satz an Problemen. Immer wieder dasselbe. SQL Injection, XSS und CSRF regieren nach wie vor, obwohl wir sie theoretisch seit Jahren kennen. Die Ursache? Fast immer eine fehlende Validierung der Eingabedaten. Abfragen, die aus vom Nutzer eingegebenem Text zusammengesetzt werden, Inhalte, die ungefiltert in die Seite eingespeist werden, Formulare ohne Token gegen gefälschte Anfragen.
Die zweite wiederkehrende Kategorie ist Broken Access Control, also eine fehlerhafte Zugriffskontrolle. Konten mit zu vielen Rechten, keine Prüfung, ob ein Nutzer überhaupt Anspruch auf einen bestimmten Datensatz hat, Administrationspanels, die allein durch eine wenig naheliegende URL geschützt sind. Ein solcher Schutz durch Verstecken fällt in Sekunden, sobald jemand den Pfad errät oder eine Kennung in der Anfrage austauscht.
Ein eigenes Kapitel sind Secrets. Datenbankpasswörter, API-Schlüssel, Integrationstoken – sie landen direkt im Repository oder in Konfigurationsdateien, ohne jede Verschlüsselung. Und ein einziger unachtsam geteilter Commit genügt, damit Zugangsdaten monatelang offen sichtbar bleiben.
Beim Audit geerbten Codes kehren regelmäßig einige Sünden wieder:
- Bibliotheken und Frameworks in Versionen mit öffentlich bekannten Schwachstellen,
- keine Begrenzung der Anmeldeversuche, was Brute-Force-Angriffe ermöglicht,
- Fehlermeldungen, die die Datenbankstruktur oder Serverpfade preisgeben,
- von Nutzern hochgeladene Dateien ohne Kontrolle von Typ und Größe,
- Sitzungen ohne Ablauf sowie Cookies ohne Sicherheitsflags.
Alle diese Mängel haben einen gemeinsamen Nenner. Sie entstanden, weil Sicherheit nicht Teil des Prozesses war, sondern ein verspäteter Gedanke. Tipp: Wenn Sie ein Projekt von einem anderen Dienstleister übernehmen, beginnen Sie mit einem Audit der Abhängigkeiten und einer Durchsicht des Berechtigungsmodells. Dort stecken meist die gefährlichsten Überraschungen.
Was ein guter Software House standardmäßig umsetzt – Standards und Praktiken
Ein seriöser Dienstleister fragt nicht, ob er grundlegende Schutzmechanismen einschalten soll. Er schaltet sie einfach ein, denn das ist Standard. Die erste Säule ist Verschlüsselung. Die gesamte Übertragung läuft über HTTPS und TLS, und sensible Daten in der Datenbank – personenbezogene Daten, Zahlungsdetails – werden zusätzlich geschützt, damit ihr Abfangen nicht sofort die vollständige Offenlegung bedeutet.
Die zweite Säule ist Authentifizierung. Passwörter liegen nie im Klartext vor, sondern als starke Hashes mit einem soliden Algorithmus. Wo das Risiko höher ist, kommen 2FA und kurzlebige Token hinzu, die nach Ablauf für Angreifer wertlos sind. Und bei Integrationen und externen Anmeldungen greifen wir zu bewährten Standards wie OAuth2, statt eigene, brüchige Lösungen zusammenzubasteln.
Die dritte Säule ist Disziplin auf der Serverseite. Jede Eingabe durchläuft Validierung und Bereinigung, unabhängig davon, was im Browser passiert – denn Schutzmechanismen im Frontend umgeht man mit einem Fingerschnippen. Konsequent halten wir uns an das Prinzip der geringsten Rechte: Nutzer, Dienst und Prozess erhalten genau so viel Zugriff, wie sie für ihre Aufgabe brauchen. Und kein bisschen mehr.
Damit diese Regeln nicht am Gedächtnis eines einzelnen Entwicklers hängen, stützen wir uns auf eine geordnete Checkliste. Tipp: Jedes Projekt sollte mit einer fertigen OWASP-Top-10-Checkliste starten, die schon in der Entwurfsphase bewusst durchgegangen wird. Nicht fünf Minuten vor dem Start hastig abgehakt.
Zu den standardmäßigen guten Praktiken gehört auch Ordnung bei den Secrets. Schlüssel und Passwörter bewahren wir außerhalb des Repositories auf, in dedizierten Konfigurationsspeichern, mit Trennung von Test- und Produktivumgebung. So legt ein versehentliches Code-Leck nicht sofort den Zugang zu den Daten offen. So verstandener Schutz wird zu einem verlässlichen Fundament, auf dem Sie weitere Funktionen ergänzen, ohne ständige Angst vor einer Sicherheitsregression.
Sicherheit, Architektur und API-Integrationen
Eine widerstandsfähige Anwendung beginnt mit guter Architektur. Die Trennung der Schichten, in der Präsentation, Geschäftslogik und Datenzugriff klare Grenzen haben, gibt echte Kontrolle darüber, wer was tun darf. Die Isolierung von Diensten sorgt dafür, dass ein Problem in einem Modul nicht sofort auf das ganze System übergreift. Und B2B-Integrationen, die mit Blick auf Vertrauen entworfen sind, erlauben den sicheren Datenaustausch zwischen Organisationen.
Besondere Aufmerksamkeit verlangen APIs. Denn über sie sprechen Systeme miteinander und mit Partnern. Wir setzen Anfragelimits ein, also Rate Limiting, damit ein einzelner Client den Dienst weder überlastet noch zum massenhaften Abgreifen von Daten nutzt. Den Zugriff stützen wir auf API-Schlüssel und Token, und in der B2B-Kommunikation kommen Signaturen der Anfragen und Verschlüsselung hinzu – dadurch weiß der Empfänger sicher, dass die Daten vom richtigen Absender stammen und unterwegs niemand daran gerührt hat.
Eine gut durchdachte Architektur zahlt sich auch später aus, unabhängig davon, ob wir von einem komplexen B2B-System sprechen oder von moderner Website-Entwicklung mit umfangreicher Logik. Eine klare Aufteilung in Module, ein einziger Punkt der Wahrheit für jede Datenart, ein vorhersehbarer Informationsfluss – all das erleichtert das Schließen von Schwachstellen und die Skalierung ohne Ausfälle. Sie müssen eine einzelne Komponente aktualisieren? Das gelingt, ohne die gesamte Plattform anzuhalten.
Praktische Entscheidungen, die man gleich zu Beginn treffen sollte, sind unter anderem:
- eine eigene Datenzugriffsschicht, damit Sicherheitsregeln an einer Stelle liegen und nicht über den Code verstreut sind,
- Versionierung der API, damit Änderungen die Integrationen bei Partnern nicht zerstören,
- Trennung von Umgebungen und Konfigurationen, was die Reichweite eines möglichen Fehlers begrenzt.
Bei diesem Vorgehen kämpft Sicherheit nicht gegen Skalierbarkeit. Sie geht mit ihr Hand in Hand. Ein modular entworfenes System lässt sich leichter auditieren, testen und weiterentwickeln, und jede weitere Integration fügt sich in ein stimmiges Ganzes ein, statt einen neuen, schlecht bewachten Zugangspunkt zu schaffen.
Wartung, Aktualisierungen und Monitoring nach dem Start
Sicherheit endet nicht am Tag des Starts. Die Bibliotheken und Abhängigkeiten, auf denen eine Anwendung ruht, altern, und in verbreiteten Paketen tauchen laufend neue Schwachstellen auf. Ein System, das vor einem Jahr sicher war, kann heute eine bekannte Lücke haben – nur weil sich niemand um Aktualisierungen gekümmert hat. Deshalb behandeln wir Wartung als festen Bestandteil der Zusammenarbeit und nicht als Leistung, die erst nach einer Störung anläuft.
Die zweite Säule der Wartungsphase ist Sichtbarkeit dessen, was im System geschieht. Ohne Ereignisprotokollierung und Anomalie-Monitoring bemerken Sie einen Vorfall meist erst dann, wenn der Schaden bereits erheblich ist. Ein sinnvolles Set umfasst das Protokollieren wichtiger Vorgänge, Warnungen bei ungewöhnlichen Verkehrsmustern, regelmäßige Sicherungskopien und einen erprobten Wiederherstellungsplan. Denn eine Kopie, die nie jemand zurückzuspielen versucht hat, ist ein trügerisches Sicherheitsgefühl. Mehr nicht.
Betrachten Sie die Wartungskosten als Investition, nicht als Belastung. Geplante Aktualisierungen und Monitoring sind günstiger und weniger stressig als das Löschen eines Brands mitten am Wochenende, wenn die Anwendung liegt und Daten abgeflossen sein könnten. Vorbeugen kostet fast immer weniger als die Reaktion auf ein Risiko, das bereits eingetreten ist.
Tipp: Planen Sie regelmäßige Audits und Penetrationstests, besonders nach größeren Änderungen – einer neuen Integration, einer Datenmigration oder der Einführung eines weiteren Moduls. Gerade nach umfangreicheren Eingriffen schleicht sich am leichtesten unbemerkt eine neue Schwachstelle ein.
Eine gute Gewohnheit ist, mit dem Dienstleister einen klaren Wartungsrhythmus zu vereinbaren. Wer prüft wie oft die Aktualisierungen, wie sehen die Verfahren zur Reaktion auf einen Vorfall aus, in welcher Zeit ist der Dienst nach einer Störung zurück. Ein solcher Plan macht aus Sicherheit statt einer Absichtserklärung einen messbaren Prozess, auf den man während des gesamten Produktlebens bauen kann. Auch lange nach Abschluss der Hauptphase der Umsetzung.
FAQ – die häufigsten Kundenfragen zur Anwendungssicherheit
In Gesprächen mit Kunden kehren einige Fragen wie ein Bumerang zurück. Wir haben die häufigsten zusammengetragen, samt der Antworten, die wir in der Phase von Angebot und Planung üblicherweise geben.
Braucht auch ein kleines Projekt Schutz auf Enterprise-Niveau?
Die Größe kann täuschen. Selbst eine kleine Anwendung unterliegt denselben Vorschriften und denselben automatisierten Angriffen wie große Systeme, sobald sie personenbezogene Daten oder Zahlungen verarbeitet. Bots, die das Internet scannen, prüfen nicht die Größe des Unternehmens. Sie prüfen das Vorhandensein bekannter Schwachstellen. Deshalb gelten die Grundlagen – Verschlüsselung, korrekte Authentifizierung, Datenvalidierung – immer. Der Unterschied liegt in den Proportionen: Ein kleineres Projekt braucht keine ausgebauten Mechanismen wie im Konzern, aber das Fundament muss unabhängig von der Größe solide sein.
Was kostet die Umsetzung eines angemessenen Sicherheitsniveaus?
Es gibt keinen einheitlichen Betrag, denn die Kosten hängen von der Sensibilität der Daten, der Zahl der Integrationen und den rechtlichen Anforderungen ab. Aber es gibt eine andere, wichtigere Beobachtung: Von Anfang an eingebaute Sicherheit ist vergleichsweise günstig, weil sie aus guten Entwurfsentscheidungen folgt und nicht aus zusätzlicher Arbeit. Teuer wird sie erst dann, wenn man sie einem fertigen System nachrüsten oder die Folgen eines Vorfalls beseitigen muss. Am vernünftigsten ist es, sie als festen Bestandteil des Budgets für Umsetzung und Wartung zu behandeln. Nicht als optionalen Zusatz.
Was tun, wenn die Anwendung jemand anderes geschrieben hat und wir ihren Zustand nicht kennen?
Eine häufige Situation, und sie lässt sich in den Griff bekommen. Wir beginnen mit einem Audit – der Durchsicht der Abhängigkeiten, des Berechtigungsmodells, der Art der Secret-Speicherung sowie der am stärksten exponierten Funktionen. Am Ende steht eine nach Risiko geordnete Liste von Schwachstellen. Dank ihr schließen wir zuerst das Gefährlichste und planen ruhigere Aufräumarbeiten für später. Ein solcher Überblick liefert zudem ein realistisches Bild der technischen Schuld, bevor Sie über die Weiterentwicklung oder Modernisierung des Systems entscheiden.
Fazit – was Sie von Ihrem Dienstleister verlangen sollten
Die wichtigste Schlussfolgerung ist einfach. Sicherheit ist ein Prozess und keine einmalige Funktion, die man abhakt und vergisst. Fordern Sie sie in jeder Phase ein – von den ersten Architekturentscheidungen über Programmierung und Integrationen bis zur Wartung lange nach dem Start. Ein Dienstleister, der erst bei der Projektabnahme über Datenschutz zu sprechen beginnt, verrät sich selbst: Er hat ihn als Zusatz behandelt und nicht als Fundament.
Einen seriösen Partner erkennen Sie an einigen konkreten Signalen. Er kennt und nutzt die OWASP Top 10. Er beschreibt seine Praktiken offen, statt sich hinter Allgemeinplätzen zu verstecken. Er schlägt ein klares Berechtigungsmodell und einen Wartungsplan mit Aktualisierungen, Monitoring und Sicherungskopien vor. Und er kann seine Entscheidungen in einer Sprache erklären, die auch für nichttechnische Personen verständlich ist, und sie mit dem realen Geschäftsrisiko verknüpfen.
Worauf Sie bei der Wahl des Dienstleisters achten sollten:
- ob Sicherheit bereits in der Angebots- und Entwurfsphase auftaucht,
- ob Secrets und Schlüssel außerhalb des Repositories aufbewahrt werden,
- ob es einen Plan für Aktualisierungen, Monitoring und Reaktion auf Vorfälle gibt,
- ob der Dienstleister nach größeren Änderungen Audit und Tests vorschlägt.
Bei Web Systems behandeln wir diese Fragen als Standard, denn seit 2006 entwerfen, implementieren und betreuen wir Web- und Mobile-Anwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce sowie KI-Lösungen. Wir wissen, wie sich Sicherheit mit Skalierbarkeit und einem vernünftigen Budget verbinden lässt. Ohne leeres Marketing.
Planen Sie ein neues Produkt, ein MVP, eine Integration, eine KI-Einführung, die Automatisierung von Prozessen oder die Modernisierung eines bestehenden Systems? Nehmen Sie Kontakt mit dem Team von Web Systems auf – wir helfen Ihnen, die Risiken einzuschätzen und eine Lösung zu entwerfen, die vom ersten Tag an sicher ist.
