White-Label-Seiten-Builder mit GrapesJS

Die Standard-Demo, ungestylt und ohne Branding. Das ist der Ausgangspunkt, von dem jeder White-Label-Build ausgeht – und der, den Ihre Kunden niemals sehen sollten.

White-Labelling wird üblicherweise als Logo-Tausch beschrieben. Das ist es nicht. Vergleichen Sie die beiden folgenden Frames: gleiche Leinwand, gleiche Drag-and-Drop-Steuerung, gleiche Stilsteuerung – und zwei völlig unterschiedliche Produkte aus der Sicht der Person, die sie nutzt.

Ihre Nutzer sollten das Gefühl haben, Ihr Produkt zu benutzen – nicht als einen Drittanbieter-Editor, der zufällig darin eingebettet ist.

Ein White-Label-Seiten-Builder ist ein visuelles Seitenbearbeitungssystem, das in ein anderes Produkt integriert und an seine Marke, das Nutzererlebnis und die Geschäftsregeln angepasst werden kann.

Der Begriff stammt aus der Fertigung, wo ein White-Label-Produkt von einem Unternehmen hergestellt und unter dem Namen eines anderen Unternehmens verkauft wird. Auf Software angewandt bedeutet das, dass die Bearbeitungs-Engine eine Abhängigkeit ist, die Ihr Team auswählt, und alles, was der Kunde wahrnimmt – die Benutzeroberfläche, der Wortschaschatz, die Inhaltsbibliothek, die Regeln, wer was tun darf – gehört Ihnen. Ein White-Label-Page-Builder ist daher weniger ein Produkt, das Sie installieren, als vielmehr ein Produkt, das Sie selbst zusammenstellen.

White-Label ist mehr als nur ein Logo zu ändern. Jeder oben genannte Punkt ist eine Entscheidung darüber, wem eine Ebene des Erlebnisses gehört – und ein Erbauer, der beim Logo aufhört, ist immer noch das Werkzeug von jemand anderem.

Ein White-Label-Build ist ein Stapel von Schichten, und es lohnt sich, genau zu sagen, welche davon eine visuelle Bearbeitungsmaschine liefern kann und welche nicht. Lesen Sie den Stapel von oben nach unten: was Ihr Kunde sieht, bis hin zu dem Ort, an dem sich die veröffentlichte Seite schließlich befindet.

Die Editor-Engine ist die einzige Ebene, die du nicht aufbauen musst. Jede zweite Schicht ist der Ort, an dem sich dein Produkt tatsächlich abhebt – was ein guter Grund ist, nicht ein Jahr damit zu verbringen, das bereits gelöste Produkt neu aufzubauen.

Derselbe Stack, aufgelistet. Drei Spuren: Was dir die Engine direkt bietet, was eine Erweiterung bieten kann und was nur deine Anwendung besitzen kann. Die dritte Spur ist die ehrliche – und dort stellt ein Unternehmenskäufer seine Fragen.

Nichts in der rechten Spur ist eine Lücke im Editor – diese Fähigkeiten hängen von deinen Konten, deinem Mietmodell und deiner Infrastruktur ab, sodass keine Bearbeitungsmaschine sie für dich entscheiden kann.

Dein Kunde öffnet nie einen Editor. Er öffnet dein Produkt, geht auf deren Seiten, wählt eine Vorlage und beginnt mit dem Bearbeiten – und die Bearbeitungsmaschine ist zufällig das, was die Leinwand mitten in dieser Reise zeichnet.

GrapesJS kann im Hintergrund arbeiten, während Ihre Kunden mit Ihrem Produkterlebnis interagieren.

GrapesJS übernimmt die visuelle Bearbeitungsebene. Ihre Anwendung übernimmt die Geschäftslogik darum herum – und die Grenze zwischen beiden ist die wichtigste Designentscheidung im gesamten Build.

Wenn mehr als ein Kunde Ihren Builder nutzt, hört Tenancy auf, ein Implementierungsdetail zu sein. Jede Organisation benötigt ihre eigenen Seiten, ihre eigene Asset-Bibliothek, eigene Vorlagen und ihre eigene Marke – und muss strukturell nicht in der Lage sein, die von anderen zu erreichen.

• Mandantenisolation

  Jedes Projekt, jedes Asset und jede Vorlagenzeile ist auf eine Organisation zugeschnitten, und der Umfang wird serverseitig angewendet – nicht durch Filterung im Browser.

