Formatierte Texte in der Web-App: Was darf der Editor speichern und anzeigen?

Wenn Mitarbeitende Anleitungen, Produkttexte oder Kundeninformationen selbst bearbeiten sollen, ist ein Texteditor mit Formatierungsleiste oft sinnvoll. Legen Sie trotzdem vor der Umsetzung fest, welche Inhalte er tatsächlich erlaubt und wie die gespeicherten Texte später ausgegeben werden. Eine Vorschau, die ordentlich aussieht, beweist noch nicht, dass eingefügter Inhalt in allen Ansichten sicher verarbeitet wird.

Die Entscheidung lautet nicht nur „Textfeld oder Editor“. Sie betrifft einen erlaubten Inhaltsumfang, nachvollziehbare Änderungen beim Einfügen und die technische Verarbeitung jeder späteren Ausgabe. Dieser Beitrag beschreibt Anforderungen für die Beauftragung. Er ist weder eine Sicherheitsprüfung Ihres Systems noch ein Versprechen, dass eine einzelne Bibliothek sämtliche Angriffe verhindert.

Mit dem benötigten Inhalt beginnen

Nehmen Sie einen erfundenen Text aus dem geplanten Arbeitsablauf. Braucht er Absätze, Zwischenüberschriften, Listen, Hervorhebungen und Links? Sind Tabellen oder Bilder wirklich notwendig? Oder reicht einfacher Text, weil die spätere Anzeige ohnehin eine feste Struktur hat?

Vereinbaren Sie eine überschaubare Liste erlaubter Elemente. Freie Schriftgrößen, beliebige Farben und eigene Seitengestaltung sind nicht automatisch nötig, nur weil der gewählte Editor sie anbietet. Eine kompakte Auswahl erleichtert einheitliche Inhalte, ersetzt aber keine technische Sicherheitskontrolle.

Beschreiben Sie außerdem den Unterschied zwischen einer echten Zwischenüberschrift und einem nur groß dargestellten Absatz. Der Editor sollte die benötigte Struktur unterstützen, statt Mitarbeitende dazu zu zwingen, jeden Abschnitt mit Leerzeilen und Fettschrift nachzubauen. Das ist eine Anforderung an Ihre Umsetzung, keine durch eine Sicherheitsquelle zugesicherte Editorfunktion.

Einfügen aus anderen Programmen bewusst behandeln

Teams kopieren häufig aus Textverarbeitung, E-Mails oder Webseiten. Vereinbaren Sie, ob dabei nur Text oder auch freigegebene Formatierung übernommen wird. Nicht erlaubte Darstellung sollte vorhersehbar entfallen, ohne stillschweigend wichtige Wörter oder die Bedeutung einer Liste zu verändern.

Zeigen Sie dem Entwickler Beispiele mit verschachtelten Listen, langen Links, Sonderzeichen und unerwarteten Formatierungen. Ein Beispiel darf keine vertraulichen Kundendaten enthalten. Entscheiden Sie auch, ob externe Bilder überhaupt übernommen werden sollen oder ob Bilder einen gesonderten, kontrollierten Einfügeweg benötigen.

Nach dem Speichern und erneuten Öffnen muss klar sein, welche Fassung tatsächlich gilt. Eine nur lokal schöne Vorschau hilft wenig, wenn nach dem nächsten Laden andere Formatierung erscheint. Bei größeren Bereinigungen kann eine verständliche Rückmeldung sinnvoll sein. Deren Umfang gehört ins Briefing.

Formatierung erlauben heißt nicht beliebiges HTML ausführen

Das OWASP Cheat Sheet zur Vermeidung von Cross-Site Scripting unterscheidet die Ausgabe von reinem Text von absichtlich erlaubtem HTML. Es erklärt: Eine reine Ausgabekodierung würde bei einem HTML-Editor die gewünschte Formatierung nicht darstellen. Für diesen Fall empfiehlt es HTML-Bereinigung und nennt DOMPurify als geeignete Bibliothek.

Daraus folgt nicht, dass ein Browsereditor oder die Installation dieser Bibliothek die gesamte Anwendung automatisch absichert. OWASP warnt ausdrücklich, dass nachträgliche Änderungen am bereinigten Inhalt den Schutz wieder aufheben können. Auch eine nachgeschaltete Bibliothek darf den Inhalt nicht unkontrolliert verändern. Zudem müssen Bereinigungsbibliotheken aktuell gehalten werden, weil sich Browser und bekannte Umgehungsmöglichkeiten ändern.

Verlangen Sie deshalb vom Entwickler eine nachvollziehbare Beschreibung der Verarbeitung: Wo werden die erlaubten Inhalte geprüft, wo wird bereinigt, was geschieht danach und welche Ausgabewege verwenden das Ergebnis? Eine einfache Ersetzung einzelner verdächtiger Wörter ist kein gleichwertiger Nachweis für diese Verarbeitung.

Alle Ausgabeorte in den Umfang aufnehmen

Derselbe gespeicherte Text kann in der Arbeitsansicht, auf einer öffentlichen Seite, in einer Vorschau oder in einer Benachrichtigung erscheinen. Listen Sie diese Ziele einzeln auf. Ein Inhalt, der für die Darstellung in einem HTML-Textbereich geprüft wurde, ist dadurch nicht für jede andere Einbettung freigegeben.

Vielleicht soll eine Benachrichtigung nur eine reine Textzusammenfassung enthalten. Dann ist diese Ausgabe ein eigener, zu testender Weg. Gleiches gilt für einen Export. Verwechseln Sie insbesondere HTML-Bereinigung nicht mit dem Schutz vor Formelausführung in einer Tabellenkalkulation. Beide betreffen unterschiedliche Empfänger und Auswertungsregeln.

Für ältere gespeicherte Inhalte braucht es ebenfalls eine Entscheidung. Lassen Sie prüfen, ob sie denselben Regeln entsprechen und was vor ihrer erneuten Veröffentlichung geschehen muss. Ändern Sie historische Inhalte nicht ohne nachvollziehbaren Plan und Rückkehrmöglichkeit allein deshalb massenhaft, weil ein neuer Editor eingeführt wird.

Eine brauchbare Abnahme vereinbaren

Testen Sie in einer ausdrücklich dafür freigegebenen, isolierten Umgebung. Ihr Entwickler oder eine qualifizierte Sicherheitsprüfung sollte harmlose, kontrollierte Testinhalte für unerlaubtes Markup und problematische Links vorgeben. Solche Tests gehören nicht in ein laufendes Kundenportal.

Prüfen Sie daneben die normale Arbeit: Text einfügen, bereinigen, speichern, neu öffnen und an jedem vereinbarten Ziel anzeigen. Erlaubte Überschriften und Listen müssen erhalten bleiben; nicht erlaubte Inhalte dürfen nicht unbemerkt wieder auftauchen. Lassen Sie die tatsächlich eingesetzten Bibliotheken und deren Aktualisierungsverantwortung dokumentieren.

Halten Sie diese Ergebnisse in den Abnahmekriterien fest und besprechen Sie die benötigten Ausgabewege bei der Planung Ihrer Web-App. Das Ziel ist verlässlich bearbeitbarer Inhalt mit einem überprüften Verarbeitungspfad. Eine umfangreiche Formatierungsleiste allein ist weder ein Inhaltskonzept noch ein Sicherheitsnachweis.