Über Sicherheit wird in Softwareprojekten selten gesprochen, solange nichts passiert — und nach einem Vorfall über nichts anderes mehr. Für Entscheider ist die Lage unbequem: Die Materie ist technisch, Angebote bleiben hier gern vage, und seriös versprechen kann niemand „sicher“. Möglich ist: Risiken benennen, den Aufwand am Schutzbedarf ausrichten und erkennen, ob ein Dienstleister die Grundlagen beherrscht. Dieser Beitrag ordnet die wichtigsten Felder so ein, dass Sie im Gespräch die richtigen Fragen stellen können, ohne selbst Fachmann zu werden.
Zuerst der Schutzbedarf, dann die Maßnahmen
Der häufigste Fehler passiert vor der ersten technischen Entscheidung: Es wird über Werkzeuge geredet, bevor geklärt ist, was zu schützen ist. Drei Fragen genügen für den Anfang. Welche Daten verarbeitet die Anwendung, und wie schmerzhaft wären Verlust, Veröffentlichung oder Verfälschung? Wer soll Zugriff haben? Wie lange kann der Betrieb ohne das System weiterlaufen? Aus den Antworten ergibt sich das angemessene Niveau — und die Erlaubnis, anderswo bewusst weniger zu tun.
Denn hundertprozentige Sicherheit gibt es nicht, nur ein Verhältnis von Aufwand zu Risiko, das Sie verantworten können. Ein internes Werkzeug für acht Kollegen braucht nicht das Programm einer Patientenplattform; wer es trotzdem verlangt, verbrennt Budget, das anderswo fehlt. Umgekehrt ist Sparsamkeit bei sensiblen Daten keine Option. Der rechtliche Rahmen — Datenschutz, Auftragsverarbeitung, Meldepflichten — verdient eine eigene Betrachtung und findet sie in einem separaten Beitrag in unserem Blog; hier geht es um die Umsetzung.
| Anwendungstyp | Schaden im Ernstfall | Angemessenes Niveau |
|---|---|---|
| Internes Tool, wenige Nutzer, keine personenbezogenen Daten | Arbeitsausfall, verlorene Zwischenergebnisse | Grundschutz: Zugriffsschutz, Updates, geprüfte Backups |
| Kundenportal mit Kontakt-, Vertrags- und Belegdaten | Vertrauensverlust, rechtliche Folgen, Aufklärungsaufwand | zusätzlich Rollenmodell, MFA, Protokollierung, Alarme |
| Plattform mit Zahlungs- oder Gesundheitsdaten | existenzbedrohend, aufsichtsrechtlich relevant | zusätzlich Verschlüsselungskonzept, externer Test, Notfallübung |
Authentifizierung: Identität und Sitzungen
Die Anmeldung ist die sichtbarste Schutzschicht und die, bei der am meisten selbst gebaut wird — meist ohne Not. Registrierung, Passwort-Zurücksetzen, Mehr-Faktor-Anmeldung und Sitzungsverwaltung sind gelöste Probleme; etablierte Bibliotheken und Identitätsdienste erledigen sie zuverlässiger. „Kaufen statt bauen“ ist hier fast immer richtig, und das gilt ausdrücklich auch für uns als Entwicklungspartner: eigener Code an dieser Stelle ist Risiko ohne Gegenwert.
Worauf Sie trotzdem achten sollten: Passwörter dürfen ausschließlich als moderner Hash gespeichert werden, nie lesbar und nie per E-Mail verschickt. Ein zweiter Faktor ist mindestens für administrative Konten Pflicht, denn ein übernommener Admin-Zugang hebelt jede weitere Maßnahme aus. Sitzungen brauchen eine begrenzte Lebensdauer und müssen bei Abmeldung, Passwortwechsel und Rechteentzug serverseitig ungültig werden. Anmeldeversuche gehören begrenzt, sonst wird das Formular zum Einfallstor. Und das Zurücksetzen des Passworts ist die klassische Nebentür: kurzlebige Einmal-Links, keine Auskunft, ob eine Adresse existiert.
Autorisierung: die häufigste reale Lücke
Angemeldet zu sein heißt nicht, berechtigt zu sein. Genau hier klaffen die meisten Lücken, und sie sind unspektakulär: Die Anwendung prüft, ob jemand eingeloggt ist, aber nicht, ob dieser Nutzer dieses Objekt sehen darf. Wer die Rechnungsnummer in der Adresszeile von 1042 auf 1043 ändert und den Beleg eines anderen Kunden liest, hat kein System gehackt — er hat eine fehlende Zeile Prüfcode gefunden. Solche Fehler entstehen aus Wiederholung: Jeder einzelne Endpunkt muss prüfen, und einer wird vergessen.
- Das Rollenmodell gehört vor die Umsetzung: Wer darf lesen, ändern, freigeben, löschen — schriftlich, in Geschäftssprache, mit den echten Funktionen Ihres Hauses.
- Rechte prüfen ausschließlich auf dem Server. Ein ausgegrauter Button im Browser ist Bedienkomfort, keine Sicherheitsmaßnahme.
- Die Prüfung sitzt zentral und nah an den Daten, damit sie nicht in fünfzig Endpunkten wiederholt und irgendwann übersehen wird.
- Minimale Rechte als Standard: Neue Rollen starten ohne Zugriff, nicht mit allem außer dem Ausdrücklichen.
- Testen, nicht glauben: Mit einem Testkonto der niedrigsten Rolle gezielt versuchen, an fremde Datensätze zu kommen — diese Übung dauert eine Stunde und findet mehr als jeder Scanner.
Eingaben, Injection und Dateien
Jede Eingabe von außen ist unvertrauenswürdig, auch die von angemeldeten Nutzern und aus fremden Systemen. Validierung im Browser ist Bedienhilfe; verbindlich geprüft wird auf dem Server, gegen erlaubte Werte statt gegen eine Liste verbotener. Für Datenbankzugriffe gilt: ausschließlich parametrisierte Abfragen oder eine erprobte Zugriffsschicht, niemals aus Text zusammengebaute Befehle. Für Ausgaben das Gegenstück: kontextgerechte Kodierung, damit eingeschmuggelter Code im Browser anderer Nutzer nicht ausgeführt wird.
Dateiuploads verdienen besondere Aufmerksamkeit, weil sie fremde Inhalte dauerhaft ins Haus holen: Typ und Größe prüfen, außerhalb des ausführbaren Bereichs speichern, nur über kontrollierte Wege wieder ausgeben. Als Orientierung, welche Fehlerklassen am häufigsten auftreten, ist die OWASP Top 10 nützlich — nicht als Prüfliste zum Abhaken, sondern als Landkarte, an der ein Dienstleister zeigt, wie er die Felder abdeckt.
Secrets und Verschlüsselung
Zugangsdaten sind der kürzeste Weg ins System, und sie liegen erschreckend oft im Quellcode. Datenbank-Passwörter, API-Schlüssel und Signaturgeheimnisse gehören nie in ein Repository, sondern in einen Secret-Store oder die Umgebungskonfiguration. Jede Umgebung braucht eigene Zugangsdaten: Wer mit Produktivschlüsseln entwickelt, hat die Trennung faktisch aufgegeben. Und es braucht einen Ablauf für den Fall, dass ein Schlüssel nach außen gelangt oder ein Mitarbeiter das Unternehmen verlässt — Rotation und Entzug dokumentiert, nicht improvisiert.
Bei Verschlüsselung lohnt eine ehrliche Unterscheidung. Transportverschlüsselung gehört auf alle Verbindungen, auch auf interne. Verschlüsselung im Ruhezustand — auf Datenträger- oder Datenbankebene — schützt vor Diebstahl von Hardware und Backup-Medien, nicht aber vor einer kompromittierten Anwendung, die ordnungsgemäß entschlüsselte Daten ausliefert. Wer einzelne sensible Felder zusätzlich verschlüsselt, kauft Schutz mit eingeschränkter Suchbarkeit; das kann richtig sein, sollte aber bewusst entschieden werden. Nicht infrage kommen eigene Verschlüsselungsverfahren.
Abhängigkeiten und Update-Disziplin
Ein großer Teil jeder modernen Web-App besteht aus fremdem Code: Frameworks, Bibliotheken, Container-Basisimages. Das ist wirtschaftlich sinnvoll und gleichzeitig der realistischste Angriffsweg, denn bekannte Lücken in veralteten Paketen sind öffentlich dokumentiert und automatisiert auffindbar.
Wirksam ist wenig Spektakuläres: ein Inventar der Komponenten, automatische Meldungen zu bekannten Schwachstellen, feste Wartungsfenster statt Aktionismus nach Schlagzeilen, und die Bereitschaft, ungepflegte Pakete zu ersetzen. Entscheidend ist die Aktualisierbarkeit als Architekturziel: Wenn ein Update nur mit Handarbeit und Bauchschmerzen möglich ist, wird es aufgeschoben — daraus entstehen die Altlasten. Rechnen Sie diesen Aufwand von Anfang an ins Betriebsbudget ein; wie sich Wartungsfenster in den Ablauf einfügen, zeigt unser Vorgehen.
Erkennen, reagieren, wiederherstellen
Prävention scheitert irgendwann; dann entscheidet, wie schnell Sie es merken und wie geordnet Sie reagieren. Dafür braucht es Protokolle der richtigen Ereignisse: Anmeldungen und Fehlversuche, Rechteänderungen, administrative Eingriffe, Zugriffe auf schützenswerte Daten. Passwörter, Tokens und sensible Inhalte haben darin nichts zu suchen; sinnvoll sind eine zentrale, schwer manipulierbare Ablage und eine festgelegte Aufbewahrungsdauer.
Nutzen entsteht erst durch Alarme: Auffällige Muster müssen einen Menschen erreichen, der zuständig ist und eingreifen darf. Dazu gehört ein knapper Notfallplan, der die unangenehmen Fragen vorab klärt: Wer entscheidet über eine Abschaltung, wer informiert Kunden und Aufsicht, wie erreichen sich die Beteiligten, wenn die eigenen Systeme betroffen sind? Zwei Seiten, halbjährlich durchgesprochen, sind mehr wert als ein ungelesenes Handbuch.
Bleiben die Backups, das am häufigsten überschätzte Sicherheitsnetz. Ein Backup, dessen Wiederherstellung nie getestet wurde, ist eine Hoffnung. Nötig sind mehrere Generationen, eine Kopie außerhalb der Reichweite des laufenden Systems, damit Verschlüsselungsangriffe sie nicht mitnehmen, und eine Wiederherstellungsübung mit Zeitmessung. Erst diese Messung beantwortet die Frage, die Sie als Entscheider brauchen: Wie viele Stunden Stillstand und Datenverlust wären im Ernstfall real?
Prüfen: Scanner, Pentest und der Dauerbetrieb
Zum Nachweis gibt es zwei Werkzeuge, die gern verwechselt werden. Automatisierte Scanner prüfen breit und günstig gegen bekannte Muster: veraltete Pakete, fehlende Schutzeinstellungen, offene Ports. Sie gehören in den regelmäßigen Betrieb, produzieren aber Fehlalarme und finden nichts, was Verständnis Ihrer Fachlogik voraussetzt. Ein Penetrationstest ist Handarbeit erfahrener Prüfer und findet genau das: Berechtigungsketten, Logikfehler, Wege über mehrere Schritte. Er ist punktuell, teurer und nur so gut wie der vereinbarte Umfang — samt Nachtest, ob die Befunde behoben sind.
Für eine Plattform mit sensiblen Daten ist dieser externe Blick vor dem Start gut investiertes Geld. Für ein kleines internes Werkzeug ist er es meist nicht; dort bringen ein sauberes Berechtigungskonzept, ein Vier-Augen-Review und aktuelle Abhängigkeiten pro Euro deutlich mehr. Wichtiger als jeder Einzeltest ist ohnehin, dass Sicherheit keine Projektphase ist, die man abschließt. Sie ist Betrieb: bei jedem Release mitgedacht, mit benannten Zuständigen und festem Platz im Jahresbudget. Welches Niveau für Ihre Anwendung angemessen ist, klären wir gern konkret — über die Kontaktseite oder mit dem Überblick auf der Leistungsseite.
Häufige Fragen
Was ist die häufigste Sicherheitslücke in Web-Apps?
Fehlende Objektprüfung bei der Autorisierung: Die Anwendung prüft, ob jemand angemeldet ist, aber nicht, ob dieser Nutzer gerade diesen Datensatz sehen oder ändern darf. Solche Lücken lassen sich ohne Werkzeuge finden — durch schlichtes Ändern einer ID in der Adresszeile.
Brauchen wir einen Penetrationstest vor dem Start?
Das hängt am Schutzbedarf. Bei Zahlungs- oder Gesundheitsdaten und bei Plattformen mit vielen externen Nutzern ist der externe Blick sinnvoll investiert. Bei kleinen internen Werkzeugen bringen ein geprüftes Berechtigungskonzept, ein Code-Review und aktuelle Abhängigkeiten pro Euro mehr.
Wie viel vom Budget sollte in Sicherheit fließen?
Eine allgemeingültige Quote gibt es nicht. Belastbar ist ein anderer Ansatz: Grundlagen wie Rechteprüfung, Secrets-Verwaltung und geprüfte Backups sind nicht optional und gehören in jede Kalkulation. Alles darüber staffeln Sie nach Datenart und Schadensausmaß — und planen einen laufenden Posten für Updates und Überwachung ein.
Reicht Verschlüsselung als Schutz für sensible Daten?
Nein. Transportverschlüsselung schützt Daten auf dem Weg, Verschlüsselung im Ruhezustand vor Diebstahl von Datenträgern und Backups. Gegen eine kompromittierte Anwendung oder ein zu weit gefasstes Benutzerrecht hilft beides nicht — dort wirken Berechtigungen, Protokollierung und Update-Disziplin.
