Security, Privacy and Digital Trust

Introduction

Modern full-stack applications are not merely collections of interfaces, services, and databases. They are systems of trust. Users trust an application to authenticate them correctly, protect their information, preserve the integrity of transactions, and remain available when needed. Organizations trust developers to implement controls that satisfy legal, contractual, and professional obligations. Partners trust application programming interfaces (APIs) to exchange data without unauthorized disclosure or manipulation.

Security, privacy, and digital trust are therefore architectural concerns rather than final-stage testing activities. A vulnerable design cannot be made fully secure by adding a few headers or installing a security scanner. Secure development requires the systematic identification of threats, reduction of attack surfaces, protection of identities and secrets, careful handling of personal data, and preparation for incidents.

This chapter examines secure-by-design principles, threat modeling, identity and access management, encryption, secrets management, OWASP guidance, privacy and compliance, zero-trust architecture, and incident response. The emphasis is on decisions made by full-stack professionals: how a browser, mobile client, API, identity provider, services, databases, cloud resources, and external suppliers can be designed as one security system.

Learning Objectives

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

• explain security, privacy, and digital trust as related but distinct concepts;
• apply secure-by-design and defense-in-depth principles;
• construct a practical threat model using assets, actors, trust boundaries, and threats;
• distinguish authentication, authorization, accounting, and identity federation;
• select suitable controls for passwords, sessions, tokens, encryption, and secrets;
• use OWASP guidance to evaluate common web and API risks;
• interpret privacy, governance, and compliance requirements in application design;
• explain zero-trust principles and their implications for full-stack systems;
• develop an appropriate incident-response workflow; and
• evaluate security trade-offs in a realistic software project.

1. Security, Privacy, and Digital Trust

Information security protects confidentiality, integrity, and availability. Confidentiality means that information is accessible only to authorized parties. Integrity means that information and systems are not altered improperly. Availability means that legitimate users can access services when required. These properties are often called the CIA triad, although modern practice also considers authenticity, accountability, resilience, and safety.

Privacy concerns how information about identifiable or reasonably identifiable people is collected, used, shared, retained, and deleted. Security is a major privacy safeguard, but privacy is broader. An application may securely store data while still violating privacy by collecting unnecessary information, retaining it indefinitely, or using it for an undisclosed purpose.

Digital trust is the confidence that a digital interaction will behave as represented. It depends on technical controls, transparent governance, reliable operations, legal compliance, and organizational conduct. Trust is damaged not only by a data breach, but also by unexplained surveillance, deceptive consent, unreliable availability, or failure to disclose an incident.

A useful design question is: “What must users, operators, and connected systems be able to trust, and what evidence will demonstrate that trust?” Evidence may include access logs, independent assessments, tested recovery procedures, clear privacy notices, and documented security decisions.

Core security principles

1. Secure by design: security requirements are defined before implementation and evaluated throughout the lifecycle.
2. Least privilege: each user, process, and service receives only the permissions needed for its tasks.
3. Defense in depth: multiple independent controls reduce reliance on one safeguard.
4. Fail securely: errors should deny unsafe actions rather than expose data or grant access.
5. Secure defaults: the initial configuration should be restrictive, not permissive.
6. Complete mediation: authorization should be checked whenever a protected resource is accessed, not only at login.
7. Separation of duties: sensitive actions should not be controlled by one unchecked person or component.
8. Economy of mechanism: simpler security mechanisms are easier to review and maintain.
9. Assume breach: architecture should limit damage even when one account, service, or device is compromised.
10. Usable security: controls that users cannot understand or operate reliably will be bypassed.

Security is a system property. For example, multi-factor authentication may protect an account, but it does not prevent an authorization flaw that allows one authenticated user to read another user's records.

2. Secure Development and Threat Modeling

A secure software development lifecycle integrates security into requirements, design, coding, testing, deployment, and operations. Typical activities include security requirements, architecture review, dependency analysis, code review, automated testing, configuration review, vulnerability management, logging, and post-incident learning.

Threat modeling is a structured method for asking how a system could be attacked or misused. It is most valuable early, when architectural changes are inexpensive. A practical threat model contains:

• Assets: data, credentials, payment records, source code, availability, and business capabilities;
• Actors: customers, administrators, employees, attackers, suppliers, and automated agents;
• Entry points: web forms, APIs, file uploads, message queues, administrative consoles, and cloud interfaces;
• Trust boundaries: transitions between browser and server, public and private networks, services, tenants, or organizations;
• Threats: possible actions that compromise confidentiality, integrity, availability, authenticity, or privacy;
• Controls: preventive, detective, and corrective measures; and
• Residual risk: the exposure remaining after controls are applied.

The STRIDE model is a useful classification scheme: Spoofing identity, Tampering with data, Repudiation of actions, Information disclosure, Denial of service, and Elevation of privilege. STRIDE does not replace professional judgment; it helps teams avoid overlooking categories of threat.

A threat-modeling workshop can follow this sequence:

1. Draw the system context and major data flows.
2. Mark trust boundaries and identify sensitive assets.
3. List realistic abuse cases for each entry point.
4. Identify existing and proposed controls.
5. Prioritize threats by probable impact and exploitability.
6. Assign owners and verification methods.
7. Revisit the model after major architectural or business changes.

Risk ratings should not become false precision. A score is a communication aid, not a measurement of truth. Teams should document assumptions, affected assets, attack prerequisites, business impact, and uncertainty.

Example: a file-upload threat model

Consider a student portal that accepts assignment files. Assets include student identity data and the application server. Entry points include the upload endpoint and the file-preview service. Threats include malware upload, denial of service through oversized files, path traversal through crafted filenames, and information disclosure through public URLs.

Controls may include authenticated upload, authorization checks, file-size and type limits, generated storage names, storage outside the executable web root, malware scanning, content-disposition headers, private object storage, rate limits, and audit logs. The design should also define what happens when scanning is unavailable. A secure failure may quarantine the file rather than publish it.

3. Identity and Access Management

Identity and access management (IAM) governs who or what may access which resource under which conditions. Four related functions should be distinguished:

• Identification: claiming an identity, such as entering a username.
• Authentication: proving control of that identity, such as using a password and one-time code.
• Authorization: deciding whether an authenticated subject may perform an action.
• Accountability or accounting: recording actions sufficiently to investigate and attribute them.

Authentication

Passwords should be long, unique, and stored using a deliberately slow, salted password-hashing function such as Argon2id, scrypt, or bcrypt. Passwords must not be stored in plaintext or with reversible encryption. A salt is a unique random value stored with the password hash; it prevents identical passwords from producing identical stored values and makes precomputed lookup attacks less effective.

Password policy should avoid predictable composition rules that encourage users to write passwords down. Rate limiting, breached-password screening, secure recovery, and multi-factor authentication are generally more valuable. Multi-factor authentication combines different factor types: something known, something possessed, or something inherent. A second password is not a genuinely independent factor.

Phishing-resistant methods, particularly hardware-backed passkeys using WebAuthn, can reduce credential theft. However, account recovery remains a sensitive path and must not undermine the strength of the primary authentication method.

Sessions and tokens

After authentication, a web application commonly creates a session. Session identifiers should be unpredictable, transmitted only over HTTPS, and protected with Secure, HttpOnly, and appropriate SameSite cookie attributes. Session identifiers should be rotated after login or privilege elevation and invalidated at logout and expiration. Long-lived sessions increase convenience but also increase exposure if a token is stolen.

JSON Web Tokens (JWTs) are signed claims, not automatically encrypted secrets. A signature can provide integrity and issuer authenticity, but anyone holding a token may be able to read its claims unless encryption is used. Applications must validate the expected algorithm, issuer, audience, expiration, and relevant claims. Token revocation, rotation, storage, and logout behavior must be designed explicitly. A server-side session is often simpler when immediate revocation is important.

OAuth 2.0 is an authorization framework, not a login protocol by itself. OpenID Connect adds an identity layer. In a browser-based application, the authorization-code flow with appropriate protections such as PKCE is generally preferred over exposing access tokens in URLs or using insecure implicit patterns.

Authorization models

Role-based access control (RBAC) assigns permissions to roles such as instructor or finance officer. It is understandable and effective when organizational roles are stable. Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and context, such as department, ownership, time, or device posture. ABAC is more expressive but can become difficult to audit. Many systems combine both.

Authorization must be enforced on the server and at the object level. A user interface that hides an administrator button is not an authorization control. For every sensitive request, the application should establish the caller's identity, determine the requested action and object, evaluate policy, and log an appropriate security event.

4. Encryption and Data Protection