• Projekte

  Die Seiten eines Tenants sind Zeilen in deiner Datenbank. Der Editor lädt jeweils ein Projekt und schreibt es über dein API zurück.

• Asset-Bibliotheken

  Uploads landen in einem Präfix oder Bucket pro Mandant, sodass das Medium eines Kunden niemals im Picker eines anderen Kunden auftauchen kann.

• Template-Sets

  Vorlagen können global, tarifspezifisch oder privat für eine Organisation sein, was oft genau das ist, was ein Plan-Upgrade tatsächlich freischaltet.

• Pro Mandant-Branding

  Farben, Schriftarten und Logos lösen sich je nach Organisation auf, sodass die Kunden einer Agentur jeweils ihre eigene Identität in derselben Implementierung sehen.

• Veröffentlichungsziele

  Wo die Seiten eines Tenants veröffentlicht werden – Pfad, Subdomain oder benutzerdefinierte Domain – ist die Konfiguration, die deine Anwendung auflöst.

GrapesJS hat kein eingebautes Konzept von Tenants. Es bearbeitet jeweils ein Projekt; die Isolation, das Scoping und die Berechtigungsprüfungen rund um dieses Projekt werden in Ihrer Anwendung implementiert und von Ihrem Backend durchgesetzt.

Die Anpassung geht tiefer, als die meisten Teams planen. Diese vier Stufen sind nach ihrer Sichtbarkeit geordnet, nicht nach dem Aufwand, den sie erfordern – und die letzte ist diejenige, die ein umbenanntes Tool von einem Produkt trennt, das sich eigenständig anfühlt.

• 01

  Visuelle Identität

  Die Schicht, mit der jeder beginnt. Notwendig und allein nie ausreichend.

  • Logo
  • Farben
  • Typografie
  • Icons
• 02

  Editor UI

  Das Chrom um die Leinwand. Paneele können umgestellt, ersetzt oder durch eigene Komponenten gerendert werden.

  • Panels
  • Symbolleiste
  • Navigation
  • Befehle
  • Menüs
• 03

  Inhaltssystem

  Was Nutzer tatsächlich auf einer Seite platzieren können. Hier hört ein Builder auf, generisch zu sein.

  • Blöcke
  • Komponenten
  • Vorlagen
  • Presets
• 04

  Produktsprache

  Die Worte. Ein Nutzer, der Ihren Wortschatz überall liest, bemerkt nie, dass sich darunter ein Engine befindet.

  • Bezeichnungen
  • Terminologie
  • Benutzerflüsse
  • Onboarding

Die Interface-Strings des Editors sind übersetzbar und die Panels konfigurierbar, sodass die ersten beiden Level Konfiguration und keine Forks sind. Der Kern ist BSD-3-Clause-lizenziert und selbstgehostet, was die tieferen Levels überhaupt möglich macht.

Ein Entwickler, der an Teams ausliefert, benötigt mehr als eine Art von Nutzer. Diese fünf Rollen decken die meisten Produkte ab; die Namen sind weniger wichtig als die Tatsache, dass jedes einzelne auf einen anderen Satz sichtbarer Panels, verfügbarer Blöcke und Veröffentlichungsrechte beschränkt ist.

In einem Single-User-Tool sind Bearbeiten und Veröffentlichen dieselbe Aktion. Bei einem Produkt, das an Teams verkauft wird, sind es separate Bundesstaaten mit getrennten Rechten – und diese Trennung ist meist das Erste, wornach ein Unternehmenskäufer fragt.

Redakteure können Inhalte erstellen, während nur autorisierte Nutzer sie veröffentlichen dürfen – ein Satz, der überraschend viele Geschäftsabschlüsse entscheidet.

Der Kern liefert absichtlich eine leere Blockpalette: Ein generisches Blockset wäre für jedes Produkt, in das es geworfen wurde, falsch. Was du in diese Palette einfügst, ist die produktspezifischste Entscheidung im ganzen Build.

• Hero

  Dein Eröffnungsabschnitt, mit den Feldern, die dein Produkt tatsächlich verwendet.

• Preise

  Plane Tabellen, die aus deinen eigenen Preisdaten ablesen können.

• Erfahrungsberichte

  Social Proof legt dar, wie Ihre Marke es präsentiert.

• Funktionsraster

  Ein wiederholbares Raster, das Ihre Nutzer nicht versehentlich brechen dürfen.

