A secure default means a user who changes nothing ends up in a safe state. Check every new feature for what it exposes, who can use it, what it logs and how it fails, then set each to the safe choice. Make the unsafe option require a deliberate, visible action.
The principle
OWASP's secure product design cheat sheet starts with establishing secure defaults and minimizing attack surface. It says configuration should make systems secure out of the box, so little manual setup is needed to reach a safe state. Most people never change defaults, so the default is the product for most users.
The checklist
Access
- New roles and API keys start with the least access they need. OWASP describes least privilege as giving users only the access their work requires.
- New users are not administrators.
- Sharing links and public visibility are off until someone turns them on.
- Components run with only the rights their function needs.
Exposure
- New endpoints require authentication unless there is a stated reason.
- New features are disabled until enabled, or hidden behind a flag.
- Debug modes, sample data and test accounts are off in production builds.
- Ports and services you do not need are closed.
Secrets
- No hardcoded passwords or keys. OWASP says to store them in dedicated secure storage.
- No shared default credentials. Force setting a unique one at first use.
- Generated tokens expire.
Data and transport
- Encrypted connections only, with no option to downgrade.
- Collect and retain the minimum, with a retention default that deletes.
- Exports are limited, logged and permission checked.
Logging and errors
- Security relevant events are logged by default.
- Logs exclude secrets and sensitive fields.
- Errors shown to users give little away. OWASP says errors should be logged securely without revealing sensitive details to attackers.
Updates
- Dependencies and base images are kept current. OWASP lists patching software and base images among its related practices.
Handling the unsafe option
Sometimes users need the less safe setting. Allow it, but:
- Make it explicit, with a plain warning in the interface or config.
- Log the change.
- Do not bundle it with unrelated settings.
- Consider an expiry, so the exception does not become permanent.
Defaults for developers, too
Your repository, pipeline and tooling have defaults as well. Protected main branch, required checks, least privilege tokens for CI and no long lived credentials in the repo are all defaults you can set for every new project through a template.
Do not confuse defaults with a guarantee
A safe default reduces exposure. It does not replace review, testing or monitoring. And if a safe default makes the product unusable, people will switch it off in ways you did not plan for, so test the first run experience.
Safeguard policies, gates and guardrails let you set safe defaults across repositories and have them enforced, and asset discovery shows what actually exists. The free scan is at gold.safeguard.sh/scan.
Quick check
What is the single most useful default?
Least privilege for new accounts, keys and components. It limits the damage of nearly every other mistake.
Should users be able to turn secure defaults off?
Where there is a real need, yes, but explicitly, with a warning and a log entry, not by quietly hiding the setting.
Sources
Last reviewed: 19 October 2026.
