🛡️ Protection des formulaires et contrôle d'accès

Par défaut, les formulaires propform sont accessibles au public — ce qui est utile pour les demandes de renseignements, les commentaires des clients et la génération de prospects. Cependant, certains formulaires ne doivent pouvoir être ouverts ou envoyés que sous certaines conditions. Voici les mécanismes de protection disponibles.

Contenu

• Honeypot & CSRF (activé automatiquement)
• Liste blanche d'adresses IP
• Mot de passe du formulaire
• Clé du formulaire via un paramètre d'URL
• Date d'expiration
• Valeurs autorisées comme anti-submit-trick
• Filtre par formulaire (limitation du nombre d'enregistrements)
• Exigence d'un UUID pour l'appel du formulaire
• Comparaison : quelle protection pour quoi ?

Honeypot & CSRF (activé automatiquement)

Chaque formulaire propform dispose d'une protection anti-bot intégrée — sans que vous ayez besoin de configurer quoi que ce soit :

• Champ honeypot : champ invisible que les humains ne voient pas, mais que les bots remplissent → opération interrompue, adresse IP enregistrée
• Jeton CSRF : jeton crypté lors de l'appel, vérifié lors de la soumission → les bots sans appel régulier échouent
• Signature du formulaire + horodatage : empêche les attaques par rejeu

Pour en savoir plus, consultez Protection anti-spam et anti-bot.

## Liste blanche d'adresses IP

Si un formulaire ne doit être accessible qu'à partir de certaines plages d'adresses IP (par exemple, un formulaire interne réservé aux employés accessible uniquement depuis le bureau) :

Configuration :

1. Paramètres du formulaire → Paramètres supplémentaires → faire défiler jusqu'en bas
2. Cochez la case « Liste blanche d'adresses IP »
3. Saisissez les adresses IP séparées par des virgules (par exemple 192.168.1.10, 91.42.42.42)

Limites : 2 000 caractères max. → plusieurs centaines d'adresses IP possibles

Ce qui se passe : les personnes ne figurant pas sur la liste blanche verront s'afficher le message d'erreur « Votre adresse IP n'est pas autorisée à accéder à ce formulaire ».

> 💡 Astuce : découvrez votre propre adresse IP via whatismyip.com ou des services similaires. En cas d’adresses IP domestiques dynamiques, il est préférable de définir une plage d’adresses IP ou d’utiliser un VPN.

Mot de passe du formulaire

Protège l’accès au formulaire. Sans mot de passe correct, le formulaire ne s'affiche pas du tout.

Configuration :

1. Paramètres du formulaire → Paramètres supplémentaires
2. (Actuellement implémenté en tant qu'option masquée — nous l'activons sur demande. Écrivez-nous brièvement à l'adresse hello@propform.io.)
3. Définir le mot de passe

Appel :

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

Cas d'utilisation :

• Formulaire interne destiné aux employés, sans accès public
• Lien de test privé envoyé à des clients individuels

> ⚠️ Remarque de sécurité : le mot de passe apparaît en clair dans l'URL et est actuellement stocké non chiffré dans la base de données. Convient pour une protection légère, pas pour des données hautement sensibles. Une véritable authentification utilisateur+mot de passe avec des identifiants configurables par compte est prévue dans la feuille de route.

---

Clé de formulaire via un paramètre d'URL

Contrairement au mot de passe du formulaire, la clé de formulaire vérifie une valeur dynamique — par exemple, un champ de l'enregistrement onOffice qui ne doit être défini qu'une seule fois (anti-double soumission).

Configuration :

1. Paramètres du formulaire → Paramètres supplémentaires → « Clé de formulaire requise »
2. Définir la clé — il peut s'agir d'une macro, par exemple _reservierung_aufgerufen
3. Message d'erreur facultatif (« Vous avez déjà envoyé ce formulaire »)

Appel :

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

→ La valeur après key= doit correspondre exactement à la valeur de la macro résolue.

Cas d'utilisation : workflow de réservation :

• Au départ, le champ _reservierung_aufgerufen est vide dans onOffice → le formulaire ne peut pas être appelé
• Dans la configuration, tu définis le champ sur ja (par exemple, lorsque le client arrive à l'étape de réservation)
• Après la soumission, tu peux redéfinir le champ sur nein → le formulaire est verrouillé pour empêcher toute nouvelle soumission

---

Date d'expiration

Un formulaire ne doit être accessible que jusqu'à une date donnée. Vous ajoutez la date d'expiration en tant que paramètre URL à votre lien de formulaire et activez l'option « Date d'expiration requise » dans les paramètres du formulaire.

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

Important : date + heure requises

Le paramètre ?exp= nécessite la date ET l'heure — la date seule entraîne l'erreur « Date d'expiration non valide ».

Correct :

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

Incorrect (échec) :

?exp=2030-12-31

Date d'expiration dynamique via la macro DateAdd

Dans les modèles de courrier onOffice, tu peux calculer la date d'expiration de manière dynamique — par exemple « Le lien est valable 14 jours à compter d'aujourd'hui » :

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

Unités pour DateAdd : days, weeks, months, years. Vous ajoutez l'heure à la fin sous forme de chaîne fixe, car DateAdd ne fournit que la date.

Cas d'utilisation :

• Formulaires de candidature avec date limite
• Offres à durée limitée
• Codes promotionnels avec une durée de validité

---

Valeurs autorisées comme astuce anti-soumission

Une solution astucieuse si vous souhaitez lier l'envoi du formulaire à une condition supplémentaire — sans authentification séparée :

Modèle :

1. Ajoutez un champ de texte dans le formulaire (il peut être invisible ou visible pour l'utilisateur sous la forme d'une « saisie de code »)
2. Paramètres du champ → Paramètres supplémentaires → Définissez les « Valeurs autorisées » sur la valeur souhaitée, par exemple passwort1234
3. Lors de l'envoi, propform vérifie les valeurs autorisées : si la valeur est incorrecte → pas d'envoi

Cas d'utilisation :

• Code anti-spam pour les formulaires publics (« Saisissez le code figurant dans notre e-mail »)
• Code d'accès à usage unique que vous envoyez via un canal séparé
• Protection complémentaire au honeypot/CSRF

> 💡 Différence par rapport au honeypot : le honeypot bloque les champs remplis automatiquement. Ici, la valeur doit être saisie manuellement.

Filtre par formulaire (limitation des enregistrements)

Si un formulaire peut charger ou modifier des enregistrements (par exemple, formulaire de modification d'adresse ou de modification de bien immobilier), vous pouvez limiter l'accès à un filtre onOffice — ce qui est essentiel pour les formulaires publics.

Configuration :

1. Créez un filtre dans onOffice (par exemple « uniquement les biens immobiliers actifs », « uniquement statut > 5 », « uniquement région marketing X »)
2. Dans le formulaire propform → Champs d'adresse/de bien immobilier → Paramètres de filtrage → sélectionnez le filtre
3. Résultat : le formulaire peut exclusivement charger/modifier les enregistrements issus de ce filtre — tout le reste est rejeté

Pour en savoir plus, consultez la FAQ dédiée : Filtre par formulaire.

> ⚠️ Aspect sécuritaire des formulaires publics : sans filtre, un utilisateur peut, en manipulant l'UUID dans l'URL, accéder à n'importe quel enregistrement visible par l'utilisateur de l'API. Le filtre limite cela à la zone souhaitée.

Exigence d'UUID pour l'appel du formulaire

Empêche qu'un formulaire puisse être appelé sans UUID d'enregistrement valide dans l'URL. Important pour les formulaires de modification et de téléchargement, qui ont toujours besoin d'un enregistrement spécifique.

Configuration :

1. Paramètres du formulaire → Paramètres supplémentaires → « Bien immobilier et/ou adresse requis pour les appels de formulaire »
2. Choisissez lequel des deux UUID est requis (les deux sont possibles)

Que se passe-t-il sans UUID :

• Le formulaire n'est pas affiché, un message d'erreur s'affiche à la place
• Empêche la falsification de l'URL : si l'utilisateur supprime un UUID de l'URL, un enregistrement vide serait sinon créé
• Empêche la création accidentelle d'enregistrements vides lorsque l'employé envoie le lien sans référence à un enregistrement

Cas d'utilisation :

• Formulaires de téléchargement (voir Champs de téléchargement) — sans UUID, pas d'enregistrement ; sans enregistrement, pas de fichiers
• Formulaires de modification à partir du masque onOffice (prospection, transfert, réservation)
• Formulaires de statut/statistiques pour les propriétaires

> 💡 Astuce de combinaison : l'exigence d'un UUID + un filtre par formulaire + la vérification des doublons d'adresse constituent une pile de sécurité très robuste pour les formulaires d'édition publics.

---

Comparaison : quelle protection pour quoi ?

Connexes

• 📖 Protection anti-spam et défense contre les bots — Mécanisme honeypot/CSRF
• 📖 Filtre par formulaire — Limitation des enregistrements en détail
• 📖 Protection des données & minimisation des données — ce qui est enregistré