• FAQ

  Frage-und-Antwort-Paare, erweiterbar auf der veröffentlichten Seite.

• Kontakt

  Ein Formular, das an Ihren Endpunkt verkabelt ist, nicht an das eines Drittanbieters.

• CTA

  Der Conversion-Block, der auf deine Button-Stile festgelegt ist.

• Footer

  Ein gemeinsamer Footer, der auf jeder Seite einheitlich bleibt.

Vorlagen sind die Art und Weise, wie ein Bauer seinen Nutzern beibringt, wie gut aussieht. Eine leere Leinwand wirkt einschüchternd; ein Vorlagenset, das um die Aufgaben Ihrer Kunden herum gebaut ist, ist ein Produktfeature.

Das sind Arten von Vorlagen, die ein Bauer typischerweise aussendet, keine Kataloglisten. Was dein Set enthält, sollte auf dem basieren, was deine Kunden am häufigsten veröffentlichen.

Für Agenturen und Website-Plattformen ist die veröffentlichte Seite mit der eigenen Domain des Kunden das Produkt. Es handelt sich auch ausschließlich um eine Infrastrukturangelegenheit – es lohnt sich, frühzeitig zu entwerfen, denn das Nachrüsten von Domain-Routing in einen Live-Builder ist unangenehm.

• Eine Domäne ist eine Tenant-Konfiguration

  Speichere den Hostnamen im Arbeitsbereich, verifiziere die Eigentümerschaft und leite dann eingehende Anfragen darauf an die veröffentlichten Seiten dieses Tenants weiter.

• Zertifikate stehen zur Automatisierung zur Verfügung.

  Das Ausstellen und Erneuern von Zertifikaten pro Kundendomain liegt in der Plattformverantwortung, egal ob Sie es selbst ausführen oder an einen Host delegieren.

• Veröffentlichen kann ein Einsatz sein

  Einige Teams rendern Seiten aus ihrer eigenen Datenbank; andere übertragen die generierte Ausgabe auf einen statischen Host. Beide Muster funktionieren, und eine Plugin-Familie automatisiert bereits die zweite.

• Vorschau vor der Existenz der Domain

  Gib jeder Seite von Anfang an eine plattformgehostete Vorschau-URL, damit Überprüfung und Genehmigung nie auf DNS warten.

Keine visuelle Bearbeitungsbibliothek bietet Domain-Hosting an. GrapesJS emittiert Seiten; DNS, Zertifikate, Routing und Caching bleiben bei Ihrer Infrastruktur oder Ihrem Hosting-Anbieter.

Sobald zwei Personen dieselbe Seite bearbeiten können, wird jemand fragen, wer sie geändert hat. Ein Aktivitätspfad ist günstig hinzuzufügen, während man das Speichern und Veröffentlichen entwirft, und teuer, um sie danach wieder zu rekonstruieren.

Illustrative Zeilen. GrapesJS hat kein Audit-Log; die Spur wird von Ihrer Anwendung geschrieben, wenn sie einen Speicherstand, eine Genehmigung oder eine Veröffentlichung verarbeitet, was auch der einzige Ort ist, an dem bekannt ist, welcher Benutzer handelt.

Lesen Sie den Stack als Build-Reihenfolge. Jede Sprosse wird entweder von der Engine geliefert, ist als Plugin verfügbar oder arbeitet, die nur Ihr Team erledigen kann – und ehrlich zu sein, was das ist, was eine Schätzung den Kontakt mit dem Projekt überstehen lässt.

1. Editor-EngineOpen Source
2. White-Label-Theme & benutzerdefiniertes UIPlugin
3. Benutzerdefinierte BlöckePlugin
4. VorlagenPlugin
5. Rollen & BerechtigungenDeine App
6. SpeicherPlugin
7. AssetsPlugin
8. AuditprotokolleDeine App
9. ExportPlugin
10. VeröffentlichungPlugin

Zwei Sprossen haben keine Katalog-Antwort, und das ist beabsichtigt und kein Versehen: Rollen und Audit-Logging hängen von deinem Identitätsmodell und deiner Datenbank ab, also sind sie Anwendungsarbeit. Wenn das der Teil ist, den dein Team lieber nicht allein bauen möchte, dann gibt es genau dafür Implementierungsdienste.

Jede untenstehende Listing ist ein echtes Produkt auf GJS.Market, gruppiert nach der Aufgabe, die es in einem White-Label-Build erfüllt.

