Secure Software Architecture And Design practice questions

Implement OAuth 2.0 scopes on the API gateway.

Why it fails: OAuth 2.0 scopes manage authorization, not transit security.

Use a Hardware Security Module (HSM) to store API keys.

Why it fails: HSM protects keys at rest, not data in transit.

Enable request rate limiting on the gateway.

Why it fails: Rate limiting protects against DoS, not interception.

Configure the web application to run as the database administrator account.

Why it fails: This exposes the entire database to the application process.

Grant the web application service account DBOwner rights on the production database.

Why it fails: This violates least privilege by providing excessive permissions.

Enable integrated Windows authentication for all database connections.

Why it fails: This is an authentication mechanism, not a privilege scoping strategy.

Developing a custom symmetric encryption algorithm for maximum secrecy.

Why it fails: Custom algorithms are rarely secure and prone to error.

Storing the encryption key in the same database table as the data.

Why it fails: This is a major security design failure.

D

Why it fails: Encoding is not security.

Using base64 encoding to 'obscure' the data.

Why it fails: Encoding is not security; it is easily reversible.

Fail-safe defaults.

Why it fails: Ensures systems are secure if they fail, which is not the primary purpose of a WAF.

Complete mediation.

Why it fails: Ensures every access is checked, but WAF is a layer, not a mediation mechanism.

Economy of mechanism.

Why it fails: Focuses on keeping the design simple.

Implementing an allow-list for file uploads.

Why it fails: This addresses file upload security, not CSRF.

Encrypting the HTML source code of the form.

Why it fails: Obfuscation is not a valid CSRF defense.

Using a strong password policy for all users.

Why it fails: Passwords do not prevent CSRF.

Use a hardware security module (HSM) hosted on-premises to generate and store keys, and expose a key management API to the cloud application.

Why it fails: An on-premises HSM provides strong key protection and exclusive control, but exposing a key management API to a cloud-hosted application introduces network latency, availability dependencies, and potential exposure of the API endpoint. It also complicates automatic rotation and audit log integration with the cloud environment. This design does not natively support the required seamless rotation and detailed audit logging without significant custom development.

Use a cloud provider's hold your own key (HYOK) feature, where keys are stored in an external key manager and the cloud provider never has access to the key material.

Why it fails: HYOK keeps keys external, ensuring exclusive control, but it often introduces significant performance overhead and limited functionality because cryptographic operations must call out to the external key manager. It may not support automatic rotation natively, and audit logs may be split between the external manager and the cloud provider, complicating centralized auditing. This design can also reduce availability if the external manager is unreachable.

Use a cloud provider's bring your own key (BYOK) feature, where the organization generates keys externally and imports them into the cloud provider's key management service (KMS).

Why it fails: BYOK allows the organization to generate keys externally, but once imported into the cloud provider's KMS, the provider may have access to the key material in memory during cryptographic operations. This does not guarantee exclusive control, as the provider could potentially access keys. Additionally, rotation may require re-importing keys, and audit logs are controlled by the provider, not fully by the organization.

Implement discretionary access control (DAC) where resource owners set permissions, and enforce authorization checks at the API gateway.

Why it fails: DAC allows users to grant access to others, which can lead to privilege creep and does not enforce least privilege centrally. Enforcing at the API gateway alone is insufficient because the gateway may not have the context to evaluate resource ownership. An attacker could exploit misconfigured permissions or bypass the gateway if internal services are reachable. This design does not reliably prevent horizontal or vertical privilege escalation.

Implement role-based access control (RBAC) with roles assigned based on job functions, and enforce authorization checks at the controller layer of the application.

Why it fails: RBAC with controller-layer checks is a good start, but it does not inherently prevent horizontal privilege escalation if the controller only checks role membership and not resource ownership. An attacker with a valid user session could manipulate resource identifiers to access other users' data if the controller does not verify that the requested resource belongs to the authenticated user. This design lacks the necessary object-level authorization checks.

Implement mandatory access control (MAC) with security labels assigned to users and resources, and enforce access decisions based on label comparisons at the presentation layer.

