Hygiene — Trust No Data

Overview

Security hygiene is the discipline of treating all data as untrusted at every component boundary — not just data from end users. Internal databases, caches, message queues, partner APIs, configuration stores, and even your own microservices can deliver data that is malformed, stale, tampered with, or injected. A compromised internal system, a poisoned cache entry, or a corrupted database row can be just as dangerous as a malicious HTTP request.

The core principle: sanitize, validate, and encode at the boundary of every component, not just at the perimeter.

"The Jenga tower of trust collapses when any single block is compromised. Don't assume the block below you is sound — verify it."

The Trust Boundary Model

Every component has boundaries where data enters and exits. Each boundary is a point where hygiene must be enforced.

                    ┌─────────────────────┐
  User Input ──────►│                     │──────► Database
                    │    Your Component   │
  Database ────────►│                     │──────► API Response
                    │   SANITIZE HERE     │
  Message Queue ───►│   ON EVERY EDGE     │──────► Message Queue
                    │                     │
  Cache ───────────►│                     │──────► Logs
                    │                     │
  Partner API ─────►│                     │──────► Downstream Service
                    └─────────────────────┘

Why Internal Sources Are Untrusted

Sanitization

Sanitization removes or neutralizes dangerous content from data. It should happen on input to your component, before the data is processed or stored.

Strategies

Sanitize Both Directions

• •Inbound: Validate and sanitize data entering your component from any source.
• •Outbound: Encode data leaving your component for the target context (HTML, SQL, shell, URL, JSON, XML).

  Inbound                           Outbound
  ────────                          ────────
  Validate type/format              Encode for HTML context
  Enforce allowlist                 Encode for SQL (parameterize)
  Strip/escape dangerous chars      Encode for shell (avoid shell if possible)
  Normalize/canonicalize            Encode for URL
  Reject if invalid                 Encode for JSON/XML

Canonicalization

Canonicalization (C14N) converts data to its simplest, standard form before validation. Without canonicalization, attackers bypass validation by using alternate representations of the same value.

Common Bypass Techniques Prevented by Canonicalization

Canonicalization Order

Always canonicalize before validation:

Raw Input → Decode → Normalize → Canonicalize → Validate → Process

If you validate before canonicalizing, an attacker can encode their payload to pass validation and then have it decoded into a malicious form later.

Language Examples

Path Canonicalization

// C# — Resolve to absolute path and verify it's within the allowed directory
string basePath = Path.GetFullPath("/app/uploads");
string requested = Path.GetFullPath(Path.Combine(basePath, userInput));
if (!requested.StartsWith(basePath + Path.DirectorySeparatorChar))
    throw new SecurityException("Path traversal detected");

# Python — Resolve symlinks and relative segments
import os
base = os.path.realpath("/app/uploads")
requested = os.path.realpath(os.path.join(base, user_input))
if not requested.startswith(base + os.sep):
    raise ValueError("Path traversal detected")

Unicode Normalization

import unicodedata

# Normalize to NFC before comparing or validating
clean = unicodedata.normalize("NFC", user_input)

// C# — Normalize to FormC (NFC)
string clean = userInput.Normalize(NormalizationForm.FormC);

URL Canonicalization

from urllib.parse import unquote

def canonicalize_url(url: str) -> str:
    prev = None
    while prev != url:
        prev = url
        url = unquote(url)
    return url

Output Encoding

Output encoding ensures data is safe for the specific context it is being rendered or transmitted into. This applies to ALL outputs, not just HTTP responses.

Context-Specific Encoding

Encoding Data From Internal Sources

Database row → render in HTML?    → HTML-encode the value
Cache value  → insert into SQL?   → use parameterized query
Queue msg    → pass to shell?     → use subprocess array (no shell)
Config value → embed in template? → encode for template context
API response → return to client?  → serialize properly, set Content-Type

The encoding must match the destination context, regardless of where the data came from.

Component Boundary Checklist

For every component boundary (inbound or outbound), verify:

Anti-Patterns

Best Practices

• •Treat all data as untrusted regardless of source — user input, databases, caches, queues, APIs, config, and files all deserve the same scrutiny.
• •Canonicalize before validating — decode, normalize, and resolve data to its simplest form before applying security checks.
• •Encode at the point of use, not at the point of storage — the correct encoding depends on where the data is going, not where it came from.
• •Validate on both sides of every boundary — the producer should validate what it sends and the consumer should validate what it receives.
• •Use allowlists over denylists — it is safer to define what is permitted than to try to enumerate everything that is dangerous.
• •Fail closed — if data fails validation, reject it entirely rather than attempting to "fix" it and proceeding.
• •Apply the same rigor to outbound data — log injection, email header injection, and downstream API injection are just as real as XSS.
• •Automate hygiene checks — use linters, SAST rules (Semgrep, CodeQL), and code review checklists to catch missing validation and encoding at component boundaries.
• •Document trust boundaries — make them explicit in architecture diagrams and threat models so every developer knows where hygiene enforcement is required.
• •Review ORM and framework escape hatches — dangerouslySetInnerHTML, raw SQL, HtmlString, @Html.Raw(), mark_safe(), and similar constructs bypass built-in protections and require manual encoding.