Marke

Ersetzen Sie die Standardoberfläche: benutzerdefinierte Panels, eine maßgeschneiderte Shell oder einen Editor, der von Ihren eigenen Komponenten gerendert wird.

Durchstöbern Sie diese Kategorie

Grapesjs Wix Like

Eine Builder-Oberfläche im Consumer-Stil, ausgeliefert als Preset – dieselbe, die in der Demo oben läuft, falls deine Nutzer keine Entwickler sind.

199,99 $View-Plugin

Grapesjs Paneless

Eine komplette alternative Editor-Hülle, die sowohl als Versandoption als auch als Beweis dafür nützlich ist, wie weit der Chrome getragen werden kann.

299,99 $View-Plugin

React UI for GrapesJS

Rendere die Editor-Oberfläche mit deinen eigenen React-Komponenten, sodass der Builder dein Design-System erbt, anstatt es zu approximieren.

KostenlosView-Plugin

Borders Color

Bringen Sie das Auswahl-Highlight in Einklang mit den Farben Ihrer Marke – ein kleines Detail, das still und leise einen ungebrandeten Editor verrät.

KostenlosView-Plugin

Inhalt

Die Blöcke, Abschnitte und Vorlagen, mit denen Ihre Nutzer schreiben – sowie die Seiten- und Symbolverwaltung um sie herum.

Durchstöbern Sie diese Kategorie

Users Blocks

Lass Nutzer ihre eigenen Abschnitte als wiederverwendbare Blöcke speichern, so wächst die Blockbibliothek eines Kunden, ohne dass dein Team jeden einzelnen aussendet.

59,00 $View-Plugin

Templates Manager

Verwalten Sie das Template-Set, von dem Ihre Nutzer beginnen, pro Produkt oder pro Kunde.

39,00 $View-Plugin

Symbols

Wiederverwendbare verknüpfte Abschnitte: Aktualisieren Sie einen Header einmal, und jede Seite, die sie enthält, folgt.

KostenlosView-Plugin

Pages Manager

Mehrseitige Projekte in einer Bearbeitungssitzung, was die meisten Kundenarbeitsplätze tatsächlich benötigen.

25,00 $View-Plugin

Infrastruktur

Wo Projekte und Assets liegen und wie die Ausgabe den Editor verlässt.

Durchstöbern Sie diese Kategorie

Directus Storage

Persistiere Projekte auf einem headless Backend statt auf Browserspeicher – ein ausgearbeitetes Beispiel für die Storage Seam.

KostenlosView-Plugin

Grapesjs Cloudinary

Routen Sie die Asset-Bibliothek über verwaltete Medienspeicher, mit per-tenant-Ordnern auf Ihrer Seite.

KostenlosView-Plugin

Export Zip

Geben Sie den Nutzern ein herunterladbares Archiv der von ihnen erstellten Seite, inklusive Markup und Stile.

KostenlosView-Plugin

Storage Rate Limit

Drosseln Sie, wie oft Projekte zurückgeschrieben werden, was wichtig ist, sobald viele Tenants gleichzeitig bearbeiten.

KostenlosView-Plugin

Veröffentlichung & Betrieb

Projekte, Einsatzziele, Wiederherstellung und die kleinen Details, die einen Editor fertig wirken lassen.

Durchstöbern Sie diese Kategorie

Grapesjs Project Manager

Verwalten Sie mehrere Projekte in einer Editor-Instanz – das, was einer Workspace-Shell im Katalog am nächsten kommt.

KostenlosView-Plugin

Grapesjs Netlify

Bereite die gebaute Seite direkt vom Editor aus auf einen statischen Host als Veröffentlichungsmuster zur Anpassung bereit.

KostenlosView-Plugin

Autosave & Restore — Crash Recovery for GrapesJS

Autosave mit Wiederherstellung, also ist ein verlorener Tab kein verlorener Nachmittag für deinen Kunden.

12,00 $View-Plugin

Custom Fonts

Laden Sie Ihre eigenen Schriftarten in den Editor, damit das, was Nutzer beim Bearbeiten sehen, mit dem übereinstimmt, was Besucher erhalten.

KostenlosView-Plugin

Drei Kombinationen, die immer wieder auftauchen. Keine davon ist ein Bündel – sie sind Ausgangspunkte, und jede einzelne braucht immer noch deine Anwendung darum herum.