Why it fails: MAC with label comparisons is highly secure but often too rigid for a dynamic banking application. Enforcing at the presentation layer is insufficient because an attacker could bypass the UI and directly call APIs. MAC also does not easily accommodate the complex, context-dependent access rules needed for online banking, such as allowing a user to access only their own accounts. This design is impractical and does not adequately prevent horizontal escalation.

Using a centralized regex filter to strip HTML tags.

Why it fails: Regex tag-stripping operates on the input before storage, so it cannot neutralise payloads that are reassembled or encoded differently at render time. Output encoding at the point of HTML generation is the actual control. Centralised filtering is tempting because it centralises policy, and it suits sanitising rich-text fields where some markup must survive.

Encrypting all user input before storing it in the database.

Why it fails: Encryption protects data at rest; the browser still renders whatever the application emits, so a stored payload executes on retrieval. Context-aware output encoding is what prevents script execution. Encrypting input is tempting because it sounds like a universal safeguard, and it is genuinely required for sensitive fields such as credentials or personal data.

Implementing a strict allow-list for all input fields.

Why it fails: An allow-list constrains what characters are accepted, but XSS arises when valid input is later emitted into HTML, JavaScript or attribute contexts without encoding. Output encoding is the decisive control. Allow-listing is tempting because it is genuinely the strongest validation pattern for structured fields such as postcodes, dates or enumerated values.

Centralized database user management.

Why it fails: Centralised database user management stores credentials in one repository but does not decouple authentication from each microservice, which still queries the database directly. It is tempting because it consolidates accounts; it would be correct for a single monolithic application sharing one database, not for distributed services.

Service Mesh with mutual TLS enabled.

Why it fails: A service mesh with mTLS encrypts and authenticates service-to-service connections, but authentication of end users remains per-service unless an external authorisation component is added. It is tempting because meshes centralise transport policy; it would be correct for zero-trust service identity, not centralised user authentication.

Sidecar pattern using a local proxy for mTLS.

Why it fails: A sidecar proxy secures service-to-service traffic with mTLS but leaves authentication logic distributed, since each service still validates tokens itself. It is tempting because sidecars do offload transport security; it would be correct for encrypting pod-level communication, not for centralising authentication decisions.

Checking for SQL injection in login forms.

Why it fails: SQL injection targets database query construction in input handling, not session identifier generation, rotation or termination. It offers no insight into session fixation or hijacking. Checking injection belongs in an input-validation review, where untrusted data reaches database queries.

Reviewing the database schema for password hashing algorithms.

Why it fails: Password hashing protects stored credentials at rest, not session identifiers, tokens or fixation flaws. Reviewing the schema reveals nothing about session lifecycle handling. It would be the right focus when assessing credential storage weaknesses, such as weak algorithms or unsalted hashes.

Verifying the presence of a Web Application Firewall (WAF).

Why it fails: A WAF is a compensating perimeter control that filters traffic; it neither creates nor manages session identifiers, so it cannot reveal session lifecycle flaws. Verifying its presence suits defence-in-depth reviews of deployed protections, not design-level analysis of session management mechanisms.

To identify the database engine version.

Why it fails: Database engine version is a technical fingerprint gathered during reconnaissance or vulnerability scanning, not a sensitivity classification output. Classifying data sensitivity would be the goal when scoping which controls, such as encryption strength or access restrictions, apply to each data category.

To automate the backup frequency of the database.

Why it fails: Backup frequency is an operational resilience decision driven by recovery objectives, not by sensitivity classification. Automating backups would be the correct focus when defining RPO/RTO requirements; sensitivity classification instead determines handling, encryption and access rules applied to the data itself.

To determine which data needs to be deleted periodically.

Why it fails: Retention and deletion schedules derive from legal, regulatory and business retention requirements, not from sensitivity labels alone. Determining deletion periods would be the goal during a data retention review; sensitivity classification instead informs how data must be protected while it is stored and processed.

Storing secret keys as environment variables in the container spec.

