Secure and Privacy-Aware Software Development

Introduction

Modern software operates in an environment of continuous exposure. Applications process financial records, health information, identity data, intellectual property, and communications while interacting with browsers, mobile devices, cloud services, third-party APIs, operating systems, and global supply chains. Security is therefore not a feature that can be added immediately before release. It is a system property that must be designed, implemented, verified, operated, and improved throughout the software life cycle.

Privacy adds a related but distinct obligation. Security primarily protects information and systems from unauthorized actions; privacy concerns the legitimate, fair, transparent, and proportionate collection and use of information about people. A system may be secure yet privacy-invasive if it collects excessive data or uses it for unexpected purposes. Conversely, a system may have a privacy-friendly purpose but fail to protect the data it holds.

This chapter presents an integrated approach to secure and privacy-aware development. It covers threat modeling, secure design, identity and access management, cryptography, secrets management, common vulnerabilities, zero-trust principles, privacy engineering, and software supply-chain security. The emphasis is on reasoning: understanding what must be protected, from whom, under which assumptions, and with what evidence that protections work.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Identify assets, actors, trust boundaries, threats, vulnerabilities, and risks.
2. Construct and evaluate a practical threat model.
3. Apply secure design principles to authentication, authorization, input handling, and error management.
4. Distinguish encryption, hashing, message authentication, digital signatures, and key management.
5. Design responsible secrets-management and identity-management practices.
6. Explain common application vulnerabilities and their mitigations.
7. Apply zero-trust principles to distributed systems.
8. Incorporate privacy requirements and data minimization into software design.
9. Assess software dependencies, build pipelines, and provenance as supply-chain risks.
10. Evaluate security controls using technical, ethical, legal, and operational criteria.

1. Security, Privacy, and Risk as Design Concerns

1.1 Core security properties

The traditional security objectives are often summarized as the CIA triad:

• Confidentiality: information is disclosed only to authorized subjects.
• Integrity: information and system behavior are protected against unauthorized alteration.
• Availability: authorized users can access required services when needed.

Other properties are essential in modern systems:

• Authenticity: an entity or message is genuine.
• Accountability: actions can be associated with responsible identities and evidence.
• Non-repudiation: a party cannot easily deny an action for which reliable evidence exists, although technical mechanisms cannot by themselves settle every legal dispute.
• Resilience: the system can withstand, recover from, and adapt to adverse events.

Security is risk management rather than absolute prevention. A useful conceptual model is:

Likelihood represents the estimated chance of an adverse event under stated assumptions; impact represents expected harm to confidentiality, integrity, availability, safety, finances, legal compliance, or reputation. The expression is a prioritization model, not a precise physical law. Risks may be qualitative, ordinal, or quantitative, and uncertainty should be recorded rather than hidden behind a numerical score.

1.2 Privacy as responsible information governance

Privacy engineering translates principles such as purpose limitation, data minimization, transparency, user control, accuracy, retention limitation, and confidentiality into system requirements. Important questions include:

• What personal data is collected?
• Is each element necessary for a specified purpose?
• Is the purpose communicated clearly before collection?
• How long is the data retained?
• Who may access it, and for what reason?
• Can individuals inspect, correct, export, or delete it where applicable?
• What happens when data is shared with processors, partners, or model providers?

Privacy is contextual. A location coordinate may be necessary for navigation but excessive for a simple weather display. A student identifier may support examination administration but should not be exposed in a public leaderboard.

2. Threat Modeling

Threat modeling is a structured method for anticipating misuse and failure before implementation. It is not a one-time document. Models should be revised when architecture, dependencies, data flows, deployment environments, or threats change.

2.1 Modeling elements

A useful model identifies:

• Assets: data, services, credentials, devices, keys, algorithms, and business capabilities.
• Actors: legitimate users, administrators, partners, malicious insiders, external attackers, automated agents, and accidental users.
• Entry points: web forms, APIs, file uploads, message queues, administrative interfaces, and build systems.
• Trust boundaries: transitions between different privilege, administrative, or assurance domains.
• Data flows: movement of data between processes, stores, and external systems.
• Security requirements: confidentiality, integrity, availability, authenticity, privacy, and auditability.

