Security principles for architects

Security as a quality of the structure

Chapter 2 introduced security as a quality attribute: the system's ability to protect data and functions from unauthorised use while serving those who are authorised, expressed through testable security scenarios that name an attacker, an attack, a target and a measurable response. This chapter takes the next step and asks how architecture produces that quality. The answer is that most security properties are decided by structure: which components exist, which of them trust which others, where data is stored and copied, and through which few points every request must pass.

Consider how real breaches happen. An attacker changes the order number in a URL and sees another customer's address, because the service checked that the user was logged in but not that the order was theirs. A storage bucket holding database exports is readable from the internet because a default was changed years ago. An internal reporting service accepts any request from inside the network, so one compromised laptop reaches every customer record. None of these needs clever cryptography to exploit; each is a design decision about trust that nobody made explicitly. Security by design means making those decisions deliberately, early and in writing, and then making them hard to violate by accident.

Security architecture therefore sits alongside the other cross-cutting concerns of arc42's section 8: an identity model, an authorisation model, a data protection concept and a logging concept that every team follows. The rest of this section sets out the vocabulary and principles on which the remaining sections of the chapter build.

Confidentiality, integrity and availability in a real system

The CIA triad is the starting point. On the food-delivery platform, confidentiality covers customers' names, addresses, phone numbers and order histories, couriers' live locations and identity documents, restaurants' payout bank details and the platform's own secrets. Integrity covers prices, basket totals, refunds, courier payouts and the menu a customer sees: an attacker who can change the price of a meal to zero, or redirect a restaurant's payouts to their own bank account, has not read anything secret but has done serious harm. Availability matters most during the evening peak, when a denial-of-service attack or a ransomware infection costs revenue by the minute.

ISO/IEC 25010:2023 adds authenticity (identities can be proved), accountability (actions can be traced to whoever performed them), non-repudiation (actions can be proved to have happened) and resistance (the product keeps working as intended under attack). Architects should name which properties matter for each asset, because they pull in different directions. Failing closed protects confidentiality and integrity but costs availability: if the authorisation service is down, a fail-closed ordering service refuses orders. Failing open preserves availability and gambles with everything else. The right choice differs per operation: viewing a public menu can fail open to a cached copy, while issuing a refund must fail closed.

Saltzer and Schroeder's design principles

In 1975 Jerome Saltzer and Michael Schroeder, drawing on their experience with the Multics operating system at MIT, published eight design principles for protection mechanisms in The Protection of Information in Computer Systems. Half a century later they remain the most cited foundation of secure design, because they are about structure rather than technology. The table restates each one and gives a modern example from the food-delivery platform.

Defence in depth

Defence in depth means layering several independent controls, so that the failure or bypass of one does not expose the asset. The idea comes from military fortification and is standard practice in safety engineering as well as security. Its value depends entirely on the word independent: two layers that fail for the same reason, such as two services that both trust a forged header, are one layer drawn twice.

The diagram shows the layers on the food-delivery platform's order path. If the gateway's token validation has a bug, the ordering service's object-level check still prevents one customer reading another's order. If an attacker steals the database's disk snapshots, encryption at rest with keys held elsewhere protects them. If all of that fails, monitoring should notice the unusual pattern of requests and someone should respond. Defence in depth is also the honest answer to the question "what if this control fails?", which every threat model asks.

Secure by default and secure by design

A product is secure by default when its out-of-the-box configuration is the safe one, so that weakening protection requires a deliberate act. Many large breaches came from insecure defaults left in place: databases listening on the internet without a password, administrator consoles with factory credentials, storage buckets that could be made public with one setting. Vendors have moved: since April 2023, for example, new Amazon S3 buckets are created with Block Public Access switched on and access control lists disabled. In 2023 the US Cybersecurity and Infrastructure Security Agency (CISA) and partner agencies from several countries published joint guidance urging manufacturers to make products secure by design and by default, and in 2024 CISA launched a voluntary Secure by Design pledge for software makers.

For architects, secure by default applies to the platform as much as to products. If the shared service template already includes token validation, structured security logging, a non-root container user and a least-privilege database account, every new service starts secure and teams have to opt out explicitly, which is visible in review. This is what some organisations call a paved road: the easiest path is also the secure one.