Why it fails: Environment variables are readable by any process in the container and often leak into logs or crash dumps, so compromise exposes the keys. This is tempting for simplicity, and would be correct only where a dedicated secrets manager with short-lived, dynamically injected credentials is unavailable.

Running the application process as the root user.

Why it fails: Root inside the container allows a breakout to escalate to host-level privileges, magnifying the compromise's impact. Running as root is tempting because it avoids permission errors during image builds, and would be correct only in throwaway build stages, never for the running application process.

Using a single large image for all microservices.

Why it fails: A single shared image means one compromised container's vulnerability propagates to every microservice built from it, widening blast radius. Image reuse is tempting for consistency and faster builds, and would be correct where services genuinely share identical runtime dependencies and each container is otherwise isolated.

Allowing administrative access to all users by default.

Why it fails: Granting every user administrative rights by default directly contradicts least privilege and secure by default, exposing privileged functions before any authorisation occurs. Open access suits isolated lab or training environments, not production specifications where privilege must be explicitly assigned.

Using self-signed certificates in the development environment only.

Why it fails: Self-signed certificates bypass a trusted certificate authority, so clients cannot validate the server's identity and the development environment trains insecure habits. They would be acceptable only for isolated local testing, not as a secure-by-default specification requirement.

Providing a configuration wizard to enable SSL after deployment.

Why it fails: Deferring SSL to a post-deployment wizard leaves traffic unencrypted until an administrator acts, violating secure by default, which demands protection without manual enablement. Wizards suit optional hardening of legacy systems, not baseline specifications where TLS must be active from first boot.

The system automatically resets passwords if a login failure occurs.

Why it fails: Automatic password resets on login failure address credential recovery, not default behaviour on error. Fail-safe defaults require the module to refuse access unless a subject is explicitly authorised. Password reset flows are the right control when handling forgotten credentials, but they do not define the deny-by-default posture the stem asks about.

The system permits login if the authentication server is unreachable.

Why it fails: Permitting login when the authentication server is unreachable inverts fail-safe defaults: the module should deny access on error, not grant it. It is tempting because availability engineering deliberately keeps services usable during outages, but that goal applies to resilient front ends, not to authentication decisions where the default must be denial.

All new users are granted guest access until the admin verifies them.

Why it fails: Granting guest access before admin verification is fail-open: unverified users receive privileges by default. Fail-safe defaults instead deny access until authorisation is explicitly granted. Guest provisioning is correct where low-risk, unauthenticated access to public resources is intended, but it contradicts the deny-by-default principle for an authentication module.

Cross-Site Request Forgery (CSRF).

Why it fails: CSRF exploits a browser's automatic inclusion of ambient credentials such as cookies, not forged token signatures. The 'alg: none' flaw lets an attacker submit an unsigned JWT that the verifier accepts, bypassing signature validation entirely to forge arbitrary claims. CSRF defences would be the right control when sessions rely on cookies without anti-forgery tokens.

Broken object-level authorization.

Why it fails: Broken object-level authorization concerns whether a user may access a specific object, assuming their identity is already established. The 'alg: none' attack subverts that establishment by letting an unsigned token assert any identity or role, so authentication is bypassed before authorisation is reached. Object-level checks are the right control when identities are trustworthy but per-object access rules are missing.

Insecure cookie flags.

Why it fails: The alg:none attack lets an attacker forge unsigned tokens, so signature verification is the critical flaw; cookie flags govern transport and storage, not token authenticity. Cookie flags are tempting because JWTs are often stored in cookies, but insecure flags do not enable alg:none forgery.

Storing secrets in a configuration file within the deployment container.

Why it fails: Configuration files inside the container are copied into images and exposed through environment variables, logs and image layers, so secrets leak. It is tempting because externalised configuration is the right pattern for non-sensitive settings such as feature flags or endpoint URLs, where no confidentiality requirement applies.

Requesting secrets from the user at application startup.

Why it fails: Prompting the user at startup places secrets in memory, terminals and process listings, and prevents unattended restarts. It is tempting because it removes secrets from code and disk entirely, and would suit a locally run interactive tool where a human is always present to supply credentials.