Encryption transforms readable plaintext into ciphertext using a key. Symmetric encryption uses the same secret key for encryption and decryption and is efficient for data storage and bulk communication. Authenticated encryption, such as AES-GCM or ChaCha20-Poly1305, provides confidentiality and an integrity check when used correctly. Nonces must be unique for the relevant key; accidental nonce reuse can be catastrophic for some modes.

Asymmetric cryptography uses a public and private key. It supports key exchange, digital signatures, and certificate-based authentication. It is computationally more expensive and is commonly combined with symmetric encryption in protocols such as TLS.

TLS protects data in transit between parties that correctly validate certificates. It does not automatically protect data after it reaches a server, prevent authorization errors, or secure a compromised endpoint. Data at rest may require database encryption, encrypted backups, and protected object storage. Encryption is not a substitute for access control because an application still needs a secure way to use decryption keys.

Key management is often more difficult than selecting an algorithm. Keys require generation, restricted access, rotation where justified, backup or recovery procedures, revocation, destruction, and auditability. Keys should not be embedded in source code, committed to repositories, or included in client-side bundles.

5. Secrets Management

Secrets include database passwords, API keys, signing keys, private certificates, tokens, and encryption keys. A secret-management system should provide controlled storage, access policies, auditing, rotation support, and separation between environments. Development, testing, and production must not share secrets unnecessarily.

Common failures include placing secrets in Git history, exposing them through build logs, passing them as command-line arguments, returning them in error messages, and leaving them in client-side JavaScript. Environment variables can be useful, but they are not a complete secrets-management strategy; processes, logs, crash reports, and operators may still expose them.

A sound operational pattern is to grant a service a narrowly scoped identity, allow retrieval of only the secrets it needs, rotate credentials, and monitor access. If a secret is suspected to be exposed, assume compromise: revoke or rotate it, investigate use, preserve evidence, and update the contributing process.

6. OWASP Guidance for Full-Stack Applications

The OWASP Top 10 provides awareness of prevalent web application risks, while the OWASP Application Security Verification Standard (ASVS) offers more detailed verification requirements. OWASP API Security guidance is particularly relevant to service-oriented systems.

Important risk areas include:

• Broken access control: users access functions or objects outside their authority. Mitigation requires server-side, object-level checks and deny-by-default policy.
• Cryptographic failures: sensitive data is exposed through weak algorithms, poor key handling, or missing transport protection.
• Injection: untrusted input changes the meaning of a command or query. Parameterized queries, safe APIs, context-appropriate output encoding, and validation reduce risk.
• Insecure design: the system lacks a sound security control, not merely an incorrect implementation.
• Security misconfiguration: debug features, default credentials, excessive permissions, or unsafe cloud settings remain enabled.
• Vulnerable components: dependencies, containers, plugins, and runtimes contain known weaknesses or are unsupported.
• Identification and authentication failures: weak recovery, session handling, or credential controls permit account compromise.
• Software and data integrity failures: untrusted updates, packages, or serialized data are accepted without adequate verification.
• Logging and monitoring failures: important events are not recorded, protected, reviewed, or connected to response procedures.
• Server-side request forgery: an attacker causes a server to make unintended requests to internal or external resources.

OWASP guidance should be adapted to context. A checklist cannot establish that an application is secure. Teams should connect each requirement to a risk, implementation, test, owner, and evidence. Security testing should include static analysis, dependency scanning, dynamic testing, API testing, abuse-case testing, and manual review. Automated tools produce false positives and false negatives; expert analysis remains necessary.

7. Privacy, Compliance, and Governance

Privacy engineering begins with data mapping. Teams should identify what data is collected, why it is needed, where it travels, who can access it, how long it is retained, and how it is deleted. Data minimization reduces both privacy impact and breach impact. Privacy by design commonly involves proactive prevention, privacy-friendly defaults, embedded controls, transparency, and lifecycle protection.

Legal requirements depend on jurisdiction, sector, data type, and organizational role. Frameworks and laws such as the GDPR, CCPA/CPRA, HIPAA, PCI DSS, and regional data-protection statutes differ in scope and obligations. Students should not treat a framework name as a universal compliance guarantee. Legal counsel and competent privacy professionals are necessary for formal interpretation.

Common governance questions include:

• What is the lawful or otherwise authorized basis for processing?
• Has the organization stated purposes clearly and avoided incompatible reuse?
• Can a person exercise access, correction, deletion, portability, or objection rights where applicable?
• Are processors and suppliers governed by appropriate contracts?
• Are cross-border transfers and data residency requirements addressed?
• Is a data-protection impact assessment needed?
• How are retention and secure deletion implemented and verified?
• Are breach-notification responsibilities and deadlines understood?

