Files
atelier/domains/security/input-validation.md
T
Jon Chery 496303471d docs(milestone): complete v0.1 — initial framework
---ci---
project: atelier
phase: 7
milestone: v0.1
status: complete
phase_role: final
milestone_complete: true
requirements:
  covered: [ATELIER-01, ATELIER-02, ATELIER-03, ATELIER-04, ATELIER-05, ATELIER-06, ATELIER-07, ATELIER-08, ATELIER-09, ATELIER-10, ATELIER-11, ATELIER-12, ATELIER-13, ATELIER-14, ATELIER-15, ATELIER-16, ATELIER-17, ATELIER-18, ATELIER-19, ATELIER-20, ATELIER-21, ATELIER-22, ATELIER-23, ATELIER-24, ATELIER-25, ATELIER-26, ATELIER-27, ATELIER-28, ATELIER-29, ATELIER-30, ATELIER-31, ATELIER-32, ATELIER-33, ATELIER-34, ATELIER-35]
  partial: []
ship:
  milestone: v0.1
  type: NFR
  tag: v0.0.7
  merge: milestone/v0.1-atelier -> main
  release: https://git.cloudinit.dev/cloudinit-bot/atelier/releases/tag/v0.0.7
---/ci---

Milestone v0.1 — Initial Framework (NFR, complete).
8 core principles (C1-C8), 11 domains, 110 domain principles, 27 derived docs, 4 good + 3 bad examples, 4 language docs, full matrix, 3 review docs.
All 35 requirements covered. 7 patches (v0.0.0 pre-execution through v0.0.7 final). v0.0.7 IS the v0.1.0 milestone release.
2026-08-05 00:36:55 +00:00

64 lines
2.6 KiB
Markdown

# Input Validation — Derived Rules
> Derives from `domains/security/first-principles.md` P4 (Input Validation), P5 (Output Safety).
## The Rule
All input is untrusted until validated. Validation happens at the boundary, against a schema, with explicit failure modes.
## Validate at the Boundary (P4 Locality)
- The API endpoint, the controller, the message handler — the entry point validates.
- Internal code trusts validated input. Unvalidated input never reaches the database.
- Defense in depth: the database also has constraints (P3 Defense in Depth).
## Schema Validation
- Use a schema library (zod, joi, pydantic, json-schema). Never hand-write validation.
- The schema is the contract. The schema is versioned. The schema is tested.
- Reject unknown fields (`additionalProperties: false` by default). Be explicit.
## Validation Types
### Type Validation
- `id` is a UUID, not a string. `age` is an integer ≥ 0. `email` matches a regex (or better, is parsed).
- Never accept `any`. Never accept `string` for a typed value.
### Range Validation
- `limit` ≤ 100. `page` ≥ 1. `quantity` ≥ 1 and ≤ stock.
- Bounds are explicit. No "unbounded" inputs.
### Format Validation
- `email` is parsed (not just regex). `url` is parsed. `date` is parsed.
- A regex for email is wrong (RFC 5322 is not a regular language). Use a parser.
### Semantic Validation
- `start_date < end_date`. `user_id` exists. `product_id` is in stock.
- Semantic validation may require a database lookup. That's fine.
### Presence Validation
- Required fields are present. Optional fields are absent or null.
- Empty string `""` is not the same as null. Be explicit about which you accept.
## Failure Modes (P8 Fail Securely)
- Validation failure → 400 Bad Request with a structured error (`domains/api/error-responses.md`).
- Never coerce: `"5" + 3` is not validation. Reject, don't guess.
- Never default: a missing required field is an error, not a default value.
## Output Safety (P5 Output Safety)
- Validation is for input. Encoding is for output.
- Output to HTML: HTML-encode. Output to SQL: parameterize. Output to URL: URL-encode.
- Never trust validated input for output. Validate on the way in, encode on the way out.
## What Violates Input Validation
| Violation | Principle |
|-----------|-----------|
| `JSON.parse(req.body)` with no schema | P4 Input Validation |
| `parseInt(req.query.id)` with no range check | P4 |
| `additionalProperties: true` by default | P1 Contract Fidelity |
| Coercing `"5"` to `5` silently | P8 Fail Securely |
| SQL string interpolation (even of "validated" input) | P5 Output Safety |
| Regex for email validation | P4 (use a parser) |