Hard-coding secrets in the source code as encrypted strings.

Why it fails: Encrypted strings in source code still ship the decryption key alongside the ciphertext, and the repository retains the secret permanently. It is tempting because encryption appears to protect the value, and this approach would be acceptable for non-secret constants that merely need obfuscation, not confidentiality.

Using HTTPS for all communications.

Why it fails: HTTPS encrypts data in transit, addressing confidentiality and tampering, not authorisation decisions. Broken Access Control requires server-side enforcement of permissions per request. Transport encryption is tempting because it appears in most security baselines, but it leaves horizontal and vertical privilege escalation untouched.

Implementing a strong password policy.

Why it fails: Broken Access Control concerns authorisation enforcement, so a password policy addresses authentication strength and cannot constrain what an authenticated user may access. Password policies are the right control when the risk is credential compromise or weak authentication, such as enforcing length, complexity and rotation against brute-force or spraying attacks.

Relying on client-side hidden fields to identify user roles.

Why it fails: Hidden fields are client-controlled, so users can modify role values and escalate privileges. Access control must be enforced server-side against the authenticated session. Hidden fields are tempting because they are simple to implement in forms, but they provide no trustworthy authorisation boundary.

Increased network latency.

Why it fails: Latency is governed by network topology, connection pooling and query execution, none of which a shared service account alters. It is tempting because consolidating access sounds like a bottleneck, but connection multiplexing is a separate concern; the real risk is loss of per-service accountability and non-repudiation in audit trails.

Increased risk of SQL injection.

Why it fails: SQL injection stems from unsanitised input reaching query parsers, not from credential sharing; a shared account changes attribution and blast radius, not query construction. It is tempting because shared credentials widen access, but injection is mitigated by parameterised queries and input validation, which this design choice does not affect.

Incompatibility with container orchestrators.

Why it fails: Container orchestrators authenticate workloads through service accounts, secrets or workload identity, so a shared credential remains technically usable. It is tempting because orchestrators favour per-workload identity, but incompatibility is not the risk; the actual issue is that revocation or rotation affects every microservice simultaneously, and audit logs cannot attribute actions.

Open design.

Why it fails: Open design concerns publishing security mechanisms so they withstand public scrutiny, not simplifying them. The principle addressing simplicity is economy of mechanism, which minimises complexity to reduce implementation and configuration errors. Open design is tempting because it also reduces hidden flaws, but its focus is transparency rather than keeping mechanisms small and understandable.

Complete mediation.

Why it fails: Complete mediation requires every access to every object to be checked against policy, adding enforcement points rather than reducing complexity. It is tempting because it is a genuine Saltzer and Schroeder principle, and it would be the right answer to a question asking which principle ensures authorisation checks cannot be bypassed.

Defense in depth.

Why it fails: Defence in depth layers multiple independent controls so one failure does not compromise the system; it says nothing about simplicity. Economy of mechanism is the principle that security mechanisms should be as simple as possible. Defence in depth is tempting because layering is a core security design goal, but it addresses redundancy, not comprehensibility.

Relying on the frontend to filter out unauthorized menu items.

Why it fails: Frontend menu filtering is client-side and trivially bypassed by calling the API directly, so no server-side mediation occurs. It tempts because hiding UI elements improves user experience and reduces accidental access, but it is presentation logic, never an authorisation control, and the API remains fully reachable.

Checking authorization only once at the beginning of the user session.

Why it fails: Checking authorisation once at session start fails Complete Mediation, which requires each request to be validated, since permissions can change mid-session and later calls may target different resources. It tempts because it reduces per-request overhead, which is acceptable only when authorisation is immutable and every request targets the same protected resource.

Allowing public access to all GET methods in the API.

Why it fails: Complete Mediation demands every request be authorised against current policy; exposing all GET methods publicly bypasses that check entirely, letting unauthenticated callers read resources. It tempts because public read access suits non-sensitive catalogue or status endpoints, where no protected data or state change is involved.