Consent is not a universal solution. It should be informed, specific, freely given where required, and withdrawable. Interfaces should avoid dark patterns that pressure users into excessive data sharing.

Governance also covers algorithmic and AI-enabled features. Developers should consider whether training or inference data contains personal information, whether outputs expose confidential data, whether automated decisions require explanation or human review, and whether prompt or model logs retain sensitive content. AI security threats include prompt injection, data leakage, insecure tool use, and supply-chain manipulation. AI does not eliminate the need for ordinary authentication, authorization, validation, and monitoring.

8. Zero-Trust Architecture

Zero trust is an architectural approach summarized by “never trust, always verify,” although the phrase should not be interpreted as literally rejecting all trust. The model assumes that networks may be hostile, credentials may be stolen, and components may be compromised. Access decisions are continuously evaluated using identity, resource, action, device, application, and contextual signals.

Important principles include:

• verify explicitly using available evidence;
• apply least-privilege, just-in-time access;
• segment systems and limit lateral movement;
• protect data rather than relying on a network perimeter;
• monitor continuously and improve from telemetry; and
• automate policy enforcement where practical.

For a full-stack application, zero trust may mean separate service identities, mutual TLS or equivalent authenticated service communication, short-lived credentials, policy enforcement at APIs, administrative access through strong identity providers, and restricted east-west traffic. Microservices do not automatically create zero trust. They may instead increase attack surface and policy complexity if identities, authorization, and observability are weak.

9. Incident Response and Resilience

Preventive controls cannot guarantee that incidents will never occur. Incident response prepares an organization to detect, contain, eradicate, recover from, and learn from security events. A practical lifecycle is:

1. Preparation: define roles, contacts, playbooks, backups, logging, legal pathways, and exercises.
2. Detection and analysis: validate alerts, establish scope, preserve evidence, and classify severity.
3. Containment: limit spread while avoiding unnecessary destruction of evidence.
4. Eradication: remove malicious access, fix vulnerabilities, rotate exposed credentials, and rebuild where appropriate.
5. Recovery: restore trusted services, monitor closely, and confirm business and security requirements.
6. Post-incident improvement: document causes, decisions, communication, controls, and follow-up owners.

Response plans should distinguish an event from an incident. A failed login may be an event; a pattern indicating credential stuffing may be an incident. Logs should avoid unnecessary personal data and secrets, use reliable timestamps, resist tampering, and support correlation. Backups should be protected from ransomware and restoration should be tested, not assumed.

Communication is part of security. Stakeholders need accurate, timely, and appropriately scoped information. Concealing uncertainty or making unsupported claims can increase legal and reputational harm. Incident response should include technical, executive, legal, privacy, communications, and supplier responsibilities.

10. Applied Case: Campus Marketplace API

The following is an illustrative case.

Background

A university launches a marketplace where students sell used books. The system includes a React client, a REST API, a relational database, cloud object storage for images, a payment provider, and an external identity provider. The first release uses email and password login, JWT access tokens, administrator dashboards, and an image-upload feature.

Problem

A security review finds that the API accepts an item identifier from the client and returns the corresponding record without verifying ownership or publication status. Images are stored under predictable public URLs. The production API key for the payment provider appears in a deployment script. Administrators use the same broad role, and audit logs contain full email addresses and token fragments.

Analysis

The object-level authorization flaw is a broken-access-control risk: an authenticated student can enumerate identifiers and view another student's draft listing. Public image URLs may expose deleted or private images. The deployment key creates a supply-chain and secrets-management risk. Excessive administrator privileges violate least privilege. Token fragments and unnecessary personal data in logs increase privacy and incident impact.

Threat modeling identifies students, administrators, the payment provider, and cloud storage as actors or dependencies. Trust boundaries exist at the browser/API boundary, API/payment boundary, and application/storage boundary. Assets include unpublished listings, payment operations, identity data, and credentials.

Approach and solution

The team implements authorization as a server-side policy requiring that a student may read only published listings or their own drafts. It uses non-sequential identifiers where appropriate, but does not treat obscurity as authorization. Object storage becomes private, and the application issues short-lived, authorized download responses. Uploads are size-limited, scanned, stored with generated names, and served with safe content headers.