Data-flow diagrams are especially useful because they force a team to ask where validation occurs, where data is stored, and which component makes an authorization decision.

2.2 Threat categories and analysis

STRIDE is a common threat classification:

A threat model should lead to actionable controls. Listing “hacking” is not analysis; identifying “an unauthenticated API permits a user to retrieve another customer’s invoice by changing an identifier” is actionable.

2.3 A practical threat-modeling workflow

1. Define system purpose, scope, and security assumptions.
2. Inventory assets and classify data sensitivity.
3. Draw components, data flows, stores, external entities, and trust boundaries.
4. Enumerate threats using STRIDE, abuse cases, attack trees, or a suitable equivalent.
5. Estimate likelihood and impact, including safety and privacy harms.
6. Select mitigations and assign owners.
7. Record residual risk and acceptance authority.
8. Validate controls through tests, reviews, and monitoring.
9. Revisit the model after material changes or incidents.

Threat modeling is strongest when developers, security specialists, operations personnel, privacy professionals, and domain owners participate together. Different participants see different failure modes.

3. Secure Design Principles

Secure design reduces the number and severity of implementation mistakes.

3.1 Fundamental principles

• Least privilege: each identity, process, and service receives only the permissions needed for its task.
• Complete mediation: every security-sensitive access is checked, not merely the first access.
• Fail securely: errors should deny unsafe operations without exposing secrets or creating inconsistent state.
• Defense in depth: independent controls reduce dependence on one barrier.
• Secure defaults: the initial configuration should be protective, such as private storage and disabled debugging.
• Separation of duties: critical actions may require independent approval or distinct roles.
• Economy of mechanism: simpler security mechanisms are easier to inspect and test.
• Minimize attack surface: remove unused endpoints, permissions, libraries, ports, and administrative functions.
• Psychological acceptability: security controls should be understandable and usable; unusable controls are often bypassed.
• Secure by design and by default: security and privacy requirements belong in architecture and product decisions, not only in coding standards.

3.2 Trust boundaries and authorization architecture

A client request is not trustworthy merely because it originated from a user interface. Authorization must be enforced by a trusted server-side component at the point where protected data or an operation is accessed. The server should derive the subject from a validated session or token, retrieve the target resource, and verify the subject’s relationship to that resource.

Role-based access control assigns permissions through roles such as instructor or finance clerk. Attribute-based access control evaluates attributes of the subject, resource, action, and context, such as “a clinician may view records for patients assigned to the clinician’s department during an active treatment relationship.” Attribute-based policies can express richer rules but require careful policy governance and testing.

4. Authentication and Identity Management

Authentication answers “Who or what is this?” Authorization answers “What is it allowed to do?” They must not be confused.

4.1 Authentication factors

Authentication factors are commonly grouped as:

• Something the user knows, such as a password or personal identification number.
• Something the user has, such as a hardware security key or authenticator device.
• Something the user is, such as a biometric characteristic.

Multi-factor authentication combines independent factors. Two passwords are generally two knowledge elements, not true multi-factor authentication. Passwords should be long, unique, checked against compromised-password lists, and stored using a deliberately slow password-hashing scheme with a unique salt. Passwords should never be stored in plaintext or with reversible encryption.

Phishing-resistant methods, including WebAuthn/FIDO2-style public-key authentication, are preferable for high-value accounts. Recovery processes deserve the same rigor as ordinary login; an attacker often targets account recovery rather than the primary authentication mechanism.

4.2 Sessions and tokens

Session identifiers must be unpredictable, transmitted only over protected channels, restricted with appropriate cookie attributes, rotated after authentication or privilege changes, and invalidated on logout or expiry. Cookies commonly use Secure, HttpOnly, and an appropriate SameSite setting. Tokens should have narrow audiences, short lifetimes where suitable, and explicit revocation or rotation strategies.

