Secure by Default
Software should ship with its most secure configuration already switched on, so people are protected without having to do anything.
Also known as: Secure Defaults, Security by Default, Safe Defaults
Category: Software Development
Tags: security, cybersecurity, software-design, software-development, defaults, principles, best-practices
Explanation
Ask yourself: how many default settings did you change in the last app you installed? Probably none. And you're far from alone. Research on the default effect shows that most people never touch defaults.
In security, that has a direct consequence. The default configuration IS the configuration of most deployments. If the default is insecure, most installations are insecure, no matter how good the security options buried in the settings are.
Secure by Default is the principle that the default setup of a product, system or library should be the most secure reasonable one. Users shouldn't need security expertise, extra configuration or a careful read of the docs to be protected. Weakening security should require an explicit, informed decision to opt out.
**Core practices**:
- **Deny by default**: Block access unless it's explicitly allowed (firewalls, permissions, CORS)
- **Least privilege by default**: Grant the minimum permissions needed, nothing more
- **No default credentials**: Force a unique password or key at setup. `admin/admin` should never ship
- **Encryption on by default**: TLS, encrypted storage and secure cookies, with no opt-in required
- **A small attack surface**: Disable unused services, ports, debug endpoints and features
- **Safe APIs by default**: Auto-escaping templates, parameterized queries, memory-safe languages
- **Automatic security updates** wherever that's feasible
- **A visible opt-out**: Weakening security should be deliberate, logged and clearly labeled
**Secure by Default vs. Secure by Design**:
The two often go together. Secure by Design means building security into the architecture from day one, instead of bolting it on later. Secure by Default makes sure that what ships is actually configured safely. Agencies such as CISA push both, to move the burden of security from end users to the companies that build the products.
**The tradeoff**:
Secure defaults can add friction: an extra setup step, a blocked feature that would have been convenient. Add too much, and people disable the protection entirely (the classic "just turn off the firewall" move). Good secure-by-default design keeps that friction as low as possible, so the secure path is also the easy one.
That's the Pit of Success applied to security. When the system is safe without effort, most people end up secure simply by leaving the defaults alone.
Related Concepts
← Back to all concepts