The payment key is revoked and replaced through a secrets manager with a narrowly scoped production identity. Deployment logs are reviewed for further exposure. Administrative permissions are divided into support, moderation, and finance roles. MFA is required for privileged accounts. Logs record event type, actor reference, object reference, decision, and timestamp without storing tokens or unnecessary contact data. Alerting detects repeated denied-object requests and unusual administrative activity.

The team also adds API tests for cross-user access, dependency scanning, threat-model review, backup testing, and an incident playbook for exposed credentials. Privacy documentation is updated to explain marketplace data use and retention.

Outcome and learning points

The revised design reduces unauthorized disclosure and limits the impact of a stolen credential. It also improves evidence for investigations and makes privacy practices more defensible. The central lesson is that security is not one feature. Authentication, authorization, storage configuration, secrets handling, logging, privacy, testing, and response must work together. A secure interface cannot compensate for an insecure API, and a secure API cannot compensate for exposed production credentials.

11. Challenges and Professional Trade-offs

Security controls impose cost and friction. MFA may increase support requests; detailed logging may increase storage and privacy obligations; short token lifetimes may require better session renewal; encryption may complicate search and recovery; strict supply-chain controls may slow releases. Professional security engineering makes these trade-offs explicit rather than silently accepting risk.

False assurance is a major danger. A passing vulnerability scan does not prove secure design. Compliance certification does not eliminate vulnerabilities. A firewall does not protect a permitted malicious request. Encryption does not fix excessive data collection. Zero trust does not remove the need for sound application authorization.

Security also has a human dimension. Developers need practical training, product managers need to prioritize security requirements, operators need usable runbooks, and leaders need to fund maintenance. Blaming individuals for systemic weaknesses discourages reporting and conceals recurring causes. A healthy security culture rewards early disclosure and treats incidents as opportunities for measurable improvement.

12. Contemporary Best Practices

A modern full-stack team should:

• maintain an asset inventory, data map, dependency inventory, and threat model;
• define security and privacy requirements as testable acceptance criteria;
• use centralized identity, MFA for privileged access, and least-privilege service accounts;
• enforce authorization on every protected server-side operation;
• use secure, authenticated transport and appropriate encryption for sensitive data;
• manage secrets through controlled systems and rotate exposed credentials immediately;
• validate input, encode output according to context, and use parameterized data access;
• patch supported dependencies and verify build and deployment provenance;
• collect useful, privacy-conscious logs and test alerting;
• isolate environments and protect backups;
• test recovery, incident response, and supplier failure scenarios; and
• review controls whenever features, data uses, integrations, or threats change.

Chapter Summary

Security, privacy, and digital trust are integrated properties of a full-stack system. Secure-by-design development begins with assets, threats, trust boundaries, and explicit requirements. Defense in depth, least privilege, secure defaults, fail-safe behavior, separation of duties, and an assume-breach mindset provide durable design principles.

IAM requires careful distinction between identification, authentication, authorization, and accountability. Strong password hashing, MFA, secure sessions, validated tokens, and server-side object-level authorization are essential. Encryption protects data when correctly applied, but key management and access control determine much of its practical value. Secrets require controlled storage, limited access, auditing, and rotation.

OWASP guidance helps teams address access control, injection, cryptographic failures, insecure design, misconfiguration, vulnerable components, authentication weaknesses, integrity failures, logging gaps, and server-side request forgery. Privacy requires data minimization, purpose limitation, transparency, retention control, rights management, and appropriate governance. Zero trust limits implicit assumptions about networks and identities. Incident response provides preparation, detection, containment, eradication, recovery, and learning when prevention fails.

The professional objective is not to claim that a system is perfectly secure. It is to reduce foreseeable harm, make security decisions evidence-based, preserve privacy, respond effectively, and improve continuously.

Key Terms

Authentication: Verifying that a subject controls a claimed identity.

Authorization: Determining whether an authenticated subject may perform an action on a resource.

CIA triad: Confidentiality, integrity, and availability.

Defense in depth: Use of multiple independent protective controls.

Digital trust: Confidence that digital systems behave securely, reliably, transparently, and as represented.

Encryption: Transformation of plaintext into protected ciphertext using a key.

Identity and access management: Governance of identities, authentication, authorization, and access records.

Least privilege: Granting only the permissions required for an authorized task.

Multi-factor authentication: Authentication using two or more independent factor types.

