Protect by default
Choose secure defaults
Make a new account, deployment, or feature safe before the user changes any optional security setting.
8 minute lesson
Defaults become reality for most users. A security control hidden behind an optional setting protects fewer people than you think.
Keep new resources private, deny unknown operations, use restrictive permissions, and require an explicit decision before exposure. If compatibility needs a weaker mode, make the tradeoff visible and temporary.
A new project is created public because the visibility field is optional. Most users never revisit the setting, so a quiet default becomes a repeated data leak.
A restrictive default may add one explicit publishing step. That small cost is easier to explain than silently exposing every new project.
Create a project without touching any optional security setting and record its resulting visibility and permissions. Try to access it from a signed-out browser and require a denial before calling the default safe.
Lesson completed