423.2 Security design patterns

Apply proven architectural principles to minimise risk and ensure secure behaviour by default.

Overview

Security design patterns are reusable principles that help developers build systems that are safe by design. Rather than reacting to vulnerabilities after they occur, these patterns help eliminate whole categories of risk by shaping how systems are structured.

This topic introduces three foundational design principles: least privilege, secure defaults, and simplicity and modularity. Together, they help developers write software that is more predictable, resilient, and harder to exploit.

Targets

In this topic, students learn to:

• Describe the role of design patterns in secure software development

• Apply the principle of least privilege in access control and permissions

• Design systems that are secure by default, not secure only when configured carefully

• Reduce complexity and limit interdependence to make software easier to secure

Syllabus references

Secure software architecture

Developing secure code

• Explore fundamental software design security concepts when developing programming code, including: – confidentiality – integrity – availability – authentication – authorisation – accountability

• Apply security features incorporated into software, including data protection, security, privacy and regulatory compliance

Least privilege

Definition: Give users, programs, and processes only the permissions they need, and no more.

Why it matters:

• Reduces damage if an account or process is compromised

• Prevents accidental changes to sensitive systems

• Supports layered security and accountability

Examples:

• A web app with admin and user roles should prevent regular users from accessing admin features

• A script that reads logs shouldn’t have write access to the filesystem

Implementation tips:

• Use role-based access control (RBAC)

• Separate permissions for read, write, and execute

• Use "default deny" where access must be granted explicitly

Secure defaults

Definition: Software should be secure out of the box. If users or developers forget to configure something, it should fail safely.

Why it matters:

• Misconfiguration is one of the most common causes of breaches

• Many users and teams don’t change defaults

Examples:

• A database that requires authentication by default

• An API that rate-limits anonymous users unless configured otherwise

• A server that disables directory listing unless explicitly enabled

Implementation tips:

• Set restrictive default permissions

• Require passwords or API keys by default

• Disable debug modes in production

Simplicity and modularity

Definition: Systems should be broken into simple, independent components that each do one job well.

Why it matters:

• Complex systems are harder to audit and test

• Modularity makes it easier to replace or patch insecure parts

• Smaller codebases are easier to secure

Examples:

• A microservice that only handles authentication, separate from the main app

• A function that validates input but does not handle database access

• Code that avoids nested conditionals or large functions

Implementation tips:

• Break up large functions and classes

• Use clear naming and structure

• Minimise dependencies between components

Summary

• Least privilege limits what users and processes can do, reducing damage from breaches

• Secure defaults ensure the system is safe even when misconfigured

• Simplicity and modularity make systems easier to secure, maintain, and test

• These patterns form the foundation of secure software design