Closely related is how a system behaves when something goes wrong. The OWASP Top 10:2025 added a category for mishandling exceptional conditions, which includes failing open: an error in a permission check that is caught and ignored, a timeout that defaults to "allowed", a parsing failure that skips validation. Fail-safe defaults, applied in code, mean that every exception path in a security decision ends in denial.

Attack surface and trust boundaries

The attack surface is everything an attacker can reach and influence: public endpoints and their parameters, open ports, file uploads, message queues that accept input from partners, webhooks, administrator consoles, mobile apps that can be decompiled, and the third-party code and people the system trusts. Michael Howard at Microsoft popularised the idea of measuring it in the early 2000s; the practical rule is to make it as small as possible and to know exactly what is on it. Removing an unused endpoint, closing an administrator port to the internet, or turning off a feature nobody uses reduces risk more cheaply than any added control. Every architectural style choice in Chapter 6 has a security cost here: each new network-reachable service adds endpoints, credentials and traffic to protect.

A trust boundary is where data or control passes between parts with different levels of trust or privilege. The most obvious is between the internet and the platform, but there are many more: between the customer app and the API, between a restaurant's tablet and the menu service, between services owned by different teams, between the platform and a payment provider, between application code and the database, and between ordinary users and administrators. Trust boundaries matter because they are where checks belong: authentication, authorisation, input validation and output encoding happen when data crosses a boundary, never on the assumption that the other side has already done it. Drawing the trust boundaries on a data-flow diagram is the first step of threat modelling.

The OWASP Top 10 as an awareness list

The OWASP Top 10 is the Open Worldwide Application Security Project's ranked list of the most critical web application security risks, compiled from contributed vulnerability data and a community survey. The current edition, the OWASP Top 10:2025, is the eighth. Compared with the 2021 edition, broken access control stays first and now includes server-side request forgery, security misconfiguration rises to second, the old vulnerable and outdated components category widens into software supply chain failures, and a new category covers mishandling of exceptional conditions.

Treat the list as what OWASP says it is: an awareness document, not a standard. It is useful for training, for checking that a threat model has not missed a whole class of problem and for talking to stakeholders. It is not a complete set of requirements, and "we are OWASP Top 10 compliant" means little. For verifiable requirements, OWASP's Application Security Verification Standard (ASVS) lists testable controls at three levels of rigour, and the separate OWASP API Security Top 10 covers risks specific to APIs, such as broken object-level authorisation.

A secure development lifecycle and shifting left

A secure development lifecycle builds security activities into every stage of delivery rather than relying on a test just before release. Microsoft made its Security Development Lifecycle mandatory in 2004, after Bill Gates's 2002 Trustworthy Computing memo, and the idea spread across the industry. The current reference is NIST's Secure Software Development Framework (SSDF), SP 800-218, version 1.1 of which was published in February 2022; NIST released a draft revision (version 1.2) for comment in December 2025, which had not been finalised at the time of writing. The SSDF groups practices into four families: prepare the organisation (roles, training, toolchains, security requirements), protect the software (protect code and build integrity, keep provenance), produce well-secured software (design to meet security requirements, threat-model, review and test, configure securely by default) and respond to vulnerabilities (identify, fix, and analyse root causes so the same class does not recur). It describes outcomes rather than prescribing tools, which makes it a good checklist for an architect assessing a delivery process.

To shift left is to move security work earlier: security requirements and abuse cases with the user stories, threat modelling in design, static analysis and secret scanning on every commit, dependency checks in the pipeline. The economic argument is familiar from Chapter 1: a missing authorisation check found in a design review costs an hour; the same flaw found after a breach costs a notification to regulators. Practitioners disagree about how far to push it. Advocates say developers who understand security write fewer vulnerabilities. Critics point out that simply moving security tools in front of developers floods them with low-quality findings and turns security into everyone's part-time job and nobody's expertise; they argue for secure defaults built into the platform (the paved road), so that the secure path needs no extra effort, and for security specialists embedded where the risk is highest. Most mature organisations do both, and also keep testing and monitoring in production, which is why some now speak of shifting security everywhere.

What architects own and what developers own

Security work is shared, and confusion about who owns what is itself a vulnerability. The architect owns decisions that cross team boundaries and are expensive to change; teams own their correct application. A common pattern is a small central security team that sets standards and runs the platform's security services, security champions in each product team who lead threat modelling and reviews, and architects who make sure the structural decisions are made and recorded.