Die Preise sind die Marktplatzpreise zum Bauzeitpunkt und werden zur Orientierung angezeigt.

GrapesJS bietet die Grundlage für visuelles Bearbeiten. GJS.Market-Plugins können spezialisierte Funktionen hinzufügen, ohne dass dein Team jede Funktion intern bauen muss. Beide unten genannten Wege sind legitim – die Frage ist, welche Teile des Stacks wirklich dein Unterscheidungsmerk sind.

Feature für Feature, was du selbst im Vergleich zu dem schreiben würdest, was eine etablierte Engine bereits offenlegt. Die als Anwendungsebene markierten Zeilen sind die ehrliche Hälfte dieser Tabelle: Eine Bearbeitungs-Engine kann sie nicht besitzen, also liegen sie auf deinem Teller.

Die Urteile spiegeln die aktuelle Version wider, neu verifizierte 2026-09-02. "Anwendungsschicht" bedeutet, dass die Funktion von deinen Konten und Infrastruktur abhängt, nicht dass sie fehlt.

Drei verwandte Entscheidungen, die besprochen werden, als wären sie eins. Sie stapeln sich, statt zu konkurrieren: Die meisten Produkte machen am Ende alle drei in dieser Reihenfolge.

Sobald der Bauunternehmer Ihnen gehört, ist auch die geschäftliche Beziehung darum herum. Wie Sie es gestalten, ist eher eine geschäftliche als eine technische – aber es lohnt sich, sie zu treffen, bevor das Mietmodell in Beton festgelegt wird, denn Pläne und Begrenzungen sind Mietfragen.

Eine konventionelle vierstöckige Form, die die Mietvertragsimplikationen konkret macht, anstatt eine Preisliste vorzulegen.

1. 01

   Kostenlos

   Ein Arbeitsbereich, ein kleines Seitenlimit, plattformgehostete Vorschau-URLs.

2. 02

   Pro

   Mehr Seiten, das komplette Template-Set, eine eigene Domain.

3. 03

   Team

   Mehrere Sitze, Rollen und ein Genehmigungsschritt vor der Veröffentlichung.

4. 04

   Unternehmen

   Mehrere Organisationen, eine Audit-Spur, individuelle Blöcke und Unterstützungsbedingungen.

Nur illustrativ. Was zu welcher Stufe gehört, hängt von Ihrem Markt ab – aber beachten Sie, wie viel der Leiter aus den Erlaubnis- und Mietfunktionen von zuvor auf dieser Seite besteht.

Sie kontrollieren Ihre Preisgestaltung, Ihre Pläne und Ihre Kundenbeziehung.

Ein White-Label-Build stellt Anforderungen, die ein geschlossener Editor nicht erfüllen kann. Du musst die Schnittstelle ändern, sie auf deiner eigenen Infrastruktur ausführen und sie mit Systemen integrieren, von denen der Anbieter noch nie gehört hat. Der Kern ist BSD-3-Clause-lizenziert und selbsthostbar, was all das möglich macht.

• Anpassung

  Die Benutzeroberfläche ist Markup und Konfiguration, die man lesen, ersetzen und erweitern kann – nicht eine Black Box mit einem Theming-API.

• Selbsthosting

  Der Editor läuft dort, wo deine Anwendung läuft, sodass Projekte und Assets deine Infrastruktur nie verlassen müssen.

• Erweiterbarkeit

  Eine dokumentierte Plugin-Architektur sowie ein Ökosystem bestehender Plugins zum Anpassen, statt von dort auszugehen.

• Integrationsfreiheit

  Speicher, Assets und Befehle sind Lücken, die du auf deine eigenen Dienste verweisen lässt.

• Kontrolle über die Infrastruktur

  Bereitstellung, Upgrades und Datenort sind Ihre Entscheidungen und nach Ihrem Zeitplan.

• Prüfbarkeit

  Sie können den Code lesen, den Sie an Kunden verschicken, was zunehmend eher eine Beschaffungsanforderung als eine Präferenz ist.

Der Editor ist eine Browser-Bibliothek, also geht er dorthin, wo sich deine Anwendung bereits befindet. Diese Seiten behandeln die Mechaniken pro Framework – Mounten, Aufbereiten und den Editor-Status außerhalb deiner Render-Schleife.

• React

  Den Editor in einem Komponentenbaum mounten, ohne dass er gegen deinen Renderzyklus kämpft.

  React-Seiten-Builder

