🛡️ Formular-Schutz & Zugriffskontrolle

propform-Formulare sind standardmäßig öffentlich erreichbar — was sinnvoll ist für Anfragen, Kundenfeedback, Lead-Generierung. Manche Formulare sollen aber nur unter bestimmten Bedingungen geöffnet oder abgesendet werden können. Hier die verfügbaren Schutz-Mechanismen.

Inhalt

• Honeypot & CSRF (automatisch aktiv)
• IP-Whitelist
• Formular-Passwort
• Formularschlüssel via URL-Parameter
• Ablaufdatum
• Zugelassene Werte als Anti-Submit-Trick
• Filter pro Formular (Datensatz-Beschränkung)
• UUID-Erfordernis für Formular-Aufruf
• Vergleich: Welcher Schutz wofür?

Honeypot & CSRF (automatisch aktiv)

Jedes propform-Formular hat eingebauten Bot-Schutz — ohne dass du etwas konfigurieren musst:

• Honeypot-Feld: unsichtbares Feld, das echte Menschen nicht sehen, Bots aber ausfüllen → Vorgang abgebrochen, IP geloggt
• CSRF-Token: verschlüsselter Token beim Aufruf, geprüft beim Submit → Bots ohne regulären Aufruf scheitern
• Formular-Signatur + Zeitstempel: verhindert Replay-Angriffe

Mehr dazu unter Spam-Schutz & Bot-Abwehr.

IP-Whitelist

Wenn ein Formular nur aus bestimmten IP-Bereichen aufrufbar sein soll (z.B. internes Mitarbeiter-Formular nur aus dem Büro):

Setup:

1. Formulareinstellungen → Weitere Einstellungen → ganz nach unten scrollen
2. Häkchen „IP-Whitelist" aktivieren
3. IP-Adressen komma-getrennt eintragen (z.B. 192.168.1.10, 91.42.42.42)

Limits: max. 2000 Zeichen → mehrere Hundert IPs möglich

Was passiert: Wer nicht auf der Whitelist steht, sieht eine Fehlermeldung „Deine IP ist nicht berechtigt, dieses Formular aufzurufen".

💡 Tipp: Eigene IP herausfinden via whatismyip.com oder ähnliche Dienste. Bei dynamischen Heim-IPs lieber einen IP-Bereich einplanen oder VPN nutzen.

Formular-Passwort

Schützt das Aufrufen des Formulars. Ohne korrektes Passwort wird das Formular gar nicht angezeigt.

Setup:

1. Formulareinstellungen → Weitere Einstellungen
2. (Aktuell als versteckte Option implementiert — wir schalten sie auf Anfrage frei. Schreib uns kurz unter hello@propform.io.)
3. Passwort definieren

Aufruf:

https://formular.deine-domain.de/dein-formular?password=geheim123

Use-Cases:

• Internes Mitarbeiter-Formular ohne öffentlichen Zugang
• Privater Test-Link an einzelne Kunden

⚠️ Sicherheits-Hinweis: Das Passwort steht im Klartext in der URL und wird aktuell auch unverschlüsselt in der Datenbank gespeichert. Eignet sich für leichten Schutz, nicht für hochsensitive Daten. Eine echte User+Password-Authentifizierung mit pro-Account konfigurierbaren Zugangsdaten ist auf der Roadmap.

Formularschlüssel via URL-Parameter

Anders als das Formular-Passwort prüft der Formularschlüssel einen dynamischen Wert — z.B. ein Feld aus dem onOffice-Datensatz, das nur einmal gesetzt sein darf (Anti-Doppel-Submit).

Setup:

1. Formulareinstellungen → Weitere Einstellungen → „Formularschlüssel erforderlich"
2. Schlüssel definieren — kann ein Makro sein, z.B. _reservierung_aufgerufen
3. Optionale Fehlermeldung („Sie haben das Formular bereits abgesendet")

Aufruf:

https://formular.deine-domain.de/reservierung?key=ja

→ Wert hinter key= muss exakt mit dem aufgelösten Makro-Wert übereinstimmen.

Use-Case Reservierungs-Workflow:

• Anfangs ist Feld _reservierung_aufgerufen in onOffice leer → Formular kann nicht aufgerufen werden
• Per Setup setzt du das Feld auf ja (z.B. wenn der Kunde im Reservierungs-Schritt ankommt)
• Nach Submit kannst du das Feld wieder auf nein setzen → Formular ist gesperrt für Wiederholung

Ablaufdatum

Ein Formular soll nur bis zu einem bestimmten Datum aufrufbar sein. Du hängst das Ablaufdatum als URL-Parameter an deinen Formularlink und aktivierst in den Formulareinstellungen → „Ablaufdatum erforderlich".

https://formular.deine-domain.de/bewerbung?exp=2030-12-31 23:59:59

Wichtig: Datum + Uhrzeit nötig

Der ?exp=-Parameter braucht Datum UND Uhrzeit — nur Datum allein scheitert mit „Ablaufdatum ungültig".

Korrekt:

?exp=2030-12-31 23:59:59

Falsch (scheitert):

?exp=2030-12-31

Dynamisches Ablaufdatum per DateAdd-Makro

In onOffice-Mail-Vorlagen kannst du das Ablaufdatum dynamisch berechnen — z.B. „Link gilt 14 Tage ab heute":

?exp=_calculate(DateAdd(now;14;days)) 23:59:59

Einheiten für DateAdd: days, weeks, months, years. Die Uhrzeit hängst du als festen String hinten an, weil DateAdd selbst nur das Datum liefert.

Use-Cases:

• Bewerbungs-Formulare mit Stichtag
• Zeitlich begrenzte Angebote
• Aktions-Codes mit Gültigkeit

Zugelassene Werte als Anti-Submit-Trick

Ein cleverer Workaround, wenn du das Absenden des Formulars an eine zusätzliche Bedingung knüpfen willst — ohne separate Authentifizierung:

Pattern:

1. Textfeld im Formular hinzufügen (kann unsichtbar sein, oder als „Code-Eingabe" sichtbar für den User)
2. Feldeinstellungen → Weitere Einstellungen → „Zulässige Werte" auf den Soll-Wert setzen, z.B. passwort1234
3. Beim Absenden prüft propform die zulässigen Werte: stimmt der Wert nicht → kein Submit

Use-Cases:

• Anti-Spam-Code für öffentliche Formulare („Trage den Code aus unserer Mail ein")
• Einmal-Pass-Code, den du per separatem Kanal verschickst
• Ergänzender Schutz zu Honeypot/CSRF

💡 Unterschied zum Honeypot: Honeypot blockt automatisch ausgefüllte Felder. Hier muss der Wert gewünscht ausgefüllt sein.

Filter pro Formular (Datensatz-Beschränkung)

Wenn ein Formular Datensätze laden oder bearbeiten kann (z.B. Adress-bearbeiten- oder Immobilie-bearbeiten-Formular), kannst du den Zugriff auf einen onOffice-Filter beschränken — kritisch bei öffentlichen Formularen.

Setup:

1. In onOffice einen Filter anlegen (z.B. „nur aktive Immobilien", „nur Status > 5", „nur Marketing-Region X")
2. Im propform-Formular → Adress-/Immobilien-Felder → Filtereinstellungen → den Filter auswählen
3. Effekt: Formular kann ausschließlich Datensätze aus diesem Filter laden/bearbeiten — alles andere wird abgewiesen

Mehr dazu in der separaten FAQ: Filter pro Formular.

⚠️ Sicherheits-Aspekt bei öffentlichen Formularen: Ohne Filter kann ein User per UUID-Manipulation in der URL beliebige Datensätze ansprechen, die der API-User sieht. Filter beschränkt das auf den gewünschten Bereich.

UUID-Erfordernis für Formular-Aufruf

Verhindert, dass ein Formular ohne gültige Datensatz-UUID in der URL überhaupt aufgerufen werden kann. Wichtig bei Bearbeitungs- und Download-Formularen, die immer einen konkreten Datensatz brauchen.

Setup:

1. Formulareinstellungen → Weitere Einstellungen → „Immobilie und/oder Adresse erforderlich für Formularaufrufe"
2. Wählen, welcher der beiden UUIDs verlangt wird (beide möglich)

Was passiert ohne UUID:

• Formular wird nicht angezeigt, stattdessen Fehlermeldung
• Verhindert URL-Tampering: User entfernt eine UUID aus der URL → würde sonst leerer Datensatz angelegt
• Verhindert versehentliche Anlage von leeren Datensätzen, wenn der Mitarbeiter den Link ohne Datensatz-Bezug verschickt

Use-Cases:

• Download-Formulare (siehe Download-Felder) — ohne UUID kein Datensatz, ohne Datensatz keine Dateien
• Bearbeitungs-Formulare aus onOffice-Maske heraus (Akquise, Übergabe, Reservierung)
• Status-/Statistik-Formulare für Eigentümer

💡 Kombinations-Tipp: UUID-Erfordernis + Filter pro Formular + Adress-Dubletten-Check ergibt einen sehr robusten Sicherheits-Stack für öffentliche Bearbeitungs-Formulare.

Vergleich: Welcher Schutz wofür?

Verwandt

• 📖 Spam-Schutz & Bot-Abwehr — Honeypot/CSRF-Mechanik
• 📖 Filter pro Formular — Datensatz-Beschränkung im Detail
• 📖 Datenschutz & Datensparsamkeit — was wird gespeichert