Analyse du scan de securite VICE

Contexte

Un scan VICE a ete execute sur le projet outil-bdd.

Rapport analyse :

• HTML : /Users/romainc.heriade/.vice/scans/vice-report-outil-bdd-1777283721733.html
• JSON : /Users/romainc.heriade/.vice/scans/vice-report-outil-bdd-1777283717039.json

Le rapport donne une note F, mais cette note ne doit pas etre prise comme un verdict brut. Le scan melange des risques reels, des faux positifs et des controles generiques qui ne connaissent pas l'architecture du projet.

Synthese

Le projet n'est pas dans un etat "tout est critique", mais il y a des actions securite a traiter.

Les vrais sujets prioritaires sont :

1. Mettre a jour les dependances vulnerables.
2. Durcir les headers HTTP et la configuration CORS.
3. Clarifier la strategie de stockage du token applicatif cote front.
4. Decider explicitement si les regles Supabase RLS sont applicables au projet.
5. Completer le .gitignore racine pour eviter les erreurs futures sur les fichiers .env.

Findings VICE a relativiser

Secret dans un test

VICE remonte test-app-access-token-secret dans back/src/guards/authGuard.spec.ts.

Verdict : faux positif.

Pourquoi :

• la valeur est dans un fichier de test ;
• elle est statique et volontaire ;
• elle ne correspond pas a un secret de production.

Action :

• aucune correction urgente ;
• conserver la convention explicite test-* pour eviter toute ambiguite.

.env is not in .gitignore

Verdict : partiellement faux.

Pourquoi :

• back/.env est ignore par back/.gitignore ;
• front/.env est ignore par front/.gitignore ;
• les fichiers .env.example sont bien versionnes, ce qui est normal.

Risque restant :

• un futur .env cree a la racine du repo ne serait pas ignore.

Action recommandee :

• ajouter .env* dans le .gitignore racine ;
• conserver les exceptions si necessaire pour les exemples :

.env*
!.env.example

innerHTML dans VitePress cache

VICE remonte des usages de innerHTML dans docs/.vitepress/cache.

Verdict : faux positif pratique.

Pourquoi :

• ce sont des fichiers generes par VitePress ;
• ils ne sont pas suivis par Git ;
• ils ne representent pas du code applicatif maintenu par l'equipe.

Action :

• ne pas corriger ces fichiers generes ;
• verifier que docs/.vitepress/cache/ et docs/.vitepress/dist/ restent ignores.

Session sans httpOnly

VICE indique une session sans httpOnly dans le front.

Verdict : finding mal formule.

Pourquoi :

• le front ne configure pas de cookie de session ;
• httpOnly ne peut pas etre applique a localStorage ;
• le vrai sujet est le stockage du app_access_token dans localStorage.

Risque reel :

• en cas de XSS, un script injecte peut lire le token dans localStorage.

Actions possibles :

• court terme : ajouter une CSP stricte et reduire fortement le risque XSS ;
• moyen terme : etudier un flux avec cookie httpOnly, Secure, SameSite, si compatible avec le portail auth ;
• garder des tokens courts et un mecanisme de refresh controle.

Findings VICE a traiter

Headers HTTP de securite

VICE ne trouve pas de CSP ni de HSTS.

Verdict : valide, sauf si ces headers sont poses par le reverse proxy.

Pourquoi :

• une CSP limite l'impact des XSS ;
• HSTS force l'usage de HTTPS cote navigateur ;
• d'autres headers reduisent les risques classiques : clickjacking, MIME sniffing, referrer leakage.

Actions :

• si les headers sont geres par l'infra : le documenter ;
• sinon ajouter helmet cote NestJS ;
• definir une CSP compatible avec le front, Quasar, Vite et les domaines d'authentification.

CORS trop permissif

Le backend utilise app.enableCors() sans restriction visible.

Verdict : a corriger.

Pourquoi :

• une API authentifiee doit limiter les origins autorisees ;
• une configuration large complique l'analyse des risques avec les tokens front.

Action :

• lire une liste d'origins depuis l'environnement ;
• refuser par defaut les origins inconnues ;
• documenter les origins attendues pour dev, staging et production.

Supabase RLS

VICE remonte toutes les tables SQL comme creees sans RLS.

Verdict : a qualifier avant correction.

Pourquoi :

• si la base est exposee directement via Supabase client avec des roles anon ou authenticated, l'absence de RLS est critique ;
• si la base est uniquement accedee par le backend NestJS via Prisma avec un compte serveur, RLS peut etre non applicable ;
• la recommandation automatique auth.uid() = user_id est trop generique et fausse pour plusieurs tables.

Action :

• confirmer le modele d'acces reel a la base ;
• si Supabase expose directement les tables, concevoir des policies par cas metier ;
• sinon documenter que l'isolation est portee par le backend et les guards applicatifs.

Ce que VICE a rate

VICE n'a pas remonte les vulnerabilites de dependances. Les audits Yarn ont identifie des paquets a mettre a jour.

Front

Dependances concernees :

• [email protected] : advisories sur le dev server, corrigees en >=8.0.5 ;
• [email protected] : advisories corrigees en >=1.15.0 ;
• follow-redirects via axios : corrige en >=1.16.0 ;
• postcss <8.5.10.

Priorite :

• mettre a jour vite et axios en premier ;
• relancer tests unitaires et E2E front.

Note :

• le serveur Vite front est configure sur 127.0.0.1, ce qui reduit le risque des CVE Vite liees au dev server expose sur le reseau.

Back

Dependances concernees notamment :

• @nestjs/core <=11.1.17 ;
• path-to-regexp via NestJS ;
• lodash via @nestjs/swagger et @nestjs/cli ;
• fast-xml-parser via AWS SDK ;
• uuid <14.0.0 ;
• dependances transitives de Prisma et des outils de build.

Priorite :

• mettre a jour NestJS et Swagger ensemble ;
• mettre a jour AWS SDK ;
• verifier Prisma avec prudence, car les updates peuvent toucher le client genere ;
• relancer tests back unitaires et E2E.

Docs

Dependances concernees :

• vitepress tire des versions vulnerables de vite, esbuild et postcss.

Priorite :

• mettre a jour VitePress ;
• reconstruire la documentation.

Plan d'action recommande

Priorite 1

• Mettre a jour les dependances vulnerables front, back et docs.
• Ajouter .env* au .gitignore racine.
• Restreindre CORS cote backend.

Priorite 2

• Ajouter ou documenter les headers HTTP de securite.
• Ajouter une CSP progressive, d'abord en mode test si necessaire.
• Clarifier la strategie localStorage vs cookie httpOnly pour le token applicatif.

Priorite 3

• Qualifier le besoin RLS Supabase.
• Si RLS est applicable, ecrire des policies specifiques au modele metier.
• Documenter explicitement les faux positifs acceptes pour eviter de retraiter les memes alertes a chaque scan.

Verification apres correction

Commandes utiles :

cd front && yarn audit --json
cd back && yarn audit --json
cd docs && yarn audit --json

Tests a relancer :

cd front && yarn test
cd front && yarn test:e2e
cd back && yarn test
cd back && yarn test:e2e
cd docs && yarn build

Decision

Le rapport VICE doit etre utilise comme une checklist de depart, pas comme source unique de verite.

Les corrections doivent etre priorisees selon l'exploitabilite reelle :

• dependances vulnerables ;
• headers et CORS ;
• exposition eventuelle de la base ;
• stockage du token cote navigateur ;
• hygiene Git autour des fichiers .env.