Nonce: A value intended for one-time or controlled-use association with cryptographic operations.

OAuth 2.0: A framework for delegated authorization.

OpenID Connect: An identity layer built on OAuth 2.0.

Privacy by design: Embedding privacy safeguards throughout system design and operation.

RBAC: Role-based access control, in which permissions are assigned through roles.

Secrets management: Controlled storage, retrieval, rotation, and auditing of sensitive credentials and keys.

STRIDE: A threat classification model covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Threat modeling: Structured analysis of assets, actors, trust boundaries, threats, and controls.

TLS: A protocol suite that provides authenticated and encrypted communication over networks.

Zero trust: An architecture that continuously verifies access and minimizes implicit trust.

Review Questions

Short Answer Questions

1. Distinguish security from privacy and explain how they overlap.
2. What are the main elements of a threat model?
3. Why is hiding an administrative button not an authorization control?
4. Explain why JWT signatures do not necessarily provide confidentiality.
5. List the major stages of incident response.

Long Answer Questions

1. Explain secure-by-design principles and show how they influence a full-stack application's lifecycle.
2. Compare RBAC and ABAC, including situations in which each is appropriate.
3. Discuss encryption, key management, and secrets management as related but distinct concerns.
4. Explain how OWASP guidance can be integrated into requirements, development, testing, and operations.
5. Analyze the relationship between privacy engineering, compliance, and digital trust.

Analytical / Application Questions

1. Design a threat model for an online examination system. Identify assets, actors, entry points, trust boundaries, three threats, and suitable controls.
2. An API authenticates users correctly but permits any logged-in user to request another user's invoice by changing an identifier in the URL. Diagnose the flaw and propose a layered remediation.
3. A production database credential is accidentally committed to a public repository. Describe the immediate response, investigation, recovery, and process improvements required.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents an authenticated student from reading another student's private record?

A. Hiding the record link in the user interface

B. Server-side object-level authorization

C. Increasing the password length requirement

D. Adding a public cache for records

Correct Answer: B. Server-side object-level authorization

Question 2

What is the primary purpose of a salt in password storage?

A. To decrypt the password during login

B. To make the password shorter

C. To ensure identical passwords do not produce identical stored hashes

D. To replace multi-factor authentication

Correct Answer: C. To ensure identical passwords do not produce identical stored hashes

Question 3

Which statement about a signed JWT is correct?

A. Its claims are always confidential

B. Its signature can provide integrity, but not necessarily confidentiality

C. It cannot expire

D. It automatically revokes itself after logout

Correct Answer: B. Its signature can provide integrity, but not necessarily confidentiality

Question 4

Which is an example of least privilege?

A. Giving every service administrator permissions

B. Allowing a reporting service to modify production payments

C. Giving a service only read access to the records it must report

D. Using one credential for all environments

Correct Answer: C. Giving a service only read access to the records it must report

Question 5

Which activity best represents privacy by design?

A. Collecting all potentially useful data indefinitely

B. Adding a privacy notice after deployment only

C. Minimizing collection and defining retention during system design

D. Encrypting data while ignoring its purpose

Correct Answer: C. Minimizing collection and defining retention during system design

Question 6

What does zero-trust architecture primarily require?

A. Trusting all requests inside the corporate network

B. Verifying access explicitly and applying least privilege

C. Removing all authentication between internal services

D. Using a firewall as the only security control

Correct Answer: B. Verifying access explicitly and applying least privilege

Question 7

Which OWASP risk involves untrusted input changing the meaning of a database command?

A. Injection

B. Repudiation

C. Security misconfiguration only

D. Data retention

Correct Answer: A. Injection

Question 8

What should normally happen first when a production secret is exposed?

A. Publish the secret to improve transparency

B. Ignore it if no misuse is immediately visible

C. Revoke or rotate the secret and begin investigation

D. Move the secret into client-side JavaScript

Correct Answer: C. Revoke or rotate the secret and begin investigation

Question 9

Which incident-response stage focuses on limiting the spread of an active compromise?

A. Preparation

B. Containment

C. Eradication

D. Post-incident improvement

Correct Answer: B. Containment

Question 10

Why is a public object-storage URL potentially problematic for private images?

A. It guarantees strong authorization

B. It may allow access without the application's authorization decision

C. It automatically encrypts the image

D. It prevents deletion of the image

Correct Answer: B. It may allow access without the application's authorization decision