Abstract
Es gibt gegenwärtig eine Vielzahl von Anbietern, die es ermöglichen, ein individuelles Formular für eine Webseite ohne großen Aufwand selbst zu erstellen. Allerdings lässt sich dabei in vielen Fällen feststellen, dass es an Interaktivität oder Flexibilität mangelt. Daher wird ein Ansatz vorgestellt, der das Gestalten eines interaktiven Formulars und dessen Einbindung in die eigene Webseite ermöglicht. Die Erstellung des Formulars erfolgt mithilfe eines No-Code-Editors. Anschließend wird es in ein kompaktes Datenformat konvertiert und in einer Datenbank gespeichert. Der Abruf des Formulars beim Zugriff auf die Webseite erfolgt mittels Cross-Origin Resource Sharing (CORS).
Für das Datenformat werden bestehende Ideen gesucht und beurteilt, um darauf basierend eine Lösung zu entwerfen. Es folgt der Aufbau einer Backend-Applikation mit Verbindung zu einer Datenbank, die für die Kundenverwaltung (z.B. Erstellung, Login) sowie das Abspeichern bzw. Abrufen der Daten zuständig ist. Die Funktionsweise und Bedienbarkeit der Applikation soll dabei beschrieben werden. Abschließend wird das Prinzip CORS detailliert erläutert, dies beinhaltet die Betrachtung der Funktionsweise und des Nutzens sowie das Identifizieren möglicher Sicherheitsrisiken.
Ausgangslage und Forschungsfrage
Viele Websites nutzen Formulare als zentralen Einstiegspunkt: Kontaktaufnahme, Angebotserfassung, Anträge oder Support-Tickets starten oft mit strukturierten Eingaben. Sobald sich Fragen jedoch abhängig von vorherigen Antworten ändern sollen, steigen Entwicklungsaufwand und Kosten deutlich. No-Code-Angebote helfen zwar beim schnellen Erstellen, bleiben aber häufig bei Interaktivität, Flexibilität oder Einbettung in bestehende Websites limitiert.
Die zentrale Forschungsfrage lautet: Wie lässt sich ein interaktives, modular aufgebautes Webformular so modellieren und bereitstellen, dass es kompakt gespeichert, effizient ausgeliefert und sicher per CORS in fremde Websites eingebettet werden kann? Nicht behandelt wird die vollständige Umsetzung eines visuellen Editors oder die Gestaltung (Styling) beliebiger Formularelemente bis ins Detail; im Fokus steht die technische Bereitstellungskette von Datenformat, Backend und CORS.
Methodisches Vorgehen
Ausgangspunkt ist die Anforderung, HTML-Formulare nicht als kompletten HTML-Text zu speichern, sondern als kompakte Repräsentation, die Struktur, Reihenfolge, Gruppierung und Interaktionslogik erhält. Dazu werden typische HTML-Formbestandteile (z.B. Labels, Textfelder, Selectboxen, Buttons) und die notwendige Interaktivität (über JavaScript-Events wie onchange/onclick) als Grundlage herangezogen, um ein minimal ausreichendes Datenmodell abzuleiten.
Als Orientierung werden existierende Plattformen betrachtet, die Formulare intern ebenfalls in JSON-Strukturen abbilden. Daraus entsteht ein eigenes JSON-basiertes Format [1], das Formulare in Segmente/Abschnitte ("Parts") und darin enthaltene Elemente zerlegt. Für interaktive Elemente werden zusätzlich Funktionsangaben und Ziel-IDs gespeichert, sodass sich beispielsweise Sichtbarkeit oder Aktivierung anderer Teile steuern lässt.
Für die Bereitstellung wird eine Backend-Applikation in einer MVC-Architektur konzipiert und mit einem verbreiteten Framework umgesetzt [2]. Persistenz und Zugriff erfolgen über eine relationale Datenbank und ein ORM-Ansatz (JPA) [3], sodass Formulare und zugehörige Kontodaten versionierbar abgelegt und über API-Endpunkte abgerufen werden können. Sicherheitsaspekte werden über Authentifizierung/Autorisierung (Token-basiert, z.B. Bearer Tokens) [4] sowie Rate Limiting adressiert.
Da das Formular von einer externen Website geladen wird, wird CORS als Mechanismus zur kontrollierten Freigabe eingesetzt. Grundlage ist dabei das Web-Origin-Konzept [5] und die CORS-Spezifikation [6]. Methodisch wird zwischen Simple Requests und Preflighted Requests unterschieden und die Konfiguration so abgeleitet, dass die Einbettung funktioniert, ohne die Same-Origin-Policy pauschal auszuhebeln.
Die gewonnenen Erkenntnisse
Ein zentrales Ergebnis ist ein JSON-Datenformat, das Formulare in Abschnitte und Elemente strukturiert und dabei notwendige Metadaten (IDs, Typen, Textinhalte) sowie Interaktionslogik (Funktion + Ziel) mitführt. Damit bleibt die Reihenfolge der Elemente ebenso erhalten wie die Möglichkeit, Formularteile abhängig von Eingaben ein- oder auszublenden.
Die kompakte Repräsentation reduziert Redundanzen gegenüber der Speicherung des vollständigen HTML-Codes, weil nur für die Anzeige und Interaktion relevante Informationen enthalten sind. Gleichzeitig bleibt das Format nah genug an Web-Technologien, um die Rekonstruktion in HTML und die Ausführung der Interaktionslogik auf der Client-Seite zu ermöglichen.
Auf Backend-Seite zeigt die Implementierung, dass ein klar getrenntes Modell für Nutzer, Rollen und Formulare ein wartbares Daten- und Rechtekonzept ermöglicht. Formulardaten werden als JSON-String gespeichert und über einen Mapper in Objektstrukturen überführt, sodass API-Endpunkte Formulare erstellen, persistieren und wieder ausliefern können.
Für die Einbettung auf fremden Websites wird CORS so eingesetzt, dass das Formular per GET-Anfrage geladen werden kann. Dabei dient der Origin der anfragenden Website als zentraler Anker für die Zugriffskontrolle: Nur wenn die Domain in der Datenbasis bekannt ist, wird die Antwort mit passenden CORS-Headern ausgeliefert.
Was die Ergebnisse bedeuten
Die Ergebnisse zeigen, dass die Kombination aus kompaktem Datenformat und API-basierter Auslieferung eine praktikable Grundlage für modulare, interaktive Formulare schafft. Besonders wertvoll ist die Trennung zwischen Editor/Erstellung und Auslieferung: Die Website des Kunden benötigt nur eine Einbettung, während Änderungen am Formular zentral gepflegt und versioniert werden können.
Gleichzeitig entstehen Trade-offs: Ein schlankes Format muss bewusst entscheiden, welche HTML-Attribute und welche Formularelemente unterstützt werden. Das vereinfacht Speicherung und Übertragung, begrenzt aber Flexibilität (z.B. Styling oder komplexe Validierungen). Auch die Entscheidung, Zugriffe über den Origin zu steuern, ist in einfachen Szenarien robust, kann aber bei mehreren Formularen pro Domain oder bei komplexeren Mandantenmodellen zusätzliche Identifikatoren erfordern.
Im Sicherheitskontext ist CORS weniger ein "Feature" als eine präzise Konfiguration: Fehlkonfigurationen (zu breite Origins/Headers) können Schutzmechanismen effektiv aushebeln [7]. Eine konservative Policy, konsequente Validierung eingehender Requests und eine bewusste Entscheidung für Preflight-Anfragen in risikoreichen Fällen sind zentrale Maßnahmen, um Angriffsflächen zu reduzieren.
Als Limitation bleibt, dass die betrachtete Umsetzung vor allem die Bereitstellungskette adressiert. Ein vollwertiger No-Code-Editor, umfassende Komponentenbibliotheken und ein belastbarer Betrieb (Monitoring, Auditing, Rotation von Secrets) sind eigenständige Bausteine, die für den Produktiveinsatz ergänzt werden müssen.
Kernaussagen und Ausblick
Ein kompaktes JSON-Datenformat kann interaktive Webformulare so beschreiben, dass Struktur und Logik erhalten bleiben und dennoch effizient gespeichert und ausgeliefert werden können. Ein API-Backend mit klaren Datenmodellen und Token-basierter Absicherung bildet die technische Grundlage, um Formulare zentral zu verwalten und kontrolliert bereitzustellen. CORS ermöglicht die Einbettung auf fremden Websites, erfordert aber eine strikte, bewusst eng gefasste Konfiguration. Die Arbeit zeigt damit einen gangbaren Weg, interaktive Formulare als No-Code-Baustein in bestehende Webpräsenzen zu integrieren.
Die Betreuung und fachliche Unterstützung durch Stack1 GmbH kann helfen, solche Konzepte sicher und wartbar in die Praxis zu übertragen.