A signed token is not necessarily encrypted. Its contents may be readable by whoever possesses it. Sensitive information should not be placed in a token unless confidentiality is separately provided and justified.

5. Cryptography and Secrets Management

Cryptography provides mechanisms, not a complete security solution. Correct algorithms can be defeated by poor key handling, weak authentication, unsafe endpoints, or incorrect protocol composition.

5.1 Main cryptographic functions

For password storage, memory-hard password hashing such as Argon2id is generally appropriate when configured according to current operational guidance. A salt is public, unique per password, and prevents identical passwords from producing identical stored values. A pepper is an additional secret kept separately from the password database; it can provide defense in depth but introduces key-management obligations.

For general data encryption, authenticated encryption is preferred because it protects confidentiality and detects tampering. Keys should be generated with a cryptographically secure random generator, have defined ownership and purpose, and be rotated according to risk and operational feasibility. Encryption does not eliminate the need for access control: an application that can decrypt everything on behalf of every user still needs authorization.

5.2 Key management life cycle

A professional key life cycle includes generation, distribution, activation, use, rotation, backup where justified, revocation, archival, and destruction. Keys should not be embedded in source code, container images, mobile binaries, or public repositories. Access to keys should be logged and limited. A hardware security module or managed key-management service may protect high-value keys, but it does not automatically solve application authorization or data-classification problems.

5.3 Secrets management

Secrets include database passwords, API keys, private keys, signing credentials, service tokens, and encryption keys. Recommended practices are:

• Store secrets in a dedicated secret manager rather than source control.
• Give workloads short-lived, automatically obtained credentials where possible.
• Separate development, testing, staging, and production secrets.
• Avoid printing secrets in logs, error reports, or telemetry.
• Rotate exposed secrets immediately and investigate the exposure.
• Audit access and alert on unusual retrieval patterns.
• Ensure backups and replicas receive equivalent protection.

A secret manager itself becomes a high-value target and must be protected through strong identity, network restrictions, monitoring, and recovery planning.

6. Common Vulnerabilities and Defensive Engineering

6.1 Injection

Injection occurs when untrusted data is interpreted as commands or code. SQL injection is mitigated with parameterized queries or safe, well-reviewed data-access abstractions, not by ad hoc string escaping alone. Command injection requires avoiding shell interpretation where possible and separating arguments from commands. Template, LDAP, and expression-language injection require context-specific output encoding and safe APIs.

6.2 Cross-site scripting and request forgery

Cross-site scripting (XSS) occurs when attacker-controlled content executes in another user’s browser. Context-aware output encoding, safe templating, input constraints, Content Security Policy, and avoidance of dangerous DOM APIs reduce risk. Sanitization is necessary when legitimate HTML must be accepted, but it must use a well-maintained, context-appropriate sanitizer.

Cross-site request forgery (CSRF) abuses an authenticated browser’s automatic credentials. SameSite cookies, anti-CSRF tokens, origin checks, and avoiding state changes through GET requests are common defenses. Modern token-based architectures still require careful analysis of where credentials are stored and automatically sent.

6.3 Broken access control

Broken access control includes insecure direct object references, privilege escalation, missing tenant isolation, and relying on client-supplied roles. Every sensitive operation requires server-side policy enforcement and tests for both allowed and denied cases. Multi-tenant systems should treat tenant identifiers as untrusted input and enforce isolation at every data-access layer.

6.4 Insecure deserialization, file handling, and SSRF

Deserializing untrusted objects can cause code execution, denial of service, or data corruption. Prefer simple data formats with strict schemas and explicit type handling. File uploads should be size-limited, type-validated using content inspection, renamed, stored outside executable paths, and scanned when appropriate.

Server-side request forgery (SSRF) occurs when an application fetches attacker-controlled destinations and can reach internal services. Defenses include allowlists, URL and redirect validation, egress controls, network segmentation, and cloud metadata-service protections. Validation must account for DNS rebinding, alternate IP representations, and redirect behavior.

6.5 Error handling, logging, and monitoring

