Fable security

Fable Security

If fable-core is loaded: security-relevant work is Consequential in Phase 0 triage — no arguing it down — and this skill supplies the Phase 2/4 craft and the Phase 5 rubric and catalog. If fable-core is absent, run its mini-loop: threat model → produce → self-review with an 8-defect quota → verify by attacking your own change → deliver with calibrated language.

Scope: this skill is defensive. It governs securing systems, fixing vulnerabilities, and reviewing code — not building offensive tooling.

Prime directive

Three assumptions dominate everything else. Every rule below serves one of them:

• All input is hostile until validated at a trust boundary — including input from your own database, your own services, and files users uploaded years ago.
• Fail closed. When a security control errors, the answer is "no". Availability degradation is an incident; silent authorization bypass is a breach.
• Fix the class, not the instance. A reported vulnerability is one member of a family. Patching the reported member and shipping is how the same CVE recurs.

Before any change: the threat model

Ten minutes, written down, before touching security-sensitive code:

• Assets — what an attacker would want here (data, money, access, compute).
• Trust boundaries — where data crosses from less-trusted to more-trusted context. Every boundary crossing is a validation point; validation anywhere else is decoration.
• Entry points — every path to the asset, not just the one in the ticket. The API route has a sibling admin route, a batch job, and a webhook that reach the same table.
• Attacker positions — anonymous, authenticated-as-someone-else, insider, and "attacker who already got one foot in" (defense in depth exists for the last one).

Writing security-sensitive code

1. Authorize at the object, not the route. Route-level checks answer "may this role use this endpoint"; the actual question is "may this user touch this specific record". Check ownership/tenancy where the data is fetched, and the check belongs in one place (the data layer or a policy module), not copy-pasted per handler.
2. Validate with allowlists at the boundary, encode at the sink. Input validation states what is permitted; blocklists enumerate yesterday's attacks. Escaping happens where data meets an interpreter — HTML encoding at render, parameters at the query, argument arrays at the shell — never "sanitized" speculatively in the middle.
3. Parametrize, never concatenate. SQL, shell, LDAP, XPath: data travels as data. If a query is built from strings, no amount of escaping earns a pass.
4. Use the platform's crypto, at today's settings. Password hashing is argon2/bcrypt/ scrypt via a maintained library; tokens come from a CSPRNG; comparison of secrets is constant-time. Composing your own construction from primitives counts as rolling your own.
5. Secrets never touch code, logs, or error messages. They live in the secret store / environment, are rotated when exposed, and anything that once reached a git commit or a log aggregator is compromised, period — deletion is cleanup, rotation is the fix.
6. Errors are honest inward, opaque outward. Log the mechanism with full detail for operators; tell the user something that doesn't teach an attacker (no "user exists but password wrong", no stack traces, no query fragments).
7. Deny by default. New routes require auth unless explicitly public; new permissions start empty; feature flags for security controls default on.

Fixing a reported vulnerability

The procedure, in order, no skipping:

1. Reproduce it. A vulnerability you cannot exercise is a rumor — build the failing request/input first, exactly as an attacker would send it.
2. Name the class. XSS via innerHTML, IDOR via unscoped query, injection via string concatenation. The class tells you where the siblings live.
3. Fix at the choke point. The correction goes where all instances of the class flow through — the render helper, the query builder, the policy layer — not at the one reported call site.
4. Sweep for the family. Grep for the pattern; check the same author's other endpoints, the same era of the codebase. Report every sibling found, fixed or not.
5. Assess the exposure window. How long was this live, what would exploitation look like in the logs, is there evidence either way? Say what you checked and what you couldn't. "No evidence of exploitation" without having looked is a lie by omission.
6. Prove the fix. The original attack input now fails, and a legitimate request still succeeds — both shown, not claimed.

Reviewing for security

