Validation des entrées dans les applications mobiles — principes de base, méthodes de contrôle et implémentation

Qu'est-ce que la validation des entrées ?

La validation des entrées consiste à vérifier que les données arrivant dans l'application depuis un utilisateur, un service externe ou un autre composant respectent les critères attendus. Ces critères incluent le type de données (chaîne, nombre, date), le format (email, URL, téléphone), la plage de valeurs (âge de 18 à 120), la longueur (mot de passe de 8 à 128 caractères) et les caractères autorisés (uniquement lettres latines, chiffres, trait d'union). Sans validation, l'application peut traiter des données qui provoquent des erreurs d'exécution, une corruption des données ou des vulnérabilités de sécurité.

Pourquoi la validation est-elle un élément critique de la sécurité ?

L'absence de validation des entrées est la cause première de vulnérabilités telles que SQL Injection, XSS, Command Injection, Path Traversal et Buffer Overflow. Selon MITRE CWE (2025), CWE-20 (Improper Input Validation) occupe la deuxième place dans le classement des erreurs logicielles les plus dangereuses. La validation est la première ligne de défense dans le modèle de sécurité Defense in Depth : elle coupe les données incorrectes avant qu'elles n'atteignent les autres composants du système.

Validation vs Assainissement

La validation rejette les données qui ne respectent pas les critères. L'assainissement (nettoyage) modifie les données en supprimant ou en échappant les parties dangereuses. Par exemple, lors de la saisie de contenu HTML, la validation peut vérifier la longueur du texte et l'assainissement supprimer les balises script via la bibliothèque HTML Purifier ou DOMPurify. L'assainissement ne remplace pas la validation : ils fonctionnent ensemble. La validation est une politique « autorisé/interdit », l'assainissement est « nettoyé avant utilisation ».

Types de validation des entrées

La validation est classée selon la profondeur du contrôle. La validation de format est la plus simple et la plus rapide, tandis que la validation métier est la plus complexe et la plus dépendante du contexte. Les trois niveaux doivent être appliqués en séquence : d'abord le format, puis la sémantique, puis la logique métier. Sauter un niveau peut entraîner un fonctionnement incorrect du système ou des vulnérabilités.

Validation de format

Vérification du type de données, de la taille, du format et des caractères autorisés. Elle est implémentée via des expressions régulières, les types intégrés des langages et des bibliothèques de validation. Exemples : vérification d'un UUID (format 8-4-4-4-12 chiffres hexadécimaux), vérification d'un numéro de téléphone (uniquement des chiffres, + au début, de 7 à 15 caractères), vérification d'un entier (valeur dans la plage Integer.MIN_VALUE — Integer.MAX_VALUE). La validation de format est le niveau minimum requis pour tout champ de saisie.

Validation sémantique

Vérification de la correction logique des données dans le contexte du domaine. Par exemple : la date de début n'est pas postérieure à la date de fin, l'âge se situe dans des limites raisonnables pour le système, les coordonnées se trouvent dans la zone de service. La validation sémantique exige une compréhension du contexte métier et ne peut pas être effectuée uniquement sur la base du format. Exemple : le champ « nombre de billets » peut passer la validation de format (entier, > 0), mais sémantiquement ne peut pas dépasser le nombre de places disponibles.

Validation métier

Le niveau le plus complexe — vérifier que les données respectent les règles métier de l'application. Exemples : un utilisateur ne peut pas supprimer le seul administrateur, le montant de la commande ne dépasse pas la limite de crédit, un article ne peut être commandé que s'il est en stock. La validation métier exige souvent des requêtes à la base de données ou à des services externes et est effectuée après les contrôles de format et sémantiques. Les erreurs de validation métier sont la cause la plus fréquente de mécontentement des utilisateurs.

Validation côté client et côté serveur

La validation côté client (dans le navigateur ou l'application mobile) est nécessaire pour le confort de l'utilisateur : retour immédiat sans envoyer de données au serveur. Cependant, la validation côté serveur est la seule fiable, car le code client peut toujours être contourné. Envoyez des requêtes via les outils de développement, Postman ou un proxy (Burp Suite) — et la validation côté client cesse d'exister. Selon PortSwigger Research (2025), plus de 90% des applications web testées ne s'appuient que sur la validation côté client pour au moins un champ.

Règle : le client pour l'UX, le serveur pour la sécurité

La validation côté client peut désactiver le bouton d'envoi, surligner les erreurs et afficher des indices. La validation côté serveur est un contrôle obligatoire de chaque paramètre, même si le client l'a déjà vérifié. Dupliquer la validation aux deux niveaux est une pratique standard. Le serveur doit vérifier les données comme si le client n'existait pas. Cela garantit une protection contre les requêtes modifiées, les attaques automatisées et les clients malveillants.

Implémentation de la validation côté client

Sur le web — les attributs HTML5 (required, pattern, min/max, type="email") et JavaScript. Dans les applications mobiles — les validateurs natifs de champs de texte (InputFilter sur Android, textField(:shouldChangeCharactersIn:) sur iOS). React Hook Form et Formik pour React, Vuelidate pour Vue, Angular Reactive Forms — des bibliothèques populaires pour la validation côté client. Elles prennent toutes en charge les règles personnalisées et la validation asynchrone (vérification de l'unicité du login sur le serveur).

// Exemple de validation côté serveur avec Express et Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — des données déjà validées et sûres
    const user = await User.create(value);
    res.status(201).json(user);
});

