Sichere Webentwicklung: die wichtigsten Prinzipien

Ein neues Feature funktioniert im Test, die Oberfläche ist fertig und der Release steht bevor. Doch genau in dieser Phase entstehen häufig Sicherheitslücken: Ein Formularfeld akzeptiert unerwartete Inhalte, eine Fehlermeldung verrät interne Details oder eine Sitzung bleibt nach dem Logout gültig. Sichere Webentwicklung bedeutet deshalb, Sicherheit nicht erst vor dem Go Live zu prüfen, sondern sie von der Anforderung bis zum Betrieb mitzudenken.

Webanwendungen verarbeiten Daten aus vielen Quellen: Formulare, Schnittstellen, Cookies, Datei-Uploads, Datenbanken und externe Dienste. Jede dieser Quellen kann fehlerhafte oder manipulierte Daten liefern. Für uns als Entwicklungsteam ist daher ein Grundsatz entscheidend: Vertraue keiner Eingabe, unabhängig davon, ob sie scheinbar aus dem eigenen Frontend oder von einer bekannten Schnittstelle stammt.

Eingaben konsequent validieren

Eingabevalidierung verhindert, dass Anwendungen Daten verarbeiten, die nicht zum erwarteten Zweck passen. Dabei geht es nicht nur um klassische Kontaktformulare. Auch URL-Parameter, HTTP-Header, JSON-Anfragen an APIs, hochgeladene Dateien und Werte aus Cookies sind Eingaben.

Eine robuste Validierung erfolgt immer auf dem Server. Prüfungen im Browser verbessern zwar die Bedienbarkeit, bieten aber keinen verlässlichen Schutz. Clientseitige Validierung kann umgangen werden, deshalb muss das Backend alle sicherheitsrelevanten Regeln selbst durchsetzen.

Lege für jedes Eingabefeld möglichst präzise fest:

Prüfkriterium	Beispiel für eine sichere Regel
Datentyp	Eine Artikelmenge ist eine ganze Zahl, kein beliebiger Text.
Wertebereich	Eine Menge liegt innerhalb eines fachlich sinnvollen Bereichs.
Format	Eine E-Mail-Adresse oder Kundennummer entspricht dem erwarteten Muster.
Länge	Freitext, Suchbegriffe und Dateinamen haben definierte Maximallängen.
Zeichensatz	Werte enthalten nur Zeichen, die für den jeweiligen Zweck erforderlich sind.
Fachliche Plausibilität	Ein angemeldeter Nutzer darf nur Daten seines eigenen Mandanten ändern.

Bevorzuge Positivlisten. Statt zu versuchen, alle unerwünschten Zeichen oder Muster zu sperren, erlaubst du nur Werte, die für den jeweiligen Anwendungsfall gültig sind. Eine Auswahl für den Versandstatus sollte beispielsweise aus einer festen Menge zulässiger Statuswerte stammen und nicht aus frei eingegebenem Text.

Besondere Aufmerksamkeit verdienen Datei-Uploads. Prüfe Dateigröße, zulässige Dateitypen und den tatsächlichen Dateiinhalts-Typ. Verlasse dich nicht allein auf Dateiendungen oder Angaben des Browsers. Speichere hochgeladene Dateien möglichst außerhalb des öffentlich erreichbaren Webverzeichnisses, verwende serverseitig erzeugte Dateinamen und liefere Dateien nur nach einer Berechtigungsprüfung aus.

Auch Daten aus der eigenen Datenbank sind nicht automatisch vertrauenswürdig. Sie können aus älteren, weniger gut abgesicherten Importen stammen oder durch andere Systeme geschrieben worden sein. Validiere deshalb Daten an den Grenzen deiner Anwendung und prüfe Berechtigungen immer im aktuellen Kontext.

Ausgaben passend zum Kontext kodieren

Viele Web-Sicherheitsprobleme entstehen nicht bei der Annahme von Daten, sondern bei ihrer Anzeige. Wenn eine Anwendung unkontrollierte Inhalte in HTML-Seiten, JavaScript, URLs oder Dokumente einfügt, können Inhalte anders interpretiert werden als beabsichtigt. Das ist eine typische Ursache für Cross-Site Scripting, kurz XSS.

Die zentrale Gegenmaßnahme ist kontextbezogene Ausgabekodierung. Daten müssen genau dort kodiert werden, wo sie ausgegeben werden, und zwar passend zum Zielkontext. Inhalte für HTML-Text benötigen eine andere Behandlung als Werte in HTML-Attributen, URL-Parametern oder JavaScript-Kontexten.

In der Praxis helfen diese Regeln:

