Développement accéléré par l’IA

Corriger un audit sécurité point par point

Après avoir obtenu un audit de sécurité personnalisé sur BodySync, j’aurais pu simplement appliquer les corrections les plus évidentes et passer à autre chose.

J’ai préféré prendre le temps de traiter les problèmes un par un. L’objectif n’était pas seulement de “faire disparaître” des alertes, mais de comprendre ce que chaque recommandation voulait dire, quel risque elle réduisait et comment vérifier que la correction ne cassait pas l’application.

Avancer par couches

La sécurité peut vite devenir intimidante si on essaie de tout corriger d’un seul coup.

Pour BodySync, l’approche la plus utile a été de travailler par couches successives :

les dépendances

les accès aux données

les appels externes

l’authentification

les abus automatisés

les données envoyées aux services tiers

les tailles de contenu persisté

les en-têtes de sécurité

les logs côté client

Chaque couche réduit un type de risque. Cette méthode rend le travail plus lisible et évite de mélanger une faille critique avec une optimisation secondaire.

Commencer par les dépendances

La première étape a été de regarder les paquets du projet avec npm audit.

Dans un projet Angular ou Node, c’est souvent le point d’entrée le plus simple :

npm audit

Puis, quand les corrections sont raisonnables :

npm audit fix

Après chaque correction, j’ai relancé le build pour vérifier que l’application continuait à compiler.

npm run build

Le but n’est pas toujours d’obtenir zéro alerte instantanément. Certaines vulnérabilités demandent des montées de version plus larges. Mais les alertes critiques ou hautes doivent être comprises et traitées en priorité.

Ne plus exposer les traitements sensibles

L’audit avait aussi pointé un sujet important : les appels n8n exposés côté client.

C’est une erreur fréquente quand on prototype vite. Le frontend appelle directement un webhook, l’URL se retrouve dans le bundle JavaScript, puis n’importe qui peut la récupérer et déclencher le workflow.

La correction logique consiste à déplacer cette responsabilité derrière une API ou une Cloud Function.

Le navigateur appelle une route interne, par exemple /api/coach-advice. Le backend vérifie l’utilisateur, valide le payload, contrôle le quota, garde les secrets côté serveur, appelle le webhook réel, puis retourne seulement la réponse nécessaire.

Cette étape m’a surtout aidé à mieux comprendre une règle simple : tout ce qui est sensible ne doit pas dépendre uniquement du frontend.

Durcir les règles Firestore

Un autre point important concernait les règles de base de données.

Au départ, les règles limitaient bien l’accès par utilisateur. C’est déjà essentiel, mais ce n’est pas suffisant. Un utilisateur authentifié peut encore envoyer des champs inattendus, des chaînes trop longues, des nombres aberrants ou des timestamps falsifiés si les règles ne vérifient pas la forme des données.

J’ai donc travaillé les règles comme un vrai contrat :

champs autorisés explicitement listés

champs obligatoires présents

types contrôlés

longueurs maximales

bornes sur les valeurs métier

refus des champs inattendus

timestamps mieux encadrés

Ce travail est moins visible qu’une interface, mais il change la solidité réelle de l’application.

Ajouter des barrières contre les abus

L’audit rappelait aussi que l’authentification ne suffit pas toujours.

Un compte peut être créé automatiquement. Un script peut consommer des ressources en boucle. Une clé Firebase publique n’est pas un secret, donc il faut ajouter d’autres barrières.

Les pistes les plus importantes sont :

Firebase App Check

quotas

rate limiting

vérification d’email

restrictions de domaines

alertes de consommation

blocage de certaines écritures pour les comptes non vérifiés

Ces protections ne rendent pas l’application invincible, mais elles réduisent les abus simples et donnent plus de contrôle.

Minimiser les données envoyées

BodySync manipule des données personnelles liées au suivi physique. C’est donc un sujet sensible.

L’audit m’a poussé à poser une question très concrète pour chaque appel externe :

Est-ce que ce service a vraiment besoin de toutes ces données ?

Pour un service IA, la réponse est souvent non. Il est parfois possible d’envoyer un résumé, quelques mesures récentes, un échantillon, ou des données moins identifiantes au lieu d’un historique complet.

La minimisation est une règle simple : envoyer moins, mais mieux.

Limiter avant d’enregistrer

J’ai aussi revu la taille des contenus persistés.

Les notes, commentaires, réponses IA, champs de profil, exports ou logs peuvent devenir des vecteurs d’abus si aucune limite n’est appliquée.

Une limite de caractères protège la base, réduit les coûts et évite de stocker des réponses trop volumineuses.

Ce n’est pas spectaculaire, mais c’est une des corrections les plus pragmatiques.

Tester après chaque correction

Le point le plus formateur a été de tester après chaque couche.

Après un durcissement, il ne suffit pas de vérifier que le build passe. Il faut aussi rejouer les parcours importants :

inscription

connexion

écriture en base

modification

suppression

appel API

affichage mobile

navigation privée

compte non vérifié

connexion Google

données invalides

Un bon durcissement bloque ce qui doit être bloqué sans casser les usages légitimes.

Ce que j’ai appris

Corriger un audit de sécurité m’a permis de mieux comprendre les enjeux derrière les recommandations.

Une dépendance vulnérable, ce n’est pas juste une ligne rouge dans un rapport. Un webhook exposé, ce n’est pas juste une URL mal placée. Une règle Firestore trop permissive, ce n’est pas seulement un détail de configuration.

Chaque point raconte une manière possible d’abuser de l’application, de consommer des ressources, d’écrire des données incohérentes ou d’exposer des informations sensibles.

Bilan

Cette deuxième étape a transformé l’audit en apprentissage.

La méthode qui a le mieux fonctionné tient en quatre mots : observer, prioriser, corriger, tester.

En prenant le temps de traiter chaque problème point par point, j’ai renforcé BodySync, mais j’ai surtout mieux compris comment construire une sécurité progressive et réaliste. Pas une forteresse théorique, mais des couches cohérentes qui rendent l’application plus durable.