Validation des entrées : bonnes pratiques secure coding 2026

Denylist (mauvais)
  Bannir ["<script>", "alert(", "javascript:", "../", "DROP TABLE"]
  → un attaquant trouvera toujours une forme non listée
    (encodage, Unicode, variante syntaxique, obfuscation)
 
Allowlist (bon)
  Username : [a-z0-9_]{3,32}
  → toute forme non conforme est rejetée, quelle qu'en soit la cause

// Exemple Zod - schéma API de création d'utilisateur
import { z } from 'zod';
 
const CreateUserSchema = z.object({
  email: z.string().email().max(254).toLowerCase(),
  username: z.string().regex(/^[a-z0-9_]{3,32}$/),
  password: z.string().min(12).max(128),
  birth_year: z.number().int().min(1900).max(2026),
  role: z.enum(['user', 'editor']).default('user'),
});
 
type CreateUserInput = z.infer<typeof CreateUserSchema>;
 
// Express handler
app.post('/api/users', async (req, res) => {
  const parsed = CreateUserSchema.safeParse(req.body);
  if (!parsed.success) {
    return res.status(400).json({ errors: parsed.error.issues });
  }
  const user = await createUser(parsed.data);
  res.json(user);
});

# Exemple Pydantic v2 - validation stricte
from pydantic import BaseModel, EmailStr, Field, field_validator
import unicodedata
from typing import Literal
 
class CreateUser(BaseModel):
    email: EmailStr
    username: str = Field(pattern=r'^[a-z0-9_]{3,32}$')
    password: str = Field(min_length=12, max_length=128)
    birth_year: int = Field(ge=1900, le=2026)
    role: Literal['user', 'editor'] = 'user'
 
    @field_validator('username', 'email')
    @classmethod
    def normalize_unicode(cls, v: str) -> str:
        return unicodedata.normalize('NFKC', v)
 
# FastAPI
@app.post('/api/users')
def create_user(payload: CreateUser):
    return user_service.create(payload)

// Bean Validation avec Spring Boot
public record CreateUserRequest(
    @Email @Size(max = 254) String email,
    @Pattern(regexp = "^[a-z0-9_]{3,32}$") String username,
    @Size(min = 12, max = 128) String password,
    @Min(1900) @Max(2026) int birthYear,
    @NotNull Role role
) {}
 
@PostMapping("/api/users")
public User create(@Valid @RequestBody CreateUserRequest req) {
    return userService.create(req);
}

// validator/v10 - le plus utilisé
type CreateUserRequest struct {
    Email     string `json:"email" validate:"required,email,max=254"`
    Username  string `json:"username" validate:"required,min=3,max=32,alphanum"`
    Password  string `json:"password" validate:"required,min=12,max=128"`
    BirthYear int    `json:"birth_year" validate:"required,gte=1900,lte=2026"`
    Role      string `json:"role" validate:"required,oneof=user editor"`
}

Longueur    : min et max toujours définis (éviter DoS par payload géant)
Jeu charset : whitelist regex ([a-zA-Z0-9_-] si possible)
Normaliser  : NFKC avant comparaison ou stockage
Trimmer    : espaces en début et fin
Refuser    : null bytes \0, CRLF si hors texte libre, contrôles C0

Règle : utiliser une lib dédiée (Zod .email(), Pydantic EmailStr,
        Apache Commons EmailValidator Java)
Pas de regex maison - RFC 5322 fait 6+ pages, les regex naïves
échouent sur les cas valides ou acceptent des cas dangereux.
Limite max 254 caractères (RFC 5321).
Normaliser en lowercase pour comparaison.

Utiliser le parseur natif (URL en JS, urllib en Python, java.net.URI)
Après parsing :
  - Whitelister les schemes autorisés (http, https uniquement)
  - Vérifier le host contre une allowlist si usage SSRF-sensible
  - Refuser les IP privées et métadonnées cloud
    (169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8)
  - Refuser les redirections ouvertes non contrôlées
 
Bibliothèques dédiées anti-SSRF :
  - safe-url (Node)
  - defusedxml + ipaddress (Python)
  - Apache HttpClient RedirectStrategy custom (Java)