Errors should reveal enough information for legitimate diagnosis without disclosing credentials, internal topology, personal data, or stack traces to users. Logs should support investigation while respecting data minimization. They should record security-relevant events such as authentication failures, privilege changes, administrative actions, key events, and unusual data access. Logs need integrity protection, restricted access, retention rules, clock synchronization, and alerting; collecting data without a response process creates surveillance rather than security.

7. Zero-Trust Architecture

Zero trust rejects the assumption that a network location or prior access makes a request trustworthy. Its central practical ideas are:

• Verify explicitly using identity, device, workload, resource, and contextual signals.
• Apply least-privilege access.
• Assume breach and limit lateral movement.
• Continuously evaluate access and monitor outcomes.

Zero trust does not mean blindly challenging users at every moment. It means that access decisions are based on evidence and policy rather than an implicit “inside the network” status. A service-to-service request should be authenticated and authorized even when both services run in the same cluster. Mutual TLS, workload identity, short-lived credentials, policy enforcement points, network segmentation, and centralized or distributed policy decision components are common implementation techniques.

Zero trust has limitations. Excessive policy complexity can make systems unusable; identity signals can be wrong; monitoring can create privacy concerns; and legacy systems may not support modern identity. Migration should therefore be incremental, beginning with high-value applications and clear trust-boundary improvements.

8. Privacy Engineering in the Software Life Cycle

Privacy requirements should be captured as testable requirements, not vague statements such as “respect privacy.” A privacy impact assessment can identify data flows, purposes, risks to individuals, legal bases where applicable, recipients, retention, and safeguards.

8.1 Privacy design strategies

Useful strategies include:

• Minimize: collect and retain only necessary data.
• Separate: isolate data by purpose, tenant, or identity where appropriate.
• Aggregate: use summarized data instead of individual records.
• Hide: apply encryption, pseudonymization, or access restrictions.
• Control: provide meaningful choices and permissions.
• Inform: communicate collection and use clearly.
• Enforce: encode policy in architecture and access controls.
• Demonstrate: retain evidence that requirements are being followed.

Pseudonymization reduces direct identification but does not necessarily make data anonymous. If auxiliary information can reconnect records to individuals, the privacy risk remains. Anonymization is difficult and must be evaluated against realistic re-identification threats.

8.2 Retention and deletion

Retention schedules should specify categories, purposes, periods, legal or operational justifications, and deletion or anonymization procedures. Deletion must cover active databases, caches, search indexes, logs, replicas, backups, and exports where applicable. Technical deletion may be constrained by immutable backups or legal holds; such constraints should be documented and access restricted.

8.3 Privacy and machine learning

AI systems introduce additional concerns: training-data provenance, memorization, model inversion, prompt or retrieval leakage, sensitive profiling, automated decision bias, and third-party processing. Controls may include data minimization, access boundaries, redaction, evaluation for leakage and bias, human review for consequential decisions, retention limits, and clear user communication. A model output is not automatically safe merely because the underlying model is hosted by a reputable provider.

9. Software Supply-Chain Security

Applications depend on packages, operating-system images, build tools, plugins, cloud services, and generated artifacts. A vulnerability or compromise in any of these can affect downstream users.

A supply-chain program should include:

• Dependency inventories and a software bill of materials (SBOM).
• Version pinning and reproducible or hermetic builds where feasible.
• Verification of package signatures and trusted registries.
• Automated scanning for known vulnerabilities, licenses, malicious packages, and secret leakage.
• Review of transitive dependencies and abandoned components.
• Protected source repositories and branch controls.
• Isolated build runners with minimal permissions.
• Separation between build, signing, and release authority.
• Artifact signing, provenance records, and verification at deployment.
• Rapid patching, emergency revocation, and incident-response procedures.

A vulnerability scanner is not a risk decision-maker. A high-severity issue may be unreachable in a particular deployment, while a lower-rated weakness may expose a critical asset. Findings require technical analysis, compensating controls, exploitability assessment, and documented ownership.

10. Verification, Testing, and Secure Operations

Security must be tested at multiple levels:

