Hakuna matata!

Das würde bedeuten, dass ich mich von der Idee verabschieden muss, einfach eine Wiki-Seite nach Beispielen zu parsen, um diese dann in ein Fiddle zu laden. Das Fiddle kann dann nur "echte" Beispiele parsen, die als eigenständige HTML-Dokumente ins Wiki hochgeladen wurden. Das würde die Sicherheit wesentlich steigern.

Definitiv, ich wusste bisher gar nicht, dass die ausführbaren Beispiele nur von ein paar wenigen Mitgliedern erstellt werden können. Aber das macht natürlich vieles einfacherer.

Und wenn wir schon eine JavaScript-Spielweise bauen, dann sollten wir auch direkt das volle Potenzial ausschöpfen und keine exklusive Lösung für das Wiki bauen, sondern gleich auch an das Forum denken.

Warum sollten wir das?

Weil wir so mit der Zeit eine wunderschöne Sammlung von Online-Beispielen erhalten würden, von denen man das ein oder andere bestimmt auch ins Wiki migrieren könnte. Aber mit dem zusätzlichen Aufwand, den das machen würde, weil Sicherheit dann ja doch wieder ein heikles Thema wäre, lässt sich der Nutzen wohl nicht rechtfertigen.

"allow-same-origin" darf nicht gesetzt sein, wenn wir den Fiddle-Server unter der selben Domain wie das Wiki betreiben, denn das würde dem Skript erlauben aus der Sandbox auszubrechen.

Mein Code erstellt das Iframe-Element dynamisch: <iframe src="about:new" />

Das sandbox-Attribut hat auf zur Laufzeit erstelle <iframe>s sowieso keine Auswirkung.

Es sollte also unter der entsprechenden Domain gelten. Und wenn man nichts weiter angibt, dann sollte JavaScript doch seine Same-Origin-Policy anwenden, oder nicht? Damit sind Fremdscripte ausgeschlossen. Und das finde ich prima!

Die SOP schützt deine Seite nicht davor, dass darin fremde Ressourcen eingbettet und ggf. ausgeführt werden können. Ein Angreifer, dem es gelingt ein Skript von seinem Server in eine fremde Seite einzubetten, der kann seinen Server auch so konfigurieren, dass das Skript mit entsprechenden CORS-Headern ausgeliefert wird, auf diese Weise wird das Skript auch unter der attackierten Seite ausführbar. Die SOP schützt nicht vor XSS-Anriffen, sondern vor Cross-Site-Reuqest-Forgery-Angriffen.

"allow-same-origin" hat übrigens nichts mit der SOP zu tun.

In meinem OP hatte ich ja ganz klar umrissen, dass ich mich ganz streng auf Wiki-Beispiele beschränken will (siehe fehlender "speichern"-Button). Wenn das Fiddle außerdem nur offizielle Beispieldokumente verarbeiten kann, die ausschließlich von dazu berechtigten Autoren erstellt und hochgeladen werden können, dann sollte der Sicherheitsaspekt einigermaßen gefrühstückt sein.

Oder wüsste da jemand noch weitere Aspekte zu?

Gut, das hatte ich erst anders verstanden. Wenn der Dienst sowieso nur von einem vertrauenswürdigem Benutzerkreis gefüttert wird, dann kann ich meine anfänglichen Sorgen begraben.