Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
secondsky avatar

Defense In Depth Validation

  • 326 installs
  • 202 repo stars
  • Updated August 4, 2026
  • secondsky/claude-skills

defense-in-depth-validation is a secondsky Claude skill that enforces validation at every layer data passes through so invalid inputs cannot cause deep execution failures in backend systems.

About

defense-in-depth-validation is a secondsky/claude-skills package at version 1.1.0 under MIT license teaching agents to validate data at every layer it traverses rather than patching a single bug location. The core principle states that one validation check can be bypassed by alternate code paths, refactoring, or test mocks, so entry-point schema checks, service-layer guards, and persistence-boundary sanitization must align to make invalid-state bugs structurally impossible. Developers reach for defense-in-depth-validation when invalid data causes failures deep in execution stacks, when APIs accept external payloads, or when mocks hide missing validation in tests. The skill contrasts single-point fixes with layered enforcement patterns applicable across HTTP handlers, domain services, and database writes. It fits backend and agent-tooling codebases where untrusted input flows through multiple modules. Trigger when reviews surface data integrity bugs that reappear after superficial fixes, or when designing new endpoints that must reject bad input before business logic executes.

  • defense-in-depth-validation

Defense In Depth Validation by the numbers

  • 326 all-time installs (skills.sh)
  • +17 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #1,265 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/secondsky/claude-skills --skill defense-in-depth-validation

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs326
repo stars202
Last updatedAugust 4, 2026
Repositorysecondsky/claude-skills

How do you validate data at every system layer?

Use defense-in-depth-validation for development tasks

Who is it for?

Backend developers fixing data-integrity bugs that resurface when code paths, refactors, or mocks bypass a single validation check.

Skip if: Pure UI styling tasks or security penetration testing unrelated to input validation architecture across application layers.

When should I use this skill?

Invalid data causes deep execution failures, a bug fix added only one validation point, or the user asks for defense-in-depth input checking.

What you get

Multi-layer validation guards at entry points, services, and persistence boundaries with aligned schemas that block invalid data structurally.

  • layered validation schemas
  • entry-point guards
  • persistence boundary checks

By the numbers

  • Skill metadata version 1.1.0 under MIT license

Files

SKILL.mdMarkdownGitHub ↗

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.

Related skills

How it compares

Apply defense-in-depth-validation when data bugs keep returning after single-layer fixes instead of relying on one Zod or JSON schema at the API edge only.

FAQ

Why does defense-in-depth-validation reject single-point fixes?

defense-in-depth-validation argues one validation check can be bypassed by different code paths, refactoring, or test mocks. Layered checks at entry, service, and persistence boundaries make invalid-data bugs structurally impossible.

What version is defense-in-depth-validation?

defense-in-depth-validation is version 1.1.0 in secondsky/claude-skills metadata, distributed under the MIT license as a Code Review and Quality pattern for multi-layer input validation.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.