• Unit tests for validation and authorization rules.
• Integration tests for identity, data access, and tenant isolation.
• Property-based and fuzz testing for parsers and boundary conditions.
• Static analysis for code and configuration.
• Dynamic testing and penetration testing for running systems.
• Dependency and container scanning.
• Infrastructure-as-code policy checks.
• Manual review of threat models and high-risk changes.
• Disaster-recovery and incident-response exercises.

Security tests should include negative cases: expired tokens, altered identifiers, missing permissions, malformed files, replayed requests, excessive input, and compromised dependencies. A control is more credible when its failure behavior and monitoring have also been tested.

Incident response should define preparation, detection, analysis, containment, eradication, recovery, notification, and lessons learned. Evidence preservation and privacy obligations must be considered together. After an incident, organizations should improve systems and processes rather than merely blame an individual developer.

Applied Case: Illustrative Online Health Consultation Platform

Background

Consider a fictional online health consultation platform serving patients, clinicians, laboratories, and support staff. It stores appointment data, clinical notes, prescriptions, billing records, and video-session metadata. The platform uses a web application, mobile clients, an API gateway, cloud storage, a relational database, a notification provider, and several external laboratory APIs.

Problem

A security review identifies three concerns: a patient can alter an invoice identifier in an API request; laboratory API credentials are stored in a deployment script; and the product team proposes retaining all video metadata indefinitely “for analytics.” The organization also wants clinicians to access records from personal devices.

Analysis

Threat modeling identifies the patient and clinician portals as separate trust contexts, the API gateway and services as policy enforcement points, and the laboratory integration as an external boundary. Assets include clinical records, credentials, billing information, and availability of urgent consultations. Threats include broken object-level authorization, credential theft, excessive retention, unauthorized device access, and compromise of a third-party provider.

The privacy analysis finds that indefinite retention lacks a specific purpose and increases harm if records are exposed. The device proposal requires stronger authentication, session control, device risk assessment, and remote revocation. The laboratory credential in a script could be copied by anyone with repository access and may remain in version history.

Approach and solution

The team implements server-side object authorization using the authenticated patient or clinician identity, tenant and care-relationship checks, and negative integration tests. Laboratory credentials are moved to a managed secret store, replaced with short-lived workload credentials where supported, and rotated because historical exposure is possible.

Clinical records are encrypted using managed keys, with access separated by service and role. Clinicians use phishing-resistant multi-factor authentication, short-lived sessions, device registration, and remote session revocation. The platform records access to clinical records, but excludes unnecessary clinical content from operational logs.

Video metadata is classified by purpose. Only information needed for billing, safety, or service operation is retained, with documented periods and deletion workflows. Analytics uses aggregated data where possible. External providers must meet contractual security and privacy requirements, and the platform verifies signed build artifacts and maintains an SBOM.

Outcome

The direct-object vulnerability is removed, credentials are no longer embedded in source-controlled deployment material, and the retention burden is reduced. Clinician access becomes more controlled without relying solely on network location. The organization also gains auditable evidence for access decisions, data retention, and release provenance.

Learning points

The case demonstrates that security and privacy decisions interact. Authorization protects a patient record from another patient; minimization reduces the amount of material that could be exposed; secrets management limits credential reuse; and supply-chain controls address risks outside application code. No single control is sufficient.

Professional, Ethical, and Governance Considerations

Security professionals have duties to users, employers, society, and the law. They should report serious weaknesses responsibly, avoid unnecessary access to personal data, document uncertainty, and avoid overstating assurance. Privacy notices should be understandable and should not disguise unexpected surveillance in legal language.

Regulatory obligations vary by jurisdiction and sector, but common themes include lawful and transparent processing, protection of sensitive data, breach response, data-subject rights, processor governance, and demonstrable accountability. Compliance is a baseline, not proof of security. Organizations should map requirements to controls, owners, evidence, and review dates.

Security decisions also distribute power. Continuous monitoring, biometric authentication, automated risk scoring, and behavioral analytics may disadvantage vulnerable groups or create chilling effects. Teams should evaluate necessity, proportionality, accessibility, bias, alternatives, and avenues for human appeal.

