What it means
Secure defaults make essential protection part of the initial experience. A new account should start with appropriate limits, a private workspace should not unexpectedly become public, and a service should not depend on the administrator discovering a dangerous setting after deployment. The exact settings depend on the product's purpose and operating context.
Defaults influence behavior because many people keep them. Design the ordinary setup path to make safe use straightforward, document the consequences of relaxing a protection, and distinguish a deliberate exception from an accidental exposure. Defaults complement later maintenance; they do not remove the need to apply updates, review access, and monitor changes.
The idea at a glance / Access
Start private. Bound the exception.
A new workspace begins owner-only. One approved document grant changes one permission for a defined window; the other limits remain.
Fictional TeamDocs workspace W42 contains D1 and D2. Owner O7 and collaborator C12 have separate authenticated sessions. TeamDocs supports document-level grants and checks their current validity on every read.
READ THE PICTURE
Read the default and change
Fresh W42 is owner-only: C12’s D1 read is refused. Approved E8 later permits C12 to read D1 during 09:00–10:00 UTC. At 09:30, D1 returns content; D2 is refused. At exactly 10:00, D1 is refused again. Public links stay off.
Keep in mindThis covers sharing defaults in one design. Transport, logging, copied templates, upgrades, and other features need their own checks. Grant expiry cannot recall content already returned to a permitted reader.
Read the complete example
- Read the default and change. Fresh W42 is owner-only: C12’s D1 read is refused. Approved E8 later permits C12 to read D1 during 09:00–10:00 UTC. At 09:30, D1 returns content; D2 is refused. At exactly 10:00, D1 is refused again. Public links stay off. On 25 September 2026, UTC, owner O7 creates workspace W42 through the ordinary setup path at 08:50. Its documents D1 and D2 start owner-only and public links are disabled. No special hardening or settings repair is performed after creation. A controlled read of D1 using collaborator C12’s valid session at 08:55 is refused because C12 has no grant. O7 approves exception E8 for a stated collaboration task: C12 may read D1 only from 09:00 inclusive to 10:00 exclusive that day. E8 changes a document grant, not the workspace-wide default, and does not enable public links, editing, bulk export, or access to D2. An approval/configuration record names O7, C12, D1, the read action, and the window. Independent tests at 09:30 return D1 content to C12 but refuse reading D2. At exactly 10:00, a further D1 read is refused, even though C12’s session remains authenticated. The service checks grant validity on every read in this example; a long-lived token that retained the earlier authority would require a different expiry design and testing. Expiry prevents later access under E8 but does not erase a copy already delivered at 09:30. These results establish this chosen sharing default and bounded change, not the safety of every other setting or creation path. Fresh accounts, templates, copied resources, and upgrades all need representative checks.
This covers sharing defaults in one design. Transport, logging, copied templates, upgrades, and other features need their own checks. Grant expiry cannot recall content already returned to a permitted reader.
Diagram references: NIST SP 800-53 Rev. 5 - CM-6 restrictive configuration and approved deviations · OWASP Authorization Cheat Sheet
AN ILLUSTRATIVE SCENARIO
An education file-sharing service
A school introduces a service for sharing staff documents. New folders are restricted to their owner until another staff member is explicitly added. Public links require a deliberate action with a clear explanation of who can use them. The technology team also checks whether copied folders and newly created classes receive the same intended defaults. An initial setup test with a fresh account reveals an invitation flow that had inherited broad access from an old template.
Put it to work
- List the security-relevant choices made during first use, account creation, and new-resource creation; identify where an unchanged default could expose data or authority.
- Set a restrictive but workable baseline, remove unnecessary capabilities, and make any relaxation intentional, understandable, and accountable.
- Test a clean installation or fresh account as a new user would, then verify that upgrades and templates preserve the intended protections.
How to check your work
Create a fresh test account and resource without special hardening. Confirm that unauthorized access fails, required protections are active, and any permitted relaxation leaves an understandable record of the choice.
Connect the ideas
- Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
- Control
A process, configuration, or technology meant to reduce a named risk or detect a named failure.
- Exposure
Whether and how a vulnerability or service can actually be reached in this environment.