Die richtig kniffligen Probleme tauchen meist erst in der eigentlichen Umsetzungsphase auf. Da wir bei RichPods auch interaktive Grafiken zulassen möchten, muss hier eine flexible und zugleich mächtige Chart-Library eingesetzt werden. Hier bietet sich Apache ECharts an, eine quelloffene JavaScript-Bibliothek für Datenvisualisierungen im Web.

ECharts ermöglicht die Darstellung interaktiver Diagramme und Charts (Linien, Balken, Scatter, Karten, 3D-Visualisierungen, Boxplots, etc.) durch deklarative JSON-Objekte. Die Bibliothek zeichnet sich so durch hohe Flexibilität, umfangreiche Anpassungsmöglichkeiten und gute Performance auch bei großen Datenmengen aus. Aus Developer-Sicht positioniert sich ECharts damit zwischen der Low-Level-Flexibilität vom altbekannten D3.js und der Einfachheit von beispielsweise Chart.js. Im Vergleich zu kommerziellen Lösungen wie Highcharts ist ECharts vollständig Open Source und kostenlos, bietet dabei trotzdem ähnliche Enterprise-Features (die wir bei RichPods aber nicht brauchen). Unter dem Schirm der Apache Software Foundation profitiert ECharts von einem langjährig etablierten Governance-Modell, welches die Herstellerneutralität garantiert und verhindert, dass ein einzelnes Unternehmen die Kontrolle übernimmt.

Wie gesagt ist ECharts eine sehr mächtige und umfangreiche Library zum Erstellen von Grafiken im Web – das zeigt schon ein Blick auf die Beispielseite in der Dokumentation. Diese Mächtigkeit wird allerdings zum Problem, wenn unsere User eigene Daten hochladen und visualisieren können. Was auf den ersten Blick wie ein Standard-Validierungsproblem aussieht, entpuppt sich schnell als eines der komplexesten Sicherheitsthemen in unserer RichPods-Umsetzung.

• Wie viel Flexibilität ist erlaubt, wo schränken wir bewusst stark ein?
• Mit welchen Methoden müssen wir die Uploads kontrollieren?
• Wie schaffen wir eine zuverlässige Validierung?

Ab in die Sandkiste

Daher haben wir für RichPods nach einer sicheren Lösung gesucht und nach mehreren Iterationen einen Sandbox-Ansatz verfolgt. Das Paket @richpods/echarts-sandbox adressiert genau die Sicherheitsprobleme, die zuvor aufgezeigt wurden. Es löst das Dilemma zwischen Flexibilität und Sicherheit auf Browser-spezifische Weise: Unsere „echarts-sandbox“ rendert Charts in einem iframe mit sandbox="allow-scripts" – also ohne Zugriff auf das DOM einer Webseite, Cookies oder Local Storage. So können auch unsichere ECharts-Konfigurationen in einem sicheren Kontext gerendert werden. Statt jede mögliche Injection-Stelle im JSON zu prüfen, vertrauen wir auf Browser-Sandboxing als harte Sicherheitsgrenze.

Die iframe-Isolation ist kein Allheilmittel, die Nachteile sind offensichtlich. Dieser Ansatz hat seinen Preis. Mehr Speicherverbrauch, etwas umständlicheres Styling, eingeschränkter API-Zugriff:

• Es gibt einen gewissen Performance-Overhead, der durch das Rendering im iframe auftritt. Die Kommunikation muss über postMessage erfolgen, was einen Umweg darstellt.
• Die ECharts-API steht nicht direkt zur Verfügung.
• Debugging ist schwieriger, weil der iframe in seinem eigenen Kontext ausgeführt wird.

Das Fazit: Vertraue niemals User-Uploads

Die Sicherheitsfrage bei nutzergenerierten ECharts-JSON-Konfigurationen lässt sich nicht durch klassische Input-Validierung lösen. Dafür ist die Bibliothek ganz einfach zu mächtig, lässt zu viele Konfigurationsvarianten zu und die Angriffsfläche wird zu groß. Statt einer endlosen Blocklist setzen wir bei RichPods auf Browser-Sandboxing: Die Chart-Konfiguration wird in einem isolierten iframe ausgeführt, ohne Zugriff auf DOM, Cookies oder Storage der Hauptanwendung.

Nicht jedes Problem lässt sich durch sorgfältigeres Prüfen lösen: Wenn Validierung zu komplex wird, ist Isolation oft der robustere Weg.