← Back to glossary

Defence in Depth

General PHP 5.0+ Intermediate

debt(d7/e7/b7/t5)

d7 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints explicitly state automated detection is 'no'. Identifying whether a system has proper layered defences requires manual architectural review — no linter or SAST tool can determine if your WAF, application validation, parameterised queries, and least-privilege DB users form genuinely independent layers. Only careful security review reveals single-layer gaps.

e7 Effort Remediation debt — work required to fix once spotted

Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix lists multiple independent controls (input validation + prepared statements + WAF + least-privilege DB), but implementing genuine defence in depth across an existing codebase that lacks it requires touching authentication, database access patterns, input handling, and infrastructure configuration. This is not a localized fix but a cross-cutting architectural concern spanning multiple system layers.

b7 Burden Structural debt — long-term weight of choosing wrong

Closest to 'strong gravitational pull' (b7). This applies to all PHP contexts (web, api, cli) per applies_to, and as an architectural security principle, it shapes how every security-sensitive feature must be designed. Once you commit to defence in depth, every new feature must consider multiple independent control layers. However, it's not quite b9 because you could technically retrofit it incrementally rather than requiring a full rewrite.

t5 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'notable trap' (t5). The misconception field states developers believe defence in depth means 'redundant security controls doing the same thing' when it actually requires independent controls addressing different attack vectors. This is a documented gotcha that security-aware developers eventually learn, but competent generalist developers often conflate redundancy with layering until corrected.

About DEBT scoring → scored by claude-opus-4-5-20251101 · 2026-05-07 · reviewed by human

Also Known As

layered defence defence in depth security layering

TL;DR

Layering multiple independent security controls so that bypassing one does not compromise the whole system.

Explanation

Defence in depth is a security principle borrowed from military strategy. No single control is assumed to be perfect — instead, multiple independent layers are applied so that an attacker must defeat all of them. Example: a web app uses prepared statements (layer 1) + WAF (layer 2) + least-privilege database user (layer 3) + monitoring (layer 4). If the WAF is misconfigured, the prepared statements still prevent SQL injection. Each layer should be independent — not relying on other layers having already validated input.

Diagram

flowchart TD
    ATK[Attacker] --> L1[WAF - block known attacks]
    L1 --> L2[Authentication - verify identity]
    L2 --> L3[Authorization - verify permissions]
    L3 --> L4[Input Validation - sanitise data]
    L4 --> L5[Encryption - protect data at rest]
    L5 --> L6[Logging and Monitoring]
    L6 --> L7[Backups - recover from breach]
    INFO[Attacker must defeat every layer]
style ATK fill:#f85149,color:#fff
style L1 fill:#238636,color:#fff
style L7 fill:#238636,color:#fff

Common Misconception

✗ Defence in depth means redundant security controls doing the same thing. Layered defences address different attack vectors at different layers — a WAF, application-level input validation, parameterised queries, and least-privilege DB users each catch different attacks, not the same one repeatedly.

Why It Matters

Defence in depth layers multiple independent security controls — if one layer fails, others remain. A single vulnerability in one layer does not equal full compromise.

Common Mistakes

Relying solely on perimeter defences (firewall, WAF) and having no application-level controls.
Security layers that are identical rather than independent — the same flaw defeats all layers.
Not applying defence in depth to data access — assume SQL injection happens and encrypt sensitive columns.
Treating defence in depth as checkbox compliance rather than genuine layering of independent controls.

Code Examples

✗ Vulnerable

// Single layer — WAF as the only defence:
// WAF blocks known SQLi patterns
// But uses string-concatenated queries directly
// WAF bypass → direct database access
// Better: WAF + parameterised queries + least-privilege DB user + encrypted columns

✓ Fixed

// Multiple independent layers — each one fails safely
// Layer 1 — WAF blocks obvious attacks at CDN edge
// Layer 2 — Rate limiting at load balancer
// Layer 3 — Authentication middleware
// Layer 4 — Authorisation check in controller
// Layer 5 — Input validation in Form Request
// Layer 6 — Prepared statements — SQL injection impossible even if validation bypassed
// Layer 7 — Output encoding — XSS impossible even if data is tainted
// Layer 8 — CSP headers — XSS payload can't exfiltrate even if rendered

// In code — don't rely on a single guard:
public function update(Request $req, int $id): JsonResponse {
    $req->validate(['name' => 'required|string|max:100']); // L5
    $user = User::findOrFail($id);
    if ($user->id !== auth()->id()) abort(403);             // L4
    $user->update(['name' => $req->name]);                 // L6 (Eloquent uses PDO)
    return response()->json(['name' => e($user->name)]);   // L7
}

References

https://en.wikipedia.org/wiki/Defense_in_depth_(computing)