Sécurité web sans paranoïa : les 5 problèmes récurrents des PME

La sécurité web est souvent abordée avec le Top 10 OWASP, un document qui finit par paralyser les équipes : trop de points à vérifier, et le projet entre dans une logique de « on verra plus tard ». Résultat ? Le « plus tard » arrive généralement quand le problème est déjà là.

Prenons les choses à l’inverse. Voici les 5 problèmes concrets que nous rencontrons le plus fréquemment dans les projets de PME déjà en production. Si vous les résolvez, vous serez mieux protégés que 90 % des applications web en circulation.

1. Validation uniquement côté frontend

L’erreur la plus fréquente : le formulaire contient une validation JavaScript côté client (« ce champ est obligatoire », « l’email doit contenir un @ », etc.), tandis que le backend suppose que les données envoyées sont valides.

Le problème ? N’importe qui peut contourner cette validation avec cURL, Postman ou les outils de développement du navigateur pour envoyer n’importe quoi au backend.

Solution : toute validation critique doit impérativement être reproduite côté backend. Le frontend sert à améliorer l’expérience utilisateur (affichage rapide des erreurs), tandis que le backend garantit la sécurité (protection de la base de données contre les données corrompues).

Dans des projets comme Mon Assurance Auto, où des données personnelles sont traitées et des devis d’assurance sont générés, chaque champ est validé deux fois : côté client pour un retour immédiat, et côté serveur pour une confiance totale.

2. Secrets hardcodés dans le code

C’est un classique que nous rencontrons bien trop souvent lors d’audits. Clés API, mots de passe de base de données, tokens de services… tout est stocké directement dans le dépôt, dans des fichiers comme config.js ou constants.ts.

Double problème :

• Tout développeur ayant accès au code (y compris ceux qui ont quitté l’entreprise) peut accéder aux systèmes.
• Si le dépôt est exposé (ce qui arrive plus souvent qu’on ne le pense), les secrets deviennent publics.

Solutions :

• Stocker toutes les identifiants dans des variables d’environnement (fichier .env).
• Ajouter .env dans .gitignore.
• Créer un .env.example avec les variables sans valeurs réelles.
• Pour la production, utiliser un gestionnaire de secrets (Vercel, AWS Secrets Manager, etc.).
• Rotater les identifiants lorsqu’un collaborateur quitte l’équipe.

3. Absence de Row Level Security dans les bases multi-locataires

Si votre application gère plusieurs clients/utilisateurs qui ne doivent pas voir les données des autres, l’isolation ne peut pas reposer uniquement sur un filtre dans le code de l’application.

Exemple typique : une requête SQL du type WHERE user_id = ? qui suppose que le code mettra toujours le bon ID. Une vulnérabilité IDOR (Insecure Direct Object Reference) ou un bug dans un endpoint peut exposer les données d’un utilisateur à un autre.

Solution : activer la Row Level Security (RLS) directement au niveau de la base de données. Avec Postgres (et donc Supabase), cela se configure via des politiques RLS qui s’appliquent automatiquement. La base de données ne retourne aucune ligne qui ne correspond pas à l’utilisateur actuel, peu importe comment la requête est écrite.

C’est une couche de défense supplémentaire qui vaut de l’or. Même si un endpoint oublie le filtre ou qu’un attaquant parvient à exécuter une requête inattendue, la RLS protège toujours les données.

4. Authentification maison

« On a développé notre propre système d’authentification pour garder le contrôle et c’est plus sûr. » → Faux. C’est le meilleur moyen de créer un problème sérieux.

Créer un système d’authentification robuste (hashage des mots de passe avec Argon2 ou bcrypt, tokens JWT avec rotation, récupération sécurisée, prévention des timing attacks, limitations de tentatives, etc.) prend des semaines et échoue rarement à la première tentative.

Solution : utiliser un service mature comme Supabase Auth, Auth0, Clerk ou NextAuth/Auth.js. Ces solutions gèrent les cas complexes et suivent les meilleures pratiques. Votre code se contente d’orchestrer, sans implémenter de cryptographie.

5. Logs contenant des informations sensibles

Quand un bug survient en production, l’instinct est de logger tout le contexte. Problème : parmi ces données, on trouve souvent des mots de passe en clair (venant du body de la requête), des tokens, des numéros de cartes bancaires ou des identifiants personnels.

Ces logs finissent stockés dans des outils comme Sentry, Datadog ou CloudWatch, accessibles à plus de personnes qu’il ne faudrait, et peuvent persister pendant des mois.

Solutions :

• Établir une liste des champs sensibles qui ne doivent jamais être logués (password, token, creditCard, ssn, dni).
• Nettoyer les logs avant enregistrement : remplacer automatiquement les valeurs sensibles par ***.
• Revoir périodiquement les logs pour détecter d’éventuelles fuites.

Ce qui ne figure pas dans cette liste (intentionnellement)

OWASP mentionne des risques plus avancés comme les XSS, les injections SQL ou la désérialisation non sécurisée. Ces problèmes sont importants, mais les frameworks modernes (React, Next.js, ORM comme Prisma) les couvrent par défaut si vous ne les contournez pas activement. Pour une PME qui démarre, les 5 points ci-dessus offrent un meilleur retour sur investissement que de se battre contre des attaques CSRF quand votre application est déjà bien configurée avec Next.js.

Conclusion

La sécurité n’est pas un projet ponctuel, mais une habitude. Si vous couvrez ces 5 points lors du développement, les revoyez chaque année et maintenez vos dépendances à jour, vous serez en bonne position. Si aucun de ces points n’a jamais été envisagé et que votre application en production gère des données clients, une révision s’impose.

Vous souhaitez une audit pragmatique de votre application (pas un PDF de 80 pages, mais un rapport avec des actions concrètes à prioriser) ? Contactez-nous.

---

Par Esteban Aleart, Fondateur et Lead Engineer chez Pair Programming.