A framework design approach that provides default behaviour so developers write less boilerplate. In security terms, the same defaults can also replicate unsafe patterns across many services when teams enable features without revisiting the access, exposure, or data-handling assumptions behind them.
Why Convention Over Configuration Matters
Convention over configuration is a design choice that trades explicit setup for predictable defaults. It speeds development, reduces boilerplate, and makes common paths easier to use, but the same convenience can hide security assumptions that deserve a deliberate review.
The important security question is not whether defaults exist, but whether those defaults are safe for the environment they are deployed into. A convention is helpful when it matches the organisation’s access model, data sensitivity, and exposure profile; it becomes risky when teams accept inherited settings without checking what they expose.
How Defaults Shape Security Posture
Defaults influence behaviour at scale. When a framework applies a common configuration automatically, that behaviour is repeated across many services, which creates consistency but can also repeat a weakness everywhere it is used. If the default is permissive, externally reachable, or assumes trusted internal use, the resulting exposure can spread quickly.
This is especially important in systems that handle secrets, credentials, API endpoints, or sensitive data flows. A secure-looking convention may still permit broad access, logging gaps, weak transport settings, or data retention choices that are acceptable in a demo but not in production.
Well-chosen conventions reduce configuration drift and make secure baselines easier to maintain. Poorly chosen ones do the opposite, because teams may assume the framework has already made the right security decision for them.
Where Convention Over Configuration Becomes Dangerous
The main danger is silent inheritance. Teams often focus on business logic while default authentication, authorization, CORS, network exposure, or file handling settings remain untouched. That makes the security outcome dependent on the framework author’s assumptions rather than the application’s actual trust boundaries.
Defaults can also be replicated too broadly. In one service, an acceptable shortcut may be harmless; across many services, the same shortcut can create a systemic pattern of overexposure or data leakage. In practice, the risk comes from scale, consistency, and the fact that insecure defaults are easy to ship unchanged.
Another common failure mode is misunderstanding what the convention is optimising for. Many frameworks optimise developer ergonomics, not least privilege, data minimisation, or secure-by-default deployment. Treating convenience as equivalent to assurance is where the hidden risk starts.
Using Framework Conventions Safely
Convention should be treated as a starting point, not a final security decision. The safest teams identify which defaults are acceptable, which require hardening, and which must be overridden before deployment. That review is most important wherever the convention affects exposure, trust boundaries, or sensitive data handling.
It also helps to document when a team is intentionally keeping a default. If the security rationale is not obvious, it should be explicit enough that another practitioner can tell whether the default was chosen deliberately or simply left in place.
Practitioner note: The real control is not “use defaults” or “avoid defaults”, but “know which defaults are safe to inherit”. When convention replaces review, the organisation inherits the framework author’s assumptions whether they fit or not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Convention over configuration relies on secure baselines and controlled defaults. |
| AC-6 — Least Privilege | Default configuration can expand access beyond what the application actually needs. | |
| Recommendation — Establish approved baselines for framework defaults and review deviations before release. Override permissive defaults to ensure each service and role has only necessary access. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | This term is about choosing and governing safe default configurations. |
| Recommendation — Define configuration standards and verify that inherited defaults meet security requirements. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Convention over configuration depends on safe baseline settings across deployed software. |
| Recommendation — Harden application defaults and continuously validate deployed configurations against the standard. | ||
| NIST CSF 2.0 | PR.DS-10 — Data in Transit is Protected | Framework defaults often affect transport and exposure settings for data flows. |
| Recommendation — Confirm framework defaults protect data in transit before relying on them in production. | ||
Related resources from NHI Mgmt Group
- What breaks when backup configuration permissions are over-granted?
- How should security teams structure endpoint configuration management so policies are reusable without losing control over device-specific exceptions?
- How do organisations decide when a visual API workflow editor is the right choice over configuration files?
- When should organisations prioritise no-code onboarding configuration over custom development?