Security by Design Vocabulary

Security issues found in the design phase cost 100x less to fix than issues found in production — threat modeling is the highest-leverage point in the secure software development lifecycle.

The classic threat modeling frameworks — STRIDE (Microsoft), PASTA, LINDDUN — are designed to be applied to architecture diagrams and data flow diagrams before implementation begins. STRIDE asks: could an attacker Spoof identity? Tamper with data? Repudiate actions? cause Information disclosure? Denial of service? Elevation of privilege? Each threat category maps to a class of controls. When the system is still on the whiteboard, the team can choose architectures that minimise the attack surface from the start — rather than bolting on security controls to an architecture that was designed without considering them.

Key vocabulary:
• threat modeling — a structured analysis of a system's architecture to identify security threats and define mitigations
• STRIDE — a Microsoft threat classification framework: Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege
• attack surface — the total area of a system that an attacker can attempt to exploit

When security requirements are treated as first-class, security work becomes part of the normal delivery process — it gets estimated, tracked, and done. When it's treated as a separate checklist, it gets deferred and skipped under delivery pressure.

The practical difference: a first-class security requirement appears as an acceptance criterion on a user story ("Given a user login attempt, when the password is incorrect, then the error message must not reveal whether the username exists"). It is tested before the story is accepted. It blocks release if not met. A secondary-class security requirement is in a separate compliance document that gets reviewed quarterly — and gets found violated in production. The shift to first-class treatment requires PM buy-in (security requirements have delivery cost and must be prioritised), engineering buy-in (security is part of "done"), and definition of done updates.

Key vocabulary:
• first-class requirement — a requirement with full standing in the development process: backlog, estimation, sprint, and acceptance testing
• security acceptance criteria — specific, testable security conditions that must be satisfied before a story is accepted as done
• definition of done — the team's agreed checklist of conditions (including security) that every story must meet before it can be released

A security architecture review is a risk-focused analysis of the system's design — not a code review, not a pentest — that examines structural security properties before the system is built or deployed.

Key examination areas in a security architecture review: (1) Data flow diagrams — what data moves where, and is it protected in transit? (2) Trust boundaries — every crossing of a trust boundary (internet → DMZ, DMZ → internal, service → database) requires authentication and authorisation controls; (3) Authentication — is the identity of every caller validated? (4) Authorisation — is what each caller is permitted to do enforced at the right level? (5) Secrets — are credentials, API keys, and certificates stored in a secrets manager, not in config files or environment variables in source control? (6) Logging — are security-relevant events (auth failures, access to sensitive data) logged with enough context for incident response?

Key vocabulary:
• security architecture review — a structured analysis of a system's design to identify security risks before or during implementation
• trust boundary — a line in an architecture where different levels of trust meet, requiring authentication and authorisation controls
• secrets management — the practice of storing credentials and sensitive configuration in a dedicated vault rather than in source code or config files

Privacy by default shifts the default toward privacy — users get the most protective settings automatically, rather than having to navigate settings menus to protect themselves after the fact.

Article 25 of GDPR requires both "data protection by design" (privacy built into the system architecture) and "data protection by default" (privacy-protective settings as the default). In practice, privacy by default means: a new user's profile is private, not public; activity data is not shared with third parties unless the user explicitly enables it; location data is not collected unless needed for a specific feature the user activates; marketing emails are opt-in, not opt-out. The key principle: the service processes only the data necessary for the specific purpose at the time of collection, with the most restrictive settings as the default. This is both a legal requirement and a user trust strategy.

Key vocabulary:
• privacy by default — the most privacy-protective settings are applied automatically; users actively choose to reduce privacy, not to protect it
• data minimisation — collecting only the data strictly necessary for a specific, stated purpose
• opt-in vs. opt-out — opt-in requires active consent before data is collected; opt-out requires action to stop collection that has already started

Least privilege is a blast-radius control — by limiting what each component can access, you ensure that a compromised service can only damage the data and systems it legitimately needed to reach, not everything in the organisation.

"Baked into the design" means least privilege is established as an architectural principle, not an afterthought. Practical implementation: (1) Each microservice has its own database user with only the permissions it needs (no shared superuser accounts); (2) IAM roles follow task-specific scoping (a Lambda that reads from S3 does not also have write permissions); (3) Service-to-service authentication uses short-lived tokens or mTLS rather than long-lived shared credentials; (4) Admin access requires separate, time-limited privileged sessions, not permanent elevated accounts. The design document specifies these constraints explicitly so they survive team turnover and are enforced in code reviews and security reviews.

Key vocabulary:
• principle of least privilege (PoLP) — each entity is granted only the minimum permissions necessary for its specific function
• blast radius — the extent of damage an attacker can cause if a specific component or account is compromised
• IAM role — an identity and access management construct that assigns specific permissions to a service or user

JWT stands for JSON Web Token. It's a compact, self-contained way to securely transmit information about a user between a client and a server. Using JWTs in this scenario means the API will verify the identity of the requesting application before granting access – it's a key component of modern API security.

Rate limiting is a security control that restricts the number of requests a client (like a user or application) can make to a server within a defined period. In this case, it's implemented to mitigate brute-force attacks on the signup endpoint, preventing attackers from overwhelming the system with repeated login attempts.

A delegated access token allows the application to interact with the external payment gateway on behalf of the user without sharing its own credentials. This significantly reduces the risk associated with storing or exposing the application's private key and improves security overall – it's a core principle of OAuth 2.0.

Input validation is a crucial security measure that involves checking and sanitizing all user-provided data to prevent attacks like Cross-Site Scripting (XSS) and SQL Injection. By validating input, developers can ensure that only expected characters or values are allowed, mitigating the risk of attackers injecting malicious code.

The principle of least privilege dictates that each database object (table, view, etc.) should only be granted the minimum necessary permissions to perform its intended function. This significantly reduces the potential damage if an attacker gains access to a compromised table – limiting the scope of their actions.