Security and Trust Boundaries

Overview

Common security mistakes grouped by trust boundary: input concatenated into a query, a token logged "for debugging", an unguarded endpoint, pickle.loads on untrusted bytes. When code crosses a trust boundary, stop and run the matching checks before you commit.

This is a rigid skill. Jump to the sub-section that matches what you're writing and run that sub-section's checks.

These checks matter most when untrusted input is crossing into a system with real users — production endpoint, shared service, anything that touches user data, secrets, or auth state. In MVPs, prototypes, internal dev tools, and one-off scripts, prefer the simplest thing that works and re-invoke this skill before the code reaches users. Three rules apply at every stage, even prototypes: no committed credentials in source, no string-built SQL or shell commands, no pickle.loads (or equivalent) on untrusted input. Surface these in your summary to the user even in throwaway code.

The rules below describe properties of code that crosses a trust boundary, whether you authored that code or encountered it in a file you are touching. When you find an issue in pre-existing code adjacent to your edit, surface it in your summary to the user — don't silently rewrite the file outside the scope you were asked to change.

When to invoke

Invoke when you're about to: