Secure defaults and fail-closed design

What it is

Saltzer and Schroeder's 1975 paper lists eight design principles for protection mechanisms. The second, fail-safe defaults, says to base access decisions on permission rather than exclusion: the default situation is lack of access, and the mechanism identifies the conditions under which access is permitted. Their reasoning is about failure modes: a mistake in a mechanism that grants explicit permission tends to fail by refusing permission, which is noticed quickly, while a mistake in a mechanism that lists what to exclude tends to fail by allowing access, which may go unnoticed in normal use. The OWASP Secure Product Design cheat sheet restates it as "establish secure defaults, minimize the attack surface area, and fail securely to those well-defined and understood defaults", and, among its configuration recommendations, asks for systems that are secure by default and that fail securely rather than exposing vulnerabilities when they malfunction.

Why it matters

Many configuration-related exposures are mundane: a debug endpoint left enabled, storage that was public by default, an authorisation check that treated a missing role as "no restrictions", a policy lookup that timed out and was skipped. Each is a design that fails open. A fail-closed design turns the same mistakes into visible errors: a 403, a refused start-up, a failing test.

How to apply

• Authorisation: start from deny and enumerate what is allowed (roles, routes, origins, hosts); never express policy as a list of forbidden things.
• Configuration: require security-relevant settings explicitly (signing key, allowed hosts, TLS mode) and refuse to start when they are missing or malformed rather than substituting a permissive value. Where a default must exist, ship the production-safe one.
• Error paths: when a dependency the check relies on (session store, policy service, key store) is unavailable, deny and alert; "could not verify" is not "verified".
• Debug switches and feature flags default to off, and are removed rather than left in.
• Inputs: accept what is explicitly allowed (schemas, enumerations) rather than filtering out known-bad patterns.
• Review: for each new check, ask what happens on exception, timeout, null and empty list.

Pitfalls

Fail-closed is the right default for access control, not for every function: a health check that fails closed can take a service down, and a fraud filter that blocks on outage stops all payments. Decide per mechanism which direction is safe and write it down. Secure defaults that make the first run painful get overridden by copied "disable security" snippets; pair them with error messages that say exactly what to set.