Challenges and Limitations

Security controls create cost, latency, operational complexity, and user friction. Strong encryption can complicate lawful recovery and debugging. Fine-grained authorization can become difficult to test. Centralized identity services can become critical dependencies. Automated scanners produce false positives and false negatives. Privacy-preserving transformations may reduce analytical utility, while excessive data collection creates long-term liability.

There is also a persistent gap between design intent and operational reality. Emergency access, misconfigured cloud storage, forgotten test accounts, stale dependencies, and rushed releases can bypass carefully designed controls. Effective programs therefore combine architecture, secure coding, automation, independent review, training, incident readiness, and a culture that rewards early reporting.

Best-Practice Development Checklist

Before release, a team should be able to answer yes to the following questions:

• Have assets, trust boundaries, threats, and residual risks been documented?
• Are authentication, authorization, recovery, and session controls explicit and tested?
• Are inputs validated according to context, and are outputs safely encoded?
• Are secrets absent from source code, logs, images, and client applications?
• Are cryptographic algorithms, keys, certificates, and rotation responsibilities defined?
• Is personal data minimized, classified, retained only as needed, and deleted appropriately?
• Are dependencies inventoried, reviewed, patched, and represented in provenance records?
• Are builds and releases protected from unauthorized modification?
• Are monitoring, alerting, incident response, backup, and recovery tested?
• Can the organization demonstrate what it does, rather than merely claim that it does it?

Chapter Summary

Secure and privacy-aware development treats protection of systems and people as a life-cycle responsibility. Threat modeling identifies assets, boundaries, actors, and plausible misuse so that controls address concrete risks. Secure design relies on least privilege, complete mediation, defense in depth, secure defaults, separation of duties, and minimized attack surface.

Authentication establishes identity, while authorization determines permitted actions. Cryptography must be selected and implemented with correct key management; passwords require slow, salted hashing, and application secrets belong in managed systems rather than source code. Common vulnerabilities such as injection, XSS, CSRF, broken access control, unsafe deserialization, file-handling flaws, and SSRF require context-specific defenses and negative testing.

Zero-trust architecture replaces implicit network trust with explicit, least-privilege, continuously evaluated access. Privacy engineering adds purpose limitation, minimization, transparency, retention control, user agency, and demonstrable governance. Supply-chain security extends protection to dependencies, build systems, artifacts, and provenance. Finally, secure software depends on testing, monitoring, incident response, ethical judgment, and continuous improvement rather than any single tool or certification.

Key Terms

Threat modeling: Structured identification and treatment of threats before and during system development.

Asset: Something valuable that requires protection, such as data, credentials, or service availability.

Trust boundary: A transition between components or domains with different trust or privilege assumptions.

Least privilege: Granting only the permissions necessary for an entity’s task.

Authentication: Verification of the identity of a user, device, service, or process.

Authorization: Determination of which actions an authenticated subject may perform.

Multi-factor authentication: Authentication using independent categories of evidence.

Cryptographic hash: A one-way function that produces a fixed-length digest from input data.

Encryption: Transformation of data to conceal its content from unauthorized parties.

Digital signature: A public-key mechanism supporting integrity and origin authentication.

Secret: Sensitive credential or key material requiring controlled storage and access.

Zero trust: A security approach that does not grant implicit trust based on network location.

Privacy engineering: Applying privacy principles through technical and organizational design.

Data minimization: Limiting data collection and retention to what is necessary.

Pseudonymization: Replacing direct identifiers while retaining a controlled possibility of linkage.

Injection: Treating untrusted input as commands, queries, or executable code.

Cross-site scripting: Injection of active content into a context viewed by another user.

Software bill of materials: An inventory of components used to construct a software product.

Provenance: Evidence describing how, where, and by whom a software artifact was produced.

Residual risk: Risk remaining after safeguards have been applied.

Review Questions

Short Answer Questions

