Secure by default
Ship with the locked-down setting on, so anything riskier takes a deliberate act to enable. Private first, public on purpose.
See it
What it is
Secure by default means the out-of-the-box setting is the safe one, and anything riskier takes a deliberate act to switch on. New buckets start private. New database tables deny reads until a policy allows them. New API keys get the narrowest scope. The unsafe path exists, but you have to walk to it on purpose.
Reach for it whenever you are designing config, a template, a starter repo, or an internal tool other people will clone without reading. The sibling principles are deny by default (allowlist what is permitted, reject everything else) and fail closed (when the auth check errors, block rather than let through). S3's move from public-ish buckets to block-public-access-on is the canonical before and after.
The misconception: people treat it as a one-time hardening pass. It is really a property of every new thing your system creates, forever. If the safe setting is annoying enough, developers will paste the wide-open config from Stack Overflow and it will ship. Make the secure path the easy path, or you have built a checkbox, not a default.
Ask AI for it
Audit this project for secure-by-default configuration and fix what is not. Concretely: make new storage buckets and files private unless explicitly shared; enable row-level security with deny-by-default policies on every table; set CORS to an explicit origin allowlist instead of '*'; require auth on new routes by default and mark public routes explicitly; give new API keys the narrowest scope that works; make auth middleware fail closed on error. Show me a diff plus a short list of every place the old default was permissive.