• Nutze Template-Engines und Frameworks, die Ausgaben standardmäßig sicher kodieren.
• Deaktiviere automatische Kodierung nur in Ausnahmefällen und dokumentiere die Begründung.
• Verwende für Datenbankabfragen parametrisierte Abfragen oder etablierte ORM-Mechanismen. Das trennt Daten und Abfragelogik zuverlässig.
• Setze Inhalte nicht über unsichere DOM-Schnittstellen ein, wenn sichere Alternativen verfügbar sind.
• Bereinige nutzergeneriertes HTML mit einer dafür geeigneten, gepflegten Bibliothek, falls Rich-Text fachlich wirklich nötig ist.
• Lege eine Content Security Policy fest. Sie begrenzt, aus welchen Quellen Browser Inhalte laden und ausführen dürfen.

Ausgabekodierung ersetzt keine Eingabevalidierung, und Eingabevalidierung ersetzt keine Ausgabekodierung. Beide Maßnahmen erfüllen unterschiedliche Aufgaben. Die Validierung schützt die fachliche Verarbeitung, die Kodierung schützt die Darstellung im jeweiligen Ausgabekontext.

Authentifizierung und Sitzungen richtig absichern

Die Anmeldung ist ein besonders schützenswerter Teil jeder Webanwendung. Hier entscheidet sich, ob Angreifer Zugang zu Konten erhalten und ob sie Sitzungen anderer Nutzer übernehmen können. Verwende etablierte Komponenten und Standards, statt eigene Authentifizierungsverfahren zu entwickeln. Selbst entwickelte Login- und Token-Mechanismen enthalten häufig schwer erkennbare Fehler.

Für Passwörter gelten klare Mindestanforderungen:

• Speichere Passwörter niemals im Klartext und niemals mit ungeeigneten, schnellen Hash-Verfahren.
• Nutze bewährte, passwortspezifische Hash-Verfahren mit individuellem Salt und angemessenen Kostenparametern.
• Übertrage Anmeldedaten ausschließlich über verschlüsselte Verbindungen.
• Begrenze wiederholte fehlgeschlagene Anmeldeversuche sinnvoll und erkenne auffällige Muster.
• Unterstütze MFA, insbesondere für administrative Konten und Zugriffe auf sensible Daten.
• Gestalte Passwort-Zurücksetzen mit kurzlebigen, einmalig nutzbaren Verfahren und ohne unnötige Preisgabe, ob ein Konto existiert.

Nach der Anmeldung beginnt die Sitzungsverwaltung. Eine sichere Sitzung benötigt eine zufällig erzeugte, ausreichend lange Sitzungskennung. Diese Kennung darf nicht in URLs erscheinen, weil URLs in Protokollen, Browser-Verläufen oder Referrer-Informationen landen können. Nutze Cookies mit den Attributen Secure, HttpOnly und einer angemessenen SameSite-Einstellung. Damit reduzierst du das Risiko, dass Sitzungsdaten über unverschlüsselte Verbindungen, Skripte oder ungewollte Kontextwechsel preisgegeben werden.

Erneuere die Sitzungskennung nach der Anmeldung und nach Änderungen der Berechtigungsstufe. Beende Sitzungen beim Logout serverseitig und definiere angemessene Ablaufzeiten für Inaktivität sowie für die maximale Sitzungsdauer. Besonders wichtig: Prüfe die Berechtigung bei jeder sensiblen Anfrage auf dem Server. Eine versteckte Schaltfläche im Frontend ist keine Zugriffskontrolle.

Das Prinzip der geringsten Rechte, auch Least Privilege genannt, gehört ebenfalls hierher. Nutzer, Dienste und technische Konten erhalten nur die Berechtigungen, die sie tatsächlich benötigen. Trenne Rollen für Verwaltung, Fachbearbeitung und Betrieb klar voneinander. So begrenzt du den Schaden, falls ein Konto kompromittiert wird.

Sichere Voreinstellungen statt nachträglicher Absicherung

Sichere Webentwicklung profitiert von einem einfachen Grundsatz: Die sichere Einstellung muss der Standard sein. Wenn eine Funktion nur durch bewusstes, dokumentiertes Abweichen unsicher wird, passieren deutlich weniger Fehler als bei optionalen Sicherheitseinstellungen.

Achte insbesondere auf diese Voreinstellungen:

• Produktionssysteme zeigen keine detaillierten Fehlermeldungen oder Stack-Traces an. Intern müssen Fehler trotzdem vollständig und geschützt protokolliert werden.
• Debug-Funktionen, Testzugänge, Beispieldaten und Standardkonten sind in Produktion deaktiviert oder entfernt.
• Sicherheitsrelevante HTTP-Header werden zentral konfiguriert, etwa für Transportverschlüsselung, Content Security Policy und Einbettungsschutz.
• CORS-Regeln sind restriktiv. Erlaube nur bekannte Origins und niemals pauschal beliebige Herkunftssysteme für sensible Schnittstellen.
• Geheimnisse wie API-Schlüssel, Zertifikate und Zugangsdaten liegen nicht im Quellcode oder in Repositorys. Nutze eine geeignete Geheimnisverwaltung und getrennte Konfigurationen je Umgebung.
• Abhängigkeiten werden regelmäßig aktualisiert und auf bekannte Schwachstellen geprüft.

Konfiguration ist Programmcode mit hoher Sicherheitswirkung. Behandle Infrastrukturdateien, Berechtigungsmodelle und Cloud-Einstellungen deshalb mit derselben Sorgfalt wie Anwendungslogik. Änderungen sollten nachvollziehbar, geprüft und versioniert sein.

Security in den Entwicklungsprozess integrieren

Ein einzelner Sicherheitstest kurz vor dem Release reicht nicht aus. Sicherheitsanforderungen gehören in die Planung, Umsetzung, Prüfung und den Betrieb. Das reduziert Nacharbeit und macht Risiken früh sichtbar, wenn Korrekturen noch vergleichsweise einfach sind.

Beginne bei neuen Funktionen mit einer kurzen Bedrohungsanalyse. Frage konkret: Welche Daten verarbeitet die Funktion? Wer darf sie lesen oder ändern? Welche Vertrauensgrenzen werden überschritten? Was passiert bei fehlerhaften Eingaben, gestohlenen Sitzungen oder Ausfällen externer Dienste? Diese Fragen machen Sicherheitsanforderungen greifbar.

Definiere Sicherheitskriterien bereits in User Stories und Akzeptanzkriterien. Beispiele sind serverseitige Berechtigungsprüfungen, Protokollierung sicherheitsrelevanter Ereignisse, Schutz vor automatisierten Anmeldeversuchen oder sichere Fehlerbehandlung. Ergänze Code Reviews um feste Prüfpunkte für Eingaben, Ausgaben, Autorisierung, Fehlerbehandlung und Geheimnisse.

Automatisierte Prüfungen helfen, bekannte Fehlerklassen früh zu erkennen. Dazu gehören Abhängigkeitsprüfungen, statische Codeanalyse und Tests für Berechtigungslogik. Sie ersetzen jedoch nicht die fachliche Beurteilung. Gerade Mandantentrennung, Rollenmodelle und komplexe Geschäftsprozesse benötigen manuelle Reviews durch Personen, die Anwendung und Schutzbedarf verstehen.

Orientierung bietet die OWASP Top 10 als Übersicht häufiger Risiken. Für konkrete Entwicklungsanforderungen ist der OWASP Application Security Verification Standard besonders hilfreich. Sicherheitsprüfungen wie Penetrationstests sollten auf einem klar definierten Scope, schriftlicher Beauftragung und abgestimmten Regeln beruhen. Ohne ausdrücklichen Auftrag sind Tests an fremden Systemen rechtswidrig. Diese Einordnung ist keine Rechtsberatung.

Passende IT-Security-Seminare und Termine findest du bei uns auf cmt.de.

Praktische Checkliste vor jedem Release

Prüfe vor der Veröffentlichung mindestens diese Punkte:

• Sind alle externen Eingaben serverseitig validiert?
• Werden Ausgaben abhängig vom jeweiligen Kontext sicher kodiert?
• Prüft jede sensible Funktion die Berechtigung auf dem Server?
• Sind Sitzungen, Cookies und Passwort-Speicherung sicher umgesetzt?
• Sind Debug-Ausgaben, Testkonten und unnötige Dienste entfernt?
• Werden Geheimnisse geschützt verwaltet und nicht im Quellcode gespeichert?
• Sind Abhängigkeiten geprüft und bekannte Sicherheitsupdates bewertet?
• Werden sicherheitsrelevante Ereignisse protokolliert, ohne sensible Daten in Logs zu schreiben?
• Gibt es einen Prozess für Schwachstellenmeldungen, Priorisierung und zeitnahe Behebung?

Sichere Webentwicklung ist kein Zustand, den du einmal erreichst und dann abhaken kannst. Anwendungen, Abhängigkeiten und Angriffsmethoden verändern sich laufend. Mit klaren Regeln für Eingaben, Ausgaben, Authentifizierung, sichere Standards und verbindliche Entwicklungsprozesse schaffst du jedoch eine belastbare Grundlage, auf der dein Team sicher weiterentwickeln kann.