Entiers :
  - Type int explicite (pas de parseFloat)
  - Plage [min, max] explicite
  - Refuser NaN, Infinity, notation scientifique sauf besoin
 
Dates :
  - Parser avec lib ISO 8601 stricte (pas de strptime permissif)
  - Timezone explicite
  - Plage raisonnable ([1900-01-01, 2100-12-31])

Utiliser schéma imbriqué (Zod .object(), Pydantic modèles imbriqués)
Limite profondeur (éviter JSON bomb : 10 niveaux max typique)
Limite taille brute (Content-Length max 1 MB typique pour une API)
Rejeter propriétés inconnues (strict: true ou .strict() en Zod)

# Python - validation magic bytes + UUID storage
import magic
from pathlib import Path
from uuid import uuid4
 
ALLOWED_MIMES = {'image/png', 'image/jpeg', 'application/pdf'}
MAX_SIZE = 10 * 1024 * 1024  # 10 MB
 
def store_upload(file_bytes: bytes, original_name: str) -> str:
    if len(file_bytes) > MAX_SIZE:
        raise ValueError("fichier trop volumineux")
 
    mime = magic.from_buffer(file_bytes, mime=True)
    if mime not in ALLOWED_MIMES:
        raise ValueError(f"type {mime} non autorisé")
 
    ext = Path(original_name).suffix.lower()
    if ext not in {'.png', '.jpg', '.jpeg', '.pdf'}:
        raise ValueError("extension non autorisée")
 
    stored_name = f"{uuid4().hex}{ext}"
    (Path("/srv/uploads") / stored_name).write_bytes(file_bytes)
    return stored_name

Entrée brute   : %252e%252e%252f
1er décodage   : %2e%2e%2f
2nd décodage   : ../
 
Si validation rejetait "../" après 1er décodage mais que l'app
consomme après 2nd décodage, le payload passe.
 
Règle : décoder une seule fois, rejeter tout payload qui contient
       encore des séquences encodées après décodage.

admin       : a d m i n (ASCII standard)
ADMIN       : majuscule, peut être normalisé lower
admın       : ı turc (U+0131) visuellement proche
𝐚𝐝𝐦𝐢𝐧       : math bold Unicode (U+1D41A...)
ⓐⓓⓜⓘⓝ      : cercles (U+24D0...)
 
Sans NFKC + lower strict, un attaquant peut créer un username
visuellement identique à un existant.

Attaques :
  filename=../../../etc/passwd
  filename=..%2f..%2fetc%2fpasswd
  filename=legit.jpg\0.php      (null byte truncation en C)
  filename=legit.jpg::$DATA      (Windows ADS)
 
Règles :
  Régénérer un UUID pour le nom stocké.
  Bannir les noms contenant ".." après décodage.
  Utiliser os.path.realpath / Path.resolve() pour vérifier
  que le chemin final est dans le répertoire autorisé.

{"user_id": "42"}   vs   {"user_id": 42}
 
Une validation laxiste accepte les deux puis compare faiblement
côté code. En PHP, "0e1234" est parfois égal à 0 en comparaison
lâche. Toujours valider le type précisément et comparer en strict.

1. Le code vérifie que le fichier n'existe pas.
2. L'attaquant crée un symlink avant que le code l'écrive.
3. Le code écrit dans la destination du symlink.
 
Règles :
  Utiliser les syscalls atomiques (O_CREAT | O_EXCL).
  Ne pas se baser sur un path string après check.

Règles 2026 :
 
  Ne jamais exposer en réponse :
    - La trace d'exception Python/Java brute
    - Le nom des champs internes (ex. mot-clé SQL)
    - Le chemin système du serveur
 
  Exposer de manière contrôlée :
    - Code HTTP 400 Bad Request (jamais 500 pour validation)
    - Structure stable { "errors": [ { "field": "email", "code": "invalid_format" } ] }
    - i18n possible côté client via codes
 
  Logger côté serveur :
    - L'entrée brute anonymisée (pas de mot de passe ni PII sensible)
    - L'user agent, l'IP source, la timestamp
    - Le code d'erreur retourné