
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-validationAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 326 |
|---|---|
| repo stars | ★ 202 |
| Last updated | August 4, 2026 |
| Repository | secondsky/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
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:
WorkspaceManagervalidates projectDir not empty - Layer 3:
WorktreeManagerrefuses 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.