Salut tout le monde,
Je bosse sur une appli qui reçoit pas mal de données utilisateur (formulaires, API) et je me pose des questions sur la validation côté serveur.
Actuellement j'utilise principalement filter_var() avec les constantes FILTER_VALIDATE_EMAIL, FILTER_VALIDATE_URL etc. C'est clean et rapide à implémenter, mais parfois j'ai l'impression que c'est un peu... permissif ?
Pour certains cas spécifiques, jsuis tenté de partir sur des regex custom plus strictes. Le truc c'est que niveau perf et sécurité, je sais pas trop ce qui est le mieux.
Vous faites comment de votre côté ? Vous restez sur filter_var ou vous mixez avec des validations custom selon le contexte ?
Et une question bonus : vous utilisez quoi pour valider les numéros de tel français ? Les formats sont tellement variés que j'arrive pas à trouver une solution propre...
Merci d'avance pour vos retours !
Validation input utilisateur : filter_var vs regex custom ?
-
Nicolas.Dev-35
- Messages : 1
- Inscription : mar. mars 10, 2026 7:40 pm
Re: Validation input utilisateur : filter_var vs regex custom ?
Alors pour avoir testé les deux approches en prod, je dirais que ça dépend vraiment du contexte. filter_var() c'est effectivement plus permissif mais c'est fait exprès - ça suit les standards RFC et évite les faux positifs qui peuvent faire chier tes utilisateurs.
Pour l'email par exemple, les regex "strictes" que je vois souvent refusent des adresses complètement valides (genre avec des + ou des domaines exotiques). Du coup maintenant je fais un mix : filter_var() pour la validation de base, et des vérifs custom uniquement pour les règles métier spécifiques (longueur, caractères interdits pour ton contexte, etc).
Et surtout, pense à la validation côté client aussi, ça évite 90% des conneries avant qu'elles arrivent sur ton serveur. Après pour l'API, c'est un autre délire, là tu peux être plus strict si tu maîtrises les clients.
Pour l'email par exemple, les regex "strictes" que je vois souvent refusent des adresses complètement valides (genre avec des + ou des domaines exotiques). Du coup maintenant je fais un mix : filter_var() pour la validation de base, et des vérifs custom uniquement pour les règles métier spécifiques (longueur, caractères interdits pour ton contexte, etc).
Et surtout, pense à la validation côté client aussi, ça évite 90% des conneries avant qu'elles arrivent sur ton serveur. Après pour l'API, c'est un autre délire, là tu peux être plus strict si tu maîtrises les clients.
Code review is love, code review is life
-
DevBackend42
- Messages : 1
- Inscription : mar. mars 10, 2026 7:40 pm
Re: Validation input utilisateur : filter_var vs regex custom ?
Alors perso j'ai une approche hybride qui marche plutôt bien. Pour les trucs standards (email, URL, IP), je reste sur filter_var() parce que c'est testé et maintenu par la communauté PHP. Par contre pour tout ce qui est métier spécifique (codes produit, formats internes, regex complexes), là je pars sur du custom.
Le truc important c'est de pas réinventer la roue quand c'est pas nécessaire. J'ai vu trop de projets où le dev avait fait sa regex email "ultra stricte" et au final ça bloquait des adresses valides. Pour les cas edge, tu peux toujours coupler filter_var() avec une validation supplémentaire si besoin.
En vrai, le plus critique c'est la cohérence dans ton code et de bien documenter tes choix pour l'équipe. Si tu pars sur du regex custom, assure-toi d'avoir des tests unitaires solides parce que c'est là que ça peut vite partir en vrille.
Le truc important c'est de pas réinventer la roue quand c'est pas nécessaire. J'ai vu trop de projets où le dev avait fait sa regex email "ultra stricte" et au final ça bloquait des adresses valides. Pour les cas edge, tu peux toujours coupler filter_var() avec une validation supplémentaire si besoin.
En vrai, le plus critique c'est la cohérence dans ton code et de bien documenter tes choix pour l'équipe. Si tu pars sur du regex custom, assure-toi d'avoir des tests unitaires solides parce que c'est là que ça peut vite partir en vrille.
Code is poetry, bugs are typos