Pourquoi la sécurité ne peut pas être une réflexion après coup
Chaque semaine, des milliers d'applications web sont compromises. Des bases de données clients vendues sur le dark web, des rançongiciels qui paralysent des entreprises entières, des données personnelles exposées. La plupart de ces incidents auraient pu être évités avec des pratiques de base.
Chez Unziptech, la sécurité est intégrée dès la conception — pas ajoutée à la dernière minute. Voici les sept pratiques que nous appliquons systématiquement.
1. Validation et assainissement de toutes les entrées
La règle d'or : ne jamais faire confiance aux données qui viennent de l'extérieur. Formulaires, paramètres d'URL, en-têtes HTTP, données JSON — tout doit être validé et assaini avant d'être traité.
Côté backend (Spring Boot), nous utilisons Bean Validation avec des annotations comme @NotBlank, @Size, @Pattern. Les injections SQL sont éliminées en utilisant des requêtes paramétrées ou des ORM (Hibernate, JPA) qui n'interpolent jamais de données utilisateur directement dans les requêtes.
2. Authentification robuste avec JWT et refresh tokens
Les sessions basées sur les cookies sont de moins en moins adaptées aux architectures modernes (API-first, microservices). Nous utilisons systématiquement :
- JWT (JSON Web Tokens) pour les tokens d'accès, avec une durée de vie courte (15-30 minutes)
- Refresh tokens chiffrés, stockés en base, avec rotation à chaque usage
- Hachage bcrypt (ou Argon2) pour les mots de passe — jamais MD5 ou SHA-1 plain
3. HTTPS partout, HSTS activé
Aucune application que nous livrons ne fonctionne en HTTP non chiffré. Le certificat TLS (via Let's Encrypt) est mis en place dès le premier déploiement, et l'en-tête Strict-Transport-Security force le navigateur à toujours utiliser HTTPS.
4. En-têtes de sécurité HTTP
Quelques lignes de configuration serveur ou middleware qui font une grande différence :
Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Ces en-têtes protègent contre les attaques XSS, le clickjacking, et le MIME sniffing.
5. Gestion sécurisée des secrets
Les clés API, mots de passe de base de données, secrets JWT ne doivent jamais apparaître dans le code source. Nous utilisons :
- Variables d'environnement injectées au moment du déploiement
- GitHub Secrets ou Vault pour les pipelines CI/CD
- Rotation régulière des clés critiques
Un simple git log ne doit jamais révéler de secret.
6. Limitations de débit (Rate Limiting)
Sans rate limiting, vos endpoints d'authentification sont vulnérables aux attaques par force brute. Nous configurons systématiquement des limites sur :
- Les routes de login (5 tentatives / minute par IP)
- Les endpoints d'API publics (100 requêtes / minute)
- Les envois de formulaires (protection anti-spam)
7. Audits de dépendances automatisés
Vos dépendances NPM ou Maven contiennent peut-être des vulnérabilités connues. Nos pipelines CI/CD exécutent npm audit et mvn dependency-check:check à chaque build. Les dépendances critiques sont mises à jour en priorité.
La sécurité comme culture, pas comme checklist
Ces pratiques ne sont pas une liste à cocher une fois — elles doivent faire partie de la culture de développement. Chez Unziptech, chaque revue de code inclut une dimension sécurité, et nous formons régulièrement notre équipe aux nouvelles menaces.
Votre application mérite cette rigueur. Parlons de votre projet.
Publié par Unziptech.com, le propriétaire de ce blog, et relié à rentalme.ma, son produit de location de voitures.