craft-security

Security Craft

This skill encodes one engineer's standard for defensive security, applied the same way across every repo. The method and opinions live here; the project specifics (which auth provider, which secret store, which validation library) live in the target repo's code and config — always discover them, never assume or hardcode.

Operating principle — discover before you build

Different repos already have different pieces in place. Before changing anything, spend a few minutes mapping the current posture so you extend rather than conflict:

• package.json / lockfile → which auth library, validation library, and HTTP framework are present?
• grep for an existing env schema (env.ts, config.ts) — are secrets loaded through a validated schema or read raw from process.env?
• Check for an existing middleware file or proxy entry point — are security headers already set, and where?
• Scan package.json for known-vulnerable pinning patterns; note whether a dependency scanner (npm audit, Snyk, Dependabot) is wired into CI.
• Look at existing route handlers — is authorization checked once in middleware, per-route, or not at all?

State what you found, then propose the smallest set of changes that closes the gaps.

The security layers (work in this order)

1. Authorization & auth-flow security — enforce least-privilege on every resource (a valid session does not mean access to everything), and apply the security standard for the authentication flow (JWT verification criteria: pin the algorithm, reject alg:none, check exp/iss/aud). The authN implementation — verifying the session/token and resolving the principal/tenant in the request lifecycle — is owned by craft-backend → auth.md; this layer owns the criteria that verification must meet and the authZ policy on top. See references/authz.md.
2. Input & output — validate all input at the boundary, encode all output for its target context, parameterize all queries. Never trust data that crossed a trust boundary. See references/input-output.md.
3. Secrets — credentials, tokens, and keys belong in a validated env schema or secret store, not in source code, logs, or error messages. See references/secrets.md.
4. Transport & headers — TLS is table stakes; security headers (CSP, HSTS, X-Frame-Options, etc.) and a strict CORS policy narrow the attack surface further. See references/headers-cors.md.
5. Supply chain — pinned, scanned dependencies with critical vulnerabilities blocking CI. Every package you import is code you're responsible for. See references/supply-chain.md.
6. Data rights — a user-data deletion path exists and cascades, third-party processors get their own deletion call, an export path exists, and PII is inventoried rather than leaking into logs or error trackers. Engineering-observable only — not legal advice. See references/data-rights.md.