Trace taint: for each entry point, follow attacker-controlled data to every sink it reaches, and name the boundary where it was validated — or report that no such boundary exists. Then walk the checklist: authz on every data access (not just routes), secrets in the diff, error paths of every security control (do they fail closed?), new dependencies (maintained? typosquat? what do they pull in?). Report findings as attack narratives: this actor, sending this, reaches this — consequence. Ordered by severity, no vibes.

Leaked-secret / incident response

Order matters more than speed of any single step: rotate first (the secret is compromised the moment it left), then contain (purge history, invalidate caches/CI logs), then look backwards (was it used?), then prevent recurrence (secret scanning, pre-commit hooks). A history rewrite without rotation is theater — clones and mirrors already exist.

The rubric

Score every dimension 0–2 before delivering (the Gauntlet's grading table). Any 0 blocks delivery. Every 1 is declared debt.

1. Boundary map — trust boundaries named, validation placed on them. Test: for each attacker-controlled input in the diff, name the line where it stops being trusted.
2. Authz completeness — every path to the asset checks, at object granularity. Test: list the entry points to the touched data; recite each one's check.
3. Class coverage — the fix lands at the choke point; siblings swept. Test: name the vulnerability class and where else it was searched for.
4. Fail-closed — every security control's error path denies. Test: for each catch/fallback around auth, validation, or crypto: what does it return on failure?
5. Secret hygiene — nothing sensitive in code, logs, errors, or fixtures; exposed secrets rotated, not just deleted.
6. Crypto soundness — platform primitives, current parameters, constant-time where comparison is secret. Test: name the library and setting for each crypto operation.
7. Proof of fix — the attack input demonstrated failing, the legitimate path demonstrated passing. Test: show both executions.
8. Disclosure honesty — exposure window assessed, siblings and residual risk reported, uncertainty stated as uncertainty.

Anti-pattern catalog

Check these by name during the Gauntlet. Format: name — the tell → the correction.

1. Instance-patching — fixing the one reported XSS/IDOR/injection call site → fix the choke point the whole class flows through; sweep for siblings.
2. Blocklist thinking — filtering <script>, banning quotes, stripping ../ → allowlist what is valid; encode at the sink.
3. Client-side enforcement — hidden button, disabled field, JS validation as the control → the server check is the control; the client copy is UX.
4. Fail-open — auth/validation wrapped in try/catch that continues on error → fail closed; alert loudly; degrade availability, never authorization.
5. Authn/authz confusion — "the user is logged in" treated as "the user may do this" → object-level ownership/tenancy check at data access.
6. String-built commands — SQL/shell/LDAP assembled by concatenation, "but escaped" → parameters, prepared statements, argument arrays. Escaping is not a pass.
7. Home-rolled crypto — custom token schemes, fast hashes for passwords, DIY constructions from primitives → platform library, current parameters.
8. Secret theater — leaked key deleted from HEAD, .env added to .gitignore after the fact, rotation skipped → rotate first; the secret is already copied.
9. Security by obscurity — unguessable URLs, hidden endpoints, "internal only" as the control → obscurity may supplement a control; it is never the control.
10. Noisy errors — stack traces, SQL fragments, "email not found" to the client → detail inward to logs, opacity outward to users.
11. Sanitization slop — escaping/stripping applied speculatively everywhere, data mangled in storage → validate at the boundary once, encode at each sink for that sink.
12. TOCTOU — check and use as separate steps on shared state (file, balance, role) → make check-and-act atomic: transactions, locks, compare-and-swap.
13. Trusted-internal fallacy — no validation because the caller is "our own service" → internal surfaces are one SSRF or one compromised box away from external.
14. Logging the payload — tokens, passwords, PII written to logs "for debugging" → log identifiers and shapes, never credentials or raw sensitive fields.

Exemplars

Read references/exemplars-security.md to calibrate what fable-grade security work looks like — recommended before fixing any reported vulnerability, and whenever your Gauntlet keeps coming back suspiciously clean.