Réponse courte : Construisez la sécurité autour des frontières de confiance : authentifiez correctement, autorisez chaque action et objet sensibles, contraignez les entrées, protégez les flux navigateur et vérifiez les contrôles avec des tests négatifs.
1. Cartographier les actifs et frontières de confiance
Commencez par les parcours qui déplacent de l'argent, exposent des données privées, changent des privilèges ou appellent un autre système. Dessinez les transitions entre navigateur anonyme, session authentifiée, API, workers, stockage et services tiers. Pour chaque transition, notez l'identité utilisée et la décision d'autorisation attendue.
Transformez cette carte en scénarios d'abus : un membre lit un autre workspace, le proxy d'images appelle une adresse privée ou un webhook falsifié modifie un abonnement. Vous obtenez des tests concrets plutôt qu'une liste générique.
2. Séparer authentification, session et autorisation
L'authentification établit qui agit ; la session transporte cette identité ; l'autorisation décide si elle peut effectuer cette action sur cet objet. Gardez ces décisions côté serveur. Utilisez des bibliothèques établies, renouvelez l'identifiant de session après connexion ou élévation de privilège, configurez HttpOnly, Secure et un SameSite adapté, puis réauthentifiez les changements critiques.
L'autorisation doit s'exécuter sur chaque requête, y compris API, exports, fichiers privés et tâches de fond. Préférez une politique de refus par défaut et des requêtes déjà limitées au tenant courant.
3. Contraindre les entrées au point d'utilisation
Validez côté serveur la syntaxe et les règles métier : types, longueurs, valeurs autorisées, transitions d'état et propriété. La validation ne remplace pas l'encodage de sortie. Paramétrez les requêtes de base de données et évitez de transmettre des valeurs utilisateur à un shell ou un moteur de template dynamique.
Pour les URL sortantes, autorisez des schémas et destinations connus, résolvez puis contrôlez les adresses, refusez loopback, réseaux privés et link-local, limitez les redirections et appliquez un filtrage réseau sortant.
const project = await db.project.findFirst({
where: { id: input.projectId, workspaceId: session.workspaceId }
});
if (!project || !session.permissions.includes("project:update")) {
return response(404);
}
await updateProject(project.id, validatedPatch);4. Protéger les flux navigateur
Utilisez HTTPS partout et n'envoyez HSTS que depuis le déploiement HTTPS. Ajoutez une CSP testée, des restrictions de framing, X-Content-Type-Options: nosniff, une politique de référent prudente et une Permissions Policy. Les requêtes qui changent l'état avec un cookie exigent une protection CSRF ; SameSite aide mais ne suffit pas toujours.
Les uploads demandent des contrôles indépendants de taille, type attendu, nom de stockage généré et mode de restitution sûr. Stockez-les hors des chemins exécutables.
5. Vérifier avant la mise en production
Ajoutez des tests négatifs pour utilisateur anonyme, mauvais rôle, mauvais tenant, identifiant deviné et session périmée. Testez limites de débit et récupération. Exécutez les contrôles de dépendances et secrets en continu, puis utilisez une revue manuelle ciblée pour les règles métier et abus multi-étapes.
Erreurs fréquentes
- Masquer un bouton sans protéger l'action API.
- Vérifier le rôle sans vérifier la propriété ou le tenant.
- Accepter toute URL HTTPS dans un fetch serveur.
- Échapper une entrée une fois puis la réutiliser en HTML, SQL et URL.
- Journaliser tokens, liens de réinitialisation ou corps sensibles complets.
- Copier une CSP d'une autre application sans la tester.
Checklist de mise en production
- Actifs critiques et transitions de confiance documentés.
- Chaque route et objet sensible possède un test d'autorisation serveur.
- Sessions avec cookies sûrs et rotation aux changements de privilège.
- Requêtes paramétrées et sorties encodées selon leur contexte.
- Requêtes sortantes limitées par destination et règles réseau.
- CSRF, clickjacking et types de contenu testés.
- Secrets hors du code et procédure de rotation prête.
- Tests d'intégration négatifs exécutés en CI.
Limites
Une checklist ne modélise pas toutes les règles produit, configurations de production ou dépendances tierces. Une revue statique ne prouve pas non plus le comportement du système déployé. Combinez conception sûre, automatisation, revue manuelle et test d'exécution autorisé selon le risque.
Sources primaires
Ressources liées
Faire relire une mise en production sensible
Appliquer ces contrôles au code et aux frontières produit réelles.