Validation dans les applications mobiles

Les applications mobiles imposent des exigences particulières à la validation des données. L'écran est plus petit — les erreurs doivent être concises, le clavier contextuel (numérique pour saisir des nombres), et le contrôle asynchrone pour ne pas bloquer l'interface. Les plateformes natives fournissent des mécanismes de validation intégrés à utiliser par défaut. Les Material Design Guidelines pour Android et les Human Interface Guidelines pour iOS contiennent des recommandations détaillées pour afficher les erreurs de validation.

Validation sur Android (Jetpack Compose)

Jetpack Compose offre une approche déclarative de la validation via la gestion d'état. Chaque champ de saisie est lié à un état (MutableState) et l'erreur est calculée en fonction de la valeur actuelle. La bibliothèque Compose Validator simplifie la création de règles : required, email, min/max length, pattern. La validation est déclenchée lors du changement du texte (onValueChange) ou lors de la tentative d'envoi du formulaire. Il est recommandé d'afficher l'erreur uniquement après la première soumission ou après que l'utilisateur a fini de saisir (debounce 300-500ms).

Validation sur iOS (SwiftUI)

SwiftUI ne dispose pas de mécanisme intégré de validation de formulaires, mais il permet de l'implémenter facilement via Combine et les property wrappers. Utilisez @State pour la valeur du champ et une propriété calculée pour l'erreur. Le framework ValidatedPropertyKit fournit des décorateurs prêts à l'emploi : @Validated().email(), @Validated().range(18...120). Recommandation iOS — utiliser les types de clavier (UIKeyboardType.emailAddress, .numberPad) et la capitalisation automatique pour réduire le nombre d'erreurs au niveau de la saisie.

Validation sur Flutter

Flutter fournit les classes Form et TextFormField avec une validation intégrée via un callback de validateur. Chaque champ renvoie une erreur sous forme de chaîne ou null si les données sont correctes. FormState.validate() lance la vérification de tous les champs du formulaire. Le package reactive_forms pour les cas complexes : validateurs personnalisés, vérification asynchrone, règles dynamiques. Flutter Web et la version mobile utilisent la même API, ce qui simplifie la maintenance.

// Exemple de validation de formulaire en Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Traiter les données valides
                    }
                },
                child: Text('Envoyer'),
            ),
        ],
    ),
)

Techniques et outils de validation

Les frameworks modernes fournissent des validateurs intégrés qui couvrent 80% des besoins. Les 20% restants exigent des règles personnalisées, des expressions régulières ou la composition de règles existantes. Le principe clé est que la validation doit être déclarative pour être facilement lue, testée et maintenue. Évitez la logique de validation dispersée dans les contrôleurs et les écrans — déplacez-la dans des classes ou des schémas séparés.

Approches White-list vs Black-list

White-list (liste blanche) — vous définissez quelles données sont autorisées ; tout le reste est rejeté. Black-list (liste noire) — vous définissez quelles données sont interdites ; tout le reste passe. La liste blanche est toujours plus fiable : vous savez exactement quelles données passeront. La liste noire exige de prévoir toutes les attaques possibles, ce qui est impossible. Exemple : lors de la vérification de l'âge, utilisez une liste blanche (uniquement les nombres de 18 à 120) plutôt qu'une liste noire (interdire "0", "-1", "999999").

Expressions régulières — puissance et danger

Les expressions régulières sont un outil efficace pour la validation de format, mais elles peuvent être une source d'attaques ReDoS (Regular Expression Denial of Service). Certains motifs (par exemple, (a+)+b) provoquent un retour arrière catastrophique sur les chaînes longues, chargeant complètement le CPU du serveur. Utilisez des bibliothèques regex éprouvées et limitez la longueur de la chaîne avant d'appliquer une expression régulière. Pour les cas complexes (email, URL), utilisez les analyseurs intégrés des langages plutôt que des regex maison.

Erreurs typiques lors de la validation

Même les développeurs expérimentés commettent des erreurs lors de l'implémentation de la validation. Les plus fréquentes : validation uniquement côté client, règles trop strictes (mot de passe "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), messages d'erreur peu informatifs ("Error: invalid input") et ignorance des cas limites (espaces au début/fin, caractères Unicode, chaînes vides). Chacune de ces erreurs dégrade l'UX et peut réduire la conversion des formulaires.

• Validation uniquement côté client — l'erreur la plus dangereuse : toute requête peut être falsifiée via Postman ou cURL
• Règles trop strictes — font fuir les utilisateurs : OWASP recommande un minimum d'exigences à l'inscription
• Ignorer Unicode — vérifier la longueur de la chaîne en octets (pas en caractères) casse le russe, le chinois, les emojis
• Erreurs peu informatives — « Invalid format » au lieu de « Email must contain @ symbol after local part »
• Vérification de champ vide — if (value) ne distingue pas une chaîne vide de zéro, de false ou de "0"

La meilleure pratique est un système centralisé de validation couvert par des tests unitaires. Chaque règle doit être testée séparément : valeurs limites, données correctes, attaques typiques (tentatives de SQLi, payloads XSS, chaînes très longues). Les tests de régression sur la validation empêchent l'affaiblissement accidentel des règles lors du refactoring. Utilisez les tests basés sur les propriétés (QuickCheck, fast-check) pour générer des données aléatoires et vérifier que la validation n'échoue pas avec une exception.