1. Distinguish confidentiality, integrity, and availability, and give one example of each.
2. Why must authorization be enforced on the server rather than trusted to a client interface?
3. Explain the difference between encryption and cryptographic hashing.
4. What is the purpose of a software bill of materials?
5. Why is pseudonymization not automatically equivalent to anonymization?

Long Answer Questions

1. Describe a complete threat-modeling workflow for a cloud-based application. Explain the role of assets, trust boundaries, threats, mitigations, and residual risk.
2. Compare role-based and attribute-based access control. Discuss their strengths, limitations, and testing requirements.
3. Explain the life cycle of cryptographic keys and the operational risks of embedding secrets in source code.
4. Discuss how zero-trust principles can be applied to service-to-service communication in a distributed system.
5. Explain how privacy requirements should influence data collection, retention, logging, analytics, and deletion throughout the software life cycle.

Analytical / Application Questions

1. An API accepts a customer ID from the browser and returns the corresponding invoice without checking ownership. Identify the vulnerability, construct a threat statement, and propose layered controls and tests.
2. A company wants to retain all user location history indefinitely to support possible future analytics. Analyze the proposal using purpose limitation, minimization, retention, security, and governance principles, then recommend an alternative.
3. A critical dependency is reported as vulnerable, but the affected function is not enabled in the organization’s deployment. Explain how the team should assess exploitability, compensating controls, business impact, patch urgency, and evidence before accepting or remediating the risk.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines permitted actions, while authorization verifies identity.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication encrypts data, while authorization hashes passwords.

D. Authentication records logs, while authorization deletes sessions.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

Which control most directly mitigates SQL injection?

A. Parameterized queries

B. Longer session timeouts

C. Disabling audit logs

D. Storing passwords in plaintext

Correct Answer: A. Parameterized queries

Question 3

Why is a unique salt used when storing password hashes?

A. To make the password recoverable by administrators

B. To eliminate the need for a password-hashing algorithm

C. To prevent identical passwords from producing identical stored values

D. To encrypt the database connection

Correct Answer: C. To prevent identical passwords from producing identical stored values

Question 4

Which principle requires every sensitive access to be checked rather than trusting an earlier check?

A. Complete mediation

B. Data aggregation

C. Non-repudiation

D. Availability

Correct Answer: A. Complete mediation

Question 5

Which statement about zero trust is correct?

A. Internal network traffic is trusted automatically.

B. Only external users require authentication.

C. Access is based on explicit verification and least privilege rather than location alone.

D. Zero trust eliminates the need for monitoring.

Correct Answer: C. Access is based on explicit verification and least privilege rather than location alone.

Question 6

A signed token is intercepted by an attacker. Which statement is most accurate?

A. A signature automatically makes the token confidential.

B. The token may remain readable even though its integrity can be verified.

C. The token cannot be replayed under any circumstances.

D. Signing removes the need for authorization checks.

Correct Answer: B. The token may remain readable even though its integrity can be verified.

Question 7

Which practice best supports software supply-chain integrity?

A. Allowing unrestricted build-server permissions

B. Pinning dependencies and verifying signed artifacts or provenance

C. Removing dependency inventories

D. Copying packages directly from unknown websites

Correct Answer: B. Pinning dependencies and verifying signed artifacts or provenance

Question 8

Which example best represents data minimization?

A. Collecting every available user attribute for possible future use

B. Retaining all logs forever regardless of purpose

C. Collecting only the location precision necessary for the service

D. Publishing raw identifiers in analytics reports

Correct Answer: C. Collecting only the location precision necessary for the service

Question 9

Which defense is most appropriate for a server-side request forgery risk?

A. Allowing arbitrary outbound URLs

B. Using destination allowlists and restricting egress

C. Disabling password rotation

D. Displaying stack traces to users

Correct Answer: B. Using destination allowlists and restricting egress

Question 10

A service credential is accidentally committed to a public repository. What is the most appropriate immediate response?

A. Leave it in place because the commit can be deleted later

B. Rename the variable but keep the same credential

C. Revoke or rotate the credential and investigate exposure

D. Print the credential in logs to determine who used it

Correct Answer: C. Revoke or rotate the credential and investigate exposure