• Next.js

  Client-only Editor, server-gerenderte veröffentlichte Seiten und die Grenze zwischen ihnen.

  Next.js-Seiten-Builder

• Vue

  Lebenszyklus, Referenzen und Zerlegung, wenn der Editor in einer Vue-Komponente lebt.

  GrapesJS mit Vue

• Angular

  Komponentenaufbau, Änderungserkennung und -bereinigung in einer Angular-Anwendung.

  GrapesJS mit Angular

• Einfaches JavaScript

  Kein Framework überhaupt – ein Script-Tag, ein Container-Element und ein Init-Aufruf.

  Fang mit den Basics an

Ein Bauer hat zwei Laufzeiten mit fast nichts gemeinsam, und sie als eine zu behandeln, ist der häufigste Leistungsfehler bei dieser Art von Produkt.

• Lazy-Load den Editor

  Lade das Bearbeitungsbundle, wenn ein Benutzer den Editor öffnet, nicht wenn er dein Dashboard öffnet.

• Halte den Editor-Status aus deinem Anwendungszustand heraus

  Der Editor verwaltet seinen eigenen Baum. Wenn du ihn in deinen globalen Store spiegelst, renderst du deine Anwendung bei jedem Tastendruck neu.

• Paginate große Asset-Bibliotheken

  Ein Mandant mit Tausenden von Bildern benötigt einen paged, durchsuchbaren Auswähler statt einer langen Liste.

• Lazy-load-lastlastige Plugins

  Rich-Text-Engines, Code-Editoren und Bildwerkzeuge lohnen sich, bis das benötigte Panel geöffnet ist.

• Trennen Sie die Laufzeiten

  Nichts, was der Editor benötigt, gehört in das Bundle, das ein Besucher für eine veröffentlichte Seite herunterlädt.

• Unabhängige Optimierung des veröffentlichten Outputs

  Bilder, kritisches CSS und Caching für veröffentlichte Seiten werden von deiner Rendering-Ebene bestimmt, auf der du die volle Kontrolle hast.

Die Autorenumgebung und die veröffentlichte Website müssen nicht dieselben Laufzeitanforderungen haben.

Ein Multi-Tenant-Builder akzeptiert nicht vertrauenswürdige Inhalte und erstellt Seiten, die andere Leute laden. Beide Hälften verdienen Aufmerksamkeit, und der Großteil der Arbeit liegt auf deiner Seite der Grenze.

• Authentifiziere jeden API-Anruf

  Projektlade, Speichern, Asset-Upload und Veröffentlichen sind alles Endpunkte, die eine authentifizierte Sitzung erreicht – und alle es lohnt sich, auch so behandelt zu werden.

• Validate Permissions serverseitig

  Überprüfe nochmal auf dem Server, was die Oberfläche bereits versteckt hat. Ein versteckter Button ist eine UX-Möglichkeit, keine Zugriffskontrolle.

• Isoliere Tenant-Daten

  Bereiche jede Abfrage nach Organisation und bevorzuge einen Bereich, der unmöglich ausgelassen werden kann, gegenüber einem, an den sich jeder Entwickler erinnern muss.

• Uploads validieren

  Überprüfe Typ, Größe und Erweiterung serverseitig und bereitstelle Benutzermedien von einem separaten Ursprung aus, wo möglich.

• Nutzerinhalte bereinigen

  Ein visueller Builder kann beliebige Markups erstellen. Entscheide bewusst, ob benutzerdefinierte Skripte erlaubt sind, und bereinige entsprechend.

• Schützen Sie Veröffentlichungs-Endpunkte

  Das Veröffentlichen verändert, was die Öffentlichkeit sieht. Begrenze den Tarif, autorisiere ihn explizit und notiere den Auslöser.

• Projektdaten validieren

  Ein gespeichertes Projekt ist Benutzereingabe. Validiere seine Form, bevor du es speicherst oder neu renderst.

• Vertrauen Sie niemals auf clientseitige Berechtigungen

  Die Blockliste und das Panelset sind Konfigurationen, über die der Browser lügen kann.

Dies ist eine Startcheckliste speziell für einen Builder, kein vollständiges Sicherheitsprogramm, und keine Architektur ist durch Konstruktion sicher. Behandeln Sie einen White-Label-Builder wie jede andere Multi-Tenant-Anwendung, die Benutzerinhalte akzeptiert.