Revenir au README

Compétence RNCP : C2.2.3

• Mesures d'accessibilité : ACCESSIBILITY.md
• Cahier de recettes : ACCEPTANCE.md
• Journal de versions : CHANGELOG.md
• Intégration Continue : CI.md
• Déploiement Continue : CD.md

Ce document présente les mesures de sécurité mises en place et planifiées dans LockLite, en lien avec le Top 10 OWASP 2021.
L’objectif est de garantir l’évolutivité et la sécurité du code source.

• Chaque coffre-fort est lié à un seul et unique identifiant utilisateur.
• Des tests de recette vérifient la relation entre utilisateurs et coffres-forts en base de données.
• Mise en place du partage de coffres-forts via une relation many-to-many.

• Introduction d’un contrôle d’accès basé sur les rôles (RBAC).
• Définir et appliquer des droits : lecture seule, édition, suppression (ACL)

• À ce stade, les secrets ne sont pas encore chiffrés.

• Mise en place du chiffrement des secrets utilisateurs (prochainement).
• Chiffrement des usernames (email/identifiant) dans une version ultérieure.

• Utilisation de Prisma (ORM) qui protège nativement contre les injections SQL.
• TypeScript strict et DTO partagés entre UI et API.
• Recettes de tests validant la longueur maximale des entrées (les noms des coffres-forts ne doivent pas dépasser 255 caractères).

• Ajouter une validation centralisée des données entrantes côté API (par exemple zod ou class-validator).
• Ajouter des tests d'injections dans le cahier de recettes

• Interdire l'usage de dangerouslySetInnerHTML

• Authentification via NextAuth avec gestion sécurisée de session.
• Messages d’erreur d’authentification uniformisés ("invalid credentials").
• UUID utilisés pour masquer les identifiants métiers.
• Protection CSRF intégrée par défaut dans NextAuth.

• Mise en place d’un mécanisme anti-brute force (limite de tentatives de connexion).
• Ajout progressif de la gestion des rôles (RBAC).

• Définir une politique de mot de passe stricte (pour les mots de passe maîtres).
• Vérifier que les cookies de session soient sécurisés (HttpOnly, Secure, SameSite=strict).
• Ajouter une authentification multifactorielle

• Analyse automatique du repository pour détecter les fuites de secrets (GitGuardian).
• Blocage des merges si un secret sensible est détecté.
• Configuration par défaut de Next.js et NextAuth.
• TypeScript configuré en mode strict.
• ESLint et Prettier appliqués en continu.
• Sessions gérées par JWT avec un secret dédié.
• Politiques de rotation des secrets.
• Mise en place de différents environnements (développement, préproduction et production)
• Désactivation du Swagger en production

• Mise en place d'une authentification sur l'API (Bearer Authentication)

• Durcissement des en-têtes HTTP via un module de sécurisation adapté.

• Adoption du versioning SemVer.
• Journal de versions avec une catégorie dédiée aux correctifs de sécurité.
• Mise en place de Dependabot pour la gestion proactive des dépendances.
• Définir une politique de mise à jour automatisée et validée en CI/CD.

• Intégration de GitGuardian pour prévenir toute fuite de secrets avant un déploiement.
• Authentification centralisée avec NextAuth
• Mots de passe maîtres hashés avec bcrypt.
• Messages d’erreur neutres pour éviter l’énumération des comptes.

• Ajout d’une limitation du nombre de tentatives de connexion.
• Ajouter une politique de mots de passe (longueur, minuscules, majuscules, chiffres, caractères spéciaux etc) pour les mots de passe maîtres
• Réinitialisation possible du mot de passe maître utilisateur

• Ajouter une authentification multifactorielle

• CI via GitHub Actions avec tests, linter et build obligatoires.
• Branche main protégée par des règles de merge strictes.
• Définir une politique de mise à jour automatisée et validée en CI/CD.

• Protection de la branche develop également.
• Déploiement (CD) déclenché uniquement si la CI est validée.

• Logger centralisé utilisé à la fois côté API, et à la fois côté UI.
• Journaux natifs de Next.js pour toutes les routes.
• Mise en place d’un outil de supervision (Sentry).

• Définir les événements critiques à journaliser (échecs d’authentification, accès refusés, erreurs serveur).

• Aucun champ URL manipulé par l’utilisateur.
• Pas d’appels sortants sensibles dans la première version.

• Validation stricte des URLs lors de l’introduction du champ "URL".