Rule 11 of 38 · Chapter II — Design for Change
Make the default path the safe path
Why this rule exists
People follow the path of least resistance, and so does code written in a hurry. If the easiest way to call an API is also the unsafe way, unsafe usage is what you will get, spread across the codebase and impossible to police by review. Making the default path the safe path means correctness is what happens when someone does the obvious thing.
In practice
Design APIs so the simplest call is the correct one: secure by default, validated by default, closed by default. Make the dangerous option require an explicit, visible opt-in that is easy to spot in review. If safety currently depends on remembering an extra step, invert it so forgetting yields the safe behavior, not the risky one.
Example
// escaping is opt-in;
// forget it and you ship XSS
render(userInput);
render(userInput, { escape: true });// escapes unless you opt out
render(userInput);
render(trustedHtml, { raw: true });When it doesn't apply
Defaults tuned for safety sometimes conflict with defaults tuned for raw performance; in a controlled, expert-only context the trade may tip the other way. Even then, make the unsafe choice loud and deliberate rather than silent.