Validation en profondeur

VérifiéSûr

Utilisez lorsque des données invalides provoquent des échecs profonds dans l'exécution, nécessitant une validation à plusieurs couches du système.

Spar Skills Guide Bot
DeveloppementIntermédiaire
23/07/2026
Claude CodeCursorWindsurfCodex
#validation#defense-in-depth#error-handling#debugging#input-validation

Recommandé pour

Synthèse automatique

Ce skill guide l'ajout de validations à chaque couche traversée par une donnée (point d'entrée, logique métier, garde d'environnement, journalisation de débogage) afin de rendre un bug structurellement impossible plutôt que simplement corrigé.

Points forts

  • Fournit un cadre clair en quatre couches avec des exemples TypeScript concrets pour chacune
  • Décrit une méthode de traçage du flux de données étape par étape pour localiser tous les points de contrôle
  • Explique comment tester chaque couche en tentant de contourner la précédente, ce qui évite les fausses impressions de sécurité
  • S'appuie sur un cas réel (projectDir vide déclenchant un git init au mauvais endroit) avec les quatre correctifs appliqués

Limites

  • Les exemples sont en TypeScript/Node.js ; l'adaptation à d'autres langages ou frameworks reste à la charge de l'utilisateur
  • Le skill ne discute pas du coût en duplication ni du moment où arrêter d'empiler les validations
  • Ne traite pas des schémas de validation déclaratifs (Zod, JSON Schema) qui pourraient remplacer certains contrôles manuels
Quand l'utiliser

À utiliser après avoir corrigé un bug causé par une donnée invalide, lorsqu'on veut empêcher sa réapparition par d'autres chemins d'exécution plutôt que se contenter d'un seul point de contrôle.

Quand l'éviter

À éviter sur du code jetable ou des scripts internes où la multiplication des validations coûte plus cher que le risque réel encouru.

Analyse de sécurité

Sûr
Score qualité88/100

The skill contains only instructional guidance and code examples about validation. It declares no tools and performs no execution, network access, file operations, or secret handling. There is no obfuscation or destructive instruction, so listing it poses no meaningful security risk.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Harden a fixed bug
We just fixed a bug where an empty projectDir made git init run in the repo root. Walk the data flow and add defense-in-depth validation at every layer so it can't happen again.
Validate a new API entry point
Add entry-point validation to createProject for the workingDirectory argument, and tell me which business-logic and environment guards I should also add downstream.
Prove layers can't be bypassed
Write tests that try to bypass Layer 1 validation for workspace initialization and confirm Layers 2 and 3 still catch the invalid input.

name: defense-in-depth description: Use when invalid data causes failures deep in execution, requiring validation at multiple system layers - validates at every layer data passes through to make bugs structurally impossible

Defense-in-Depth Validation

Overview

When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.

Core principle: Validate at EVERY layer data passes through. Make the bug structurally impossible.

Why Multiple Layers

Single validation: "We fixed the bug" Multiple layers: "We made the bug impossible"

Different layers catch different cases:

  • Entry validation catches most bugs
  • Business logic catches edge cases
  • Environment guards prevent context-specific dangers
  • Debug logging helps when other layers fail

The Four Layers

Layer 1: Entry Point Validation

Purpose: Reject obviously invalid input at API boundary

function createProject(name: string, workingDirectory: string) {
  if (!workingDirectory || workingDirectory.trim() === '') {
    throw new Error('workingDirectory cannot be empty');
  }
  if (!existsSync(workingDirectory)) {
    throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
  }
  if (!statSync(workingDirectory).isDirectory()) {
    throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
  }
  // ... proceed
}

Layer 2: Business Logic Validation

Purpose: Ensure data makes sense for this operation

function initializeWorkspace(projectDir: string, sessionId: string) {
  if (!projectDir) {
    throw new Error('projectDir required for workspace initialization');
  }
  // ... proceed
}

Layer 3: Environment Guards

Purpose: Prevent dangerous operations in specific contexts

async function gitInit(directory: string) {
  // In tests, refuse git init outside temp directories
  if (process.env.NODE_ENV === 'test') {
    const normalized = normalize(resolve(directory));
    const tmpDir = normalize(resolve(tmpdir()));

    if (!normalized.startsWith(tmpDir)) {
      throw new Error(
        `Refusing git init outside temp dir during tests: ${directory}`
      );
    }
  }
  // ... proceed
}

Layer 4: Debug Instrumentation

Purpose: Capture context for forensics

async function gitInit(directory: string) {
  const stack = new Error().stack;
  logger.debug('About to git init', {
    directory,
    cwd: process.cwd(),
    stack,
  });
  // ... proceed
}

Applying the Pattern

When you find a bug:

  1. Trace the data flow - Where does bad value originate? Where used?
  2. Map all checkpoints - List every point data passes through
  3. Add validation at each layer - Entry, business, environment, debug
  4. Test each layer - Try to bypass layer 1, verify layer 2 catches it

Example from Session

Bug: Empty projectDir caused git init in source code

Data flow:

  1. Test setup → empty string
  2. Project.create(name, '')
  3. WorkspaceManager.createWorkspace('')
  4. git init runs in process.cwd()

Four layers added:

  • Layer 1: Project.create() validates not empty/exists/writable
  • Layer 2: WorkspaceManager validates projectDir not empty
  • Layer 3: WorktreeManager refuses git init outside tmpdir in tests
  • Layer 4: Stack trace logging before git init

Result: All 1847 tests passed, bug impossible to reproduce

Key Insight

All four layers were necessary. During testing, each layer caught bugs the others missed:

  • Different code paths bypassed entry validation
  • Mocks bypassed business logic checks
  • Edge cases on different platforms needed environment guards
  • Debug logging identified structural misuse

Don't stop at one validation point. Add checks at every layer.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/defense-in-depth-validation-mrx3xzty' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/defense-in-depth-validation-mrx3xzty/download' --output '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md.part' && mv '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md.part' '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && test -s '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/defense-in-depth' && cp -R '.skill-downloads/defense-in-depth-validation-mrx3xzty' '.claude/skills/defense-in-depth'

Cursor
test -f '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && test -s '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/defense-in-depth' && cp -R '.skill-downloads/defense-in-depth-validation-mrx3xzty' '.cursor/skills/defense-in-depth'

Codex
test -f '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && test -s '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/defense-in-depth' && cp -R '.skill-downloads/defense-in-depth-validation-mrx3xzty' '.agents/skills/defense-in-depth'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/defense-in-depth-validation-mrx3xzty'

openskills read 'defense-in-depth-validation-mrx3xzty'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires