Secure Defaults
Secure defaults make the safe configuration the automatic one, so users who never touch a setting still get encryption, least privilege, and closed access.
Definition
Secure defaults are the out-of-the-box settings of a system that favor security over convenience, such as deny-by-default permissions, encryption enabled, and insecure features turned off, so that inaction produces a safe configuration.
Context and scope
Use this principle when designing products, frameworks, cloud templates, and internal platforms, because most users never change a default.
Common misconceptions
- Documentation warnings are enough; users skip docs and keep the default
- Secure defaults remove the need for configuration; they set a safe starting point, not a complete policy
- A default is secure if it is stricter; an unusable default gets disabled entirely
Anti-patterns
- Shipping public storage buckets and relying on users to lock them down
- Enabling debug endpoints, verbose errors, and wildcard CORS in production templates
- Making the secure option require ten extra steps while the insecure one is one flag
Related concepts
Related examples
Authoritative source
https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html
Inaction should be safe
Most configurations are never reviewed. A product’s defaults therefore define the security of its installed base more than any hardening guide. Secure defaults invert the usual burden: the safe path is the path of least resistance, and weakening it requires a deliberate, visible choice.
How it works
Apply deny-by-default to permissions, network exposure, and API access. Encrypt data at rest and in transit without an opt-in. Disable risky features such as debug consoles, directory listing, and install scripts until an operator enables them. Generate strong random secrets instead of placeholders, bind cookies with HttpOnly, Secure, and SameSite, and set conservative timeouts and body limits.
Good defaults are also visible. A generated configuration should state what is on and why, so operators can review rather than guess. When a default changes in a release, treat it as a potentially breaking change and document the migration.
When to use it
Every new product, template, SDK, and internal platform should start here. It matters most for infrastructure-as-code modules, where a single template can create thousands of exposed resources. For mature systems, changing defaults is a migration project, not a patch.
Trade-offs
Secure defaults can break existing workflows and integrations, so upgrades need deprecation paths. Overly strict defaults push users to disable controls wholesale rather than tune them. Some defaults depend on context: a public website and an internal admin tool need different exposure, which is why secure defaults pair with explicit profiles rather than one universal setting.
Example and misconceptions
A cloud template creates a database with a public endpoint and a default password, and the quickstart tells users to change it later. Most do not. A secure template creates a private endpoint, generates a random password into a secret manager, and requires an explicit flag to expose the database.
The common misconception is that defaults are neutral. They encode a policy choice, and when the choice is insecure, the vendor is effectively shipping that insecurity to every customer.
Related concepts: Least Privilege, Attack Surface, and Defense in Depth.