Web Security, Privacy and Identity

Introduction and Context

Modern web applications do more than deliver documents. They process identities, financial transactions, health information, location data, educational records and business decisions. A security failure can therefore cause more than service interruption: it can expose private information, enable fraud, violate legal obligations and damage public trust.

Web security is the discipline of protecting web applications, users, services and data against unauthorized access, misuse, alteration and disruption. Privacy concerns the appropriate collection, use, disclosure, retention and deletion of information about identifiable people. Identity concerns how a system represents a user or service, authenticates that identity and makes decisions based on it. These concerns overlap but are not identical. A system may authenticate users correctly while still collecting excessive data, or it may protect confidentiality while incorrectly granting access.

Security must be designed as a system property rather than added through isolated patches. Secure design includes threat modelling, defensive programming, secure configuration, dependency management, monitoring, incident response and continuous testing. This chapter develops those ideas with particular attention to authentication, authorization, OAuth, OpenID Connect, tokens, encryption, secrets, common OWASP risks and privacy-aware design.

Learning Objectives

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

1. Distinguish authentication, authorization, identity, accountability and privacy.
2. Design safer password, session and token-handling mechanisms.
3. Explain OAuth 2.0 and OpenID Connect and select them appropriately.
4. Apply encryption, hashing, key management and secret-management principles.
5. Identify and mitigate injection, cross-site scripting, cross-site request forgery and insecure access control.
6. Analyse privacy, consent, retention and data-minimization decisions.
7. Evaluate a web security design using threat modelling and layered controls.

1. A Security and Identity Vocabulary

Assets, threats, vulnerabilities and controls

An asset is something valuable to protect: an account, database, API, private key, service or reputation. A threat is a potential cause of harm, such as a malicious user, compromised dependency or accidental disclosure. A vulnerability is a weakness that can be exploited. A control is a technical, organizational or procedural measure that reduces likelihood or impact.

The commonly used security objectives are confidentiality, integrity and availability. Confidentiality prevents unauthorized disclosure; integrity prevents unauthorized alteration; and availability ensures that authorized users can obtain services when needed. Authentication and authorization support these objectives but do not replace them.

A useful threat-modelling process is:

1. Identify assets and trust boundaries.
2. Enumerate actors, entry points and data flows.
3. Consider threats such as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
4. Estimate likelihood and impact.
5. Select preventive, detective and corrective controls.
6. Reassess the design after implementation and when requirements change.

Identity, authentication and authorization

Identity is a representation of an entity, such as a person, organization, device or service. Authentication answers, “Who or what is this?” It may use knowledge factors, possession factors, inherence factors or combinations of them. A password is a knowledge factor; a hardware security key is a possession factor; and a fingerprint is an inherence factor.

Authorization answers, “What is this authenticated entity permitted to do?” It should be enforced on every protected server-side operation. A user interface that hides an administrative button is not an authorization control. The server must independently verify the user, requested action, target resource and applicable policy.

Accounting or auditing records relevant security events so that actions can be investigated. Non-repudiation is a stronger property involving evidence that an actor cannot plausibly deny an action; ordinary application logs do not automatically provide it.

Least privilege and zero trust

Least privilege grants only the permissions necessary for a task, for only as long as necessary. Zero-trust thinking avoids assuming that a request is safe merely because it originates inside a corporate network or passed through a trusted component. Each request should be evaluated using identity, device or workload context, resource, action and policy. These principles are complementary: least privilege limits damage, while zero trust challenges unverified assumptions.

2. Authentication and Account Security

Passwords

Passwords should be accepted over an encrypted connection and stored only as salted, computationally expensive password hashes. A password hash is not reversible encryption. The server stores a derived value and verifies a submitted password by applying the same password-hashing algorithm.

Suitable password-hashing algorithms include Argon2id, scrypt, bcrypt or PBKDF2, configured according to current operational guidance and periodically reviewed. A unique random salt must be generated for every password. A salt prevents identical passwords from producing identical stored values and makes precomputed rainbow-table attacks less useful. A pepper, if used, is an additional secret kept separately from the database; it is not a replacement for a salt.

Applications should permit long passphrases, avoid arbitrary composition rules that encourage predictable substitutions, screen passwords against known breached-password lists where appropriate, and use rate limiting and breached-login detection. Password reset links must be short-lived, single-use and unguessable. Security questions are generally weak because their answers are often public or predictable.

Multi-factor authentication

Multi-factor authentication combines independent factors. A password plus a one-time code generated by an authenticator application is stronger than a password alone, although phishing-resistant hardware security keys are generally preferable for high-value accounts. SMS codes are vulnerable to SIM-swap and interception risks and should not be the strongest available option.

Recovery procedures deserve the same protection as normal login. An attacker who can bypass multifactor authentication through a weak support process has effectively defeated it.

Sessions and cookies

After authentication, a server commonly creates a session identified by a random session identifier stored in a cookie. The identifier should be generated using a cryptographically secure random generator, rotated after login or privilege changes, invalidated on logout and expired after an appropriate period of inactivity or absolute lifetime.

Important cookie attributes include:

A session cookie is a bearer credential: whoever possesses it may be treated as the user. Applications must therefore protect it from disclosure through logs, URLs, referrer headers, browser storage choices and cross-site scripting. Session fixation is mitigated by issuing a new identifier after authentication and privilege elevation.

Authentication errors and account enumeration

Login failures should not reveal whether an account exists. Similar response messages, carefully designed timing, rate limits and monitoring reduce account enumeration. However, usability and accessibility must be considered; overly aggressive controls can lock out legitimate users and create denial-of-service opportunities. Adaptive controls may combine IP reputation, device signals, account history and risk-based challenges.

3. Authorization and Access Control

Access-control failures are among the most damaging web vulnerabilities. A robust authorization decision considers the subject, action, object, context and policy. For example, “Can user U download document D?” is more precise than “Is U logged in?”

Role-based access control assigns permissions through roles such as student, lecturer or administrator. Attribute-based access control evaluates attributes such as department, ownership, time and device posture. Relationship-based policies use relationships such as “user is a member of project.” Real systems may combine these approaches.

Common failures include:

• trusting a role or price supplied by the browser;
• checking access on a page but not on its API endpoint;
• using predictable object identifiers without an ownership check;
• granting new privileges without revoking old ones;
• allowing a user to modify another tenant’s records;
• relying on client-side route guards;
• failing open when an authorization service is unavailable.

A secure pattern is deny by default, centralize policy where practical, verify authorization close to the protected operation, and test both allowed and denied cases. Object-level authorization should be explicit. Replacing sequential identifiers with random identifiers can reduce guessing but does not replace authorization checks.

4. OAuth 2.0 and OpenID Connect

OAuth 2.0

OAuth 2.0 is an authorization framework for delegated access. It allows a resource owner to authorize a client to obtain limited access to a resource server through an authorization server. OAuth access tokens represent delegated authority; they do not inherently prove the identity of the person operating the client.

For browser-based and mobile applications, the Authorization Code flow with Proof Key for Code Exchange (PKCE) is the preferred modern pattern. The client creates a high-entropy code verifier and sends a transformed challenge to the authorization server. After authentication and consent, the authorization server returns a short-lived authorization code. The client exchanges the code and verifier for tokens. PKCE helps prevent an intercepted authorization code from being redeemed by an attacker.

The redirect URI must be pre-registered and matched strictly. Wildcard or loosely validated redirect URIs can enable authorization-code theft. The state parameter binds the response to the initiating browser session and helps prevent request forgery. Scopes should be narrow and understandable. Access tokens should be short-lived, transmitted only over TLS and stored in a location appropriate to the client type.

OAuth roles are:

OpenID Connect

OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. It introduces an ID token, normally a signed JSON Web Token, containing claims about the authentication event and subject. The client validates the token’s issuer, audience, signature, time-related claims and nonce. The nonce links the returned identity response to the original authentication request and helps prevent replay or substitution attacks.

The ID token is intended for the client; an access token is intended for an API or resource server. Confusing these tokens is a serious design error. An API should validate an access token according to its issuer, audience, signature, expiry, scopes and other relevant claims rather than accepting an ID token merely because it is signed.

OIDC does not eliminate the need for local authorization. A claim that a user is authenticated does not automatically mean that the user may read every record. The application must map identity claims to its own policy and lifecycle rules.

5. Tokens, Cryptography and Secrets

Encryption, hashing and message authentication

Encryption is reversible with an appropriate key and protects confidentiality. Hashing is designed as a one-way transformation and is used for integrity-related purposes and password verification. A message authentication code (MAC) provides integrity and authenticity to parties sharing a secret. Digital signatures provide integrity and origin authentication using a private key and a corresponding public key.

Authenticated encryption, such as AES-GCM or ChaCha20-Poly1305, is preferred for application data because it provides confidentiality and integrity together. Nonces or initialization vectors must be generated and used according to the algorithm’s requirements; nonce reuse can be catastrophic for some modes. Applications should use reviewed cryptographic libraries rather than implementing algorithms themselves.

TLS protects data in transit between appropriately configured endpoints. It does not protect data after an endpoint is compromised, and it does not make an authorization decision. Encryption at rest protects stored data but does not remove the need for database access controls, key management and monitoring.

JSON Web Tokens

A JSON Web Token (JWT) commonly contains a header, claims payload and signature. Important claims may include issuer, subject, audience, expiry, not-before time and issued-at time. A JWT is usually signed, not encrypted; its payload can be readable by anyone who obtains it. Sensitive information should not be placed in an ordinary JWT.

JWT validation must reject unexpected algorithms, verify the signature with the correct trusted key, check issuer and audience, enforce expiry and account for clock tolerance. A token’s claims should be treated as authorization input only after validation. Long-lived tokens increase exposure after theft. Revocation is more difficult with self-contained tokens, so designs should use short access-token lifetimes, refresh-token rotation, server-side revocation or introspection where appropriate.

Secret management

Secrets include database passwords, API keys, signing keys, encryption keys and webhook credentials. They should not be committed to source control, embedded in client-side code, printed in logs or passed through insecure command-line arguments. A managed secret store can provide encryption, access policies, auditing and rotation. Production and development secrets must be separated, and services should receive only the secrets they require.

Key management includes generation, distribution, storage, rotation, backup, revocation and destruction. Rotation alone does not solve compromise if old keys remain trusted indefinitely. Incident procedures should identify which keys must be revoked and how dependent services will recover.

6. OWASP Risks and Secure Coding

Injection

Injection occurs when untrusted input changes the meaning of an interpreter command. SQL injection is prevented primarily through parameterized queries or safe, well-designed data-access abstractions. User input should not be concatenated into SQL, shell commands, LDAP filters or template expressions. Allow-list validation is useful for structured values such as sort fields, but validation is not a substitute for parameterization.

Command execution should be avoided where a library can perform the operation directly. If unavoidable, arguments must be passed through safe APIs, constrained by allow-lists and executed with minimal privileges.

Cross-site scripting

Cross-site scripting (XSS) allows attacker-controlled content to execute in a victim’s browser. Reflected XSS arises from an immediate response, stored XSS from persisted content and DOM-based XSS from unsafe client-side data flows.

The primary control is context-appropriate output encoding. HTML text, HTML attributes, URLs, JavaScript strings and CSS contexts require different handling. A generic “escape” function is not safe for every context. Framework auto-escaping should remain enabled. Dangerous HTML should be sanitized with a well-maintained, context-aware sanitizer only when the application genuinely supports rich content. Content Security Policy can reduce impact but is a defense in depth, not a substitute for correct encoding.

HttpOnly cookies can prevent some cookie theft through JavaScript, but they do not prevent an XSS payload from making authenticated requests in the victim’s browser. XSS is therefore both a confidentiality and authorization threat.

Cross-site request forgery

Cross-site request forgery (CSRF) tricks a browser into sending an authenticated request to a target site. It is especially relevant when authentication relies on cookies that browsers automatically attach. Defenses include SameSite cookies, unpredictable anti-CSRF tokens bound to the session, origin or referer validation where reliable, and re-authentication for highly sensitive operations. A GET request should not change state. APIs using an authorization header with a token that is not automatically attached by the browser have a different CSRF profile, but they still require careful cross-origin policy and XSS protection.

Insecure direct object references and broken access control

An endpoint such as /orders/481 must check whether the current subject may access order 481. Hiding the number, using a different URL or relying on the frontend does not constitute authorization. Tests should include horizontal escalation, in which one ordinary user accesses another user’s data, and vertical escalation, in which a lower-privileged user invokes an administrative action.

Security misconfiguration and vulnerable components

Default accounts, verbose production errors, unnecessary services, permissive CORS, outdated libraries and exposed administrative consoles expand attack surface. Secure defaults, dependency inventories, automated updates, software composition analysis, configuration review and reproducible deployments are important controls. Error responses should assist legitimate users without disclosing stack traces, secrets or internal topology.

Logging and monitoring

Security logs should record relevant authentication, authorization, administrative and data-access events, with time synchronization and protection against tampering. Logs should not contain passwords, access tokens or unnecessary personal data. Monitoring should detect unusual login patterns, repeated authorization failures, token misuse and unexpected data export. Alerting must be actionable; excessive false positives cause alert fatigue.

7. Privacy, Consent and Data Governance

Security protects data from unauthorized actions; privacy asks whether the data should be collected or used in the first place. Privacy-by-design principles include data minimization, purpose limitation, transparency, user control, default protection and accountability.

Before collecting data, an organization should identify the purpose, lawful or policy basis, categories of data, recipients, retention period and user rights applicable to its jurisdiction. Consent should be informed, specific, freely given and withdrawable where consent is the relevant basis. Bundling unnecessary processing into a required service, using confusing notices or making withdrawal difficult undermines meaningful consent.

Data minimization means collecting only what is reasonably necessary. For example, an application that needs to confirm adulthood may not need to store a full birth date. Pseudonymization replaces direct identifiers with a code but does not make data anonymous if re-identification remains reasonably possible. Anonymization aims to prevent identification but must be evaluated against auxiliary datasets and evolving techniques.

Retention schedules should specify when data is archived or deleted. Backups, replicas, caches, analytics systems and logs must be included in the analysis. Privacy-enhancing techniques such as aggregation, access separation, encryption, local processing and selective disclosure can reduce exposure.

Privacy notices should describe actual practices in clear language. Data-subject requests, breach notification duties, cross-border transfers and special protections for children or sensitive categories depend on applicable law. Developers should involve legal, compliance and accessibility specialists rather than assuming that a technical control alone establishes compliance.

8. A Secure Development Lifecycle

Security activities should occur throughout the software lifecycle:

• Requirements: classify assets, privacy needs, abuse cases and regulatory constraints.
• Design: define trust boundaries, identity flows, authorization policies and failure behavior.
• Implementation: use secure libraries, parameterization, output encoding and secret-management services.
• Verification: perform code review, unit and integration security tests, dependency scanning, dynamic testing and targeted penetration testing.
• Deployment: harden configuration, restrict privileges, protect pipelines and verify observability.
• Operations: patch, rotate keys, investigate alerts, rehearse incident response and review access.
• Retirement: revoke credentials, export or delete data appropriately and remove endpoints.

Threat modelling should be revisited when a new integration, data category, identity provider or deployment environment is introduced. Security is not achieved by a single audit; it is sustained through feedback and measurable improvement.

9. Illustrative Case: University Research Portal

Background

A university creates a research portal where students upload project reports, supervisors comment on them and administrators manage submissions. The portal uses a central OIDC provider for login and exposes a REST API to a single-page application.

Problem

An initial prototype hides administrative controls in the interface but permits any authenticated user to request /api/submissions/{id}. It stores access tokens in browser local storage, accepts uploaded HTML without sanitization and sends email links containing long-lived session identifiers. The privacy notice does not explain retention or sharing with an external analytics provider.

Analysis

The API has an object-level authorization weakness: an authenticated student may alter the identifier and read another student’s report. Stored XSS may affect supervisors who view uploaded content. Long-lived browser-accessible tokens increase the impact of XSS. Email URLs containing bearer credentials may leak through browser history, logs or referrer headers. The unexplained analytics processing violates transparency and may collect more information than needed.

Approach and solution

The team first models the actors and trust boundaries. The backend now checks submission ownership or supervisor assignment for every read and write operation, while administrative permissions are evaluated server-side. The application uses Authorization Code with PKCE, validates the OIDC issuer, audience, signature, expiry and nonce, and distinguishes the ID token from the API access token.

For the browser session, the backend uses a secure, HttpOnly, appropriately SameSite cookie with rotation and server-side expiry. Uploaded rich text is sanitized using a maintained library and displayed under a restrictive content policy. File types, sizes and storage paths are constrained, and files are served with safe content-disposition settings.

Email links contain a random, single-use, short-lived reset or invitation token that is not reused as the normal session credential. Secrets are moved to a managed store, and logs are reviewed to remove tokens and unnecessary student information. The university publishes a clear privacy notice, limits analytics, defines retention and provides an administrative deletion process consistent with institutional obligations.

Outcome

Security testing confirms that students cannot access one another’s submissions, malicious markup is rendered inert, expired links fail and unauthorized API calls are logged. The design is not “perfect”: phishing, compromised endpoints, insider misuse and provider outages remain possible. However, layered controls substantially reduce likelihood and impact, and the university can explain its processing practices.

Learning points

1. Authentication does not establish object ownership.
2. A signed identity token is not automatically an API authorization token.
3. Client-side controls are useful for usability but never sufficient for security.
4. Privacy requirements affect architecture, logging, retention and vendor selection.
5. Secure design includes recovery, monitoring and operational procedures.

10. Challenges, Limitations and Contemporary Developments

Security controls create trade-offs. Strong authentication can increase friction; extensive logging can create privacy risk; short token lifetimes can increase operational complexity; and aggressive rate limiting can harm accessibility. Decisions should be risk-based, documented and tested with representative users.

Passkeys based on public-key credentials are becoming an important alternative to passwords and can provide phishing resistance when implemented through platform authenticators or security keys. Hardware-backed keys, confidential computing, privacy-preserving analytics and continuous authorization are also developing areas. Artificial intelligence can assist with code review, anomaly detection and vulnerability triage, but generated code may contain insecure assumptions, leak confidential prompts or produce false confidence. AI outputs require human review, testing, data-governance controls and clear accountability.

Regulatory frameworks differ across jurisdictions, but common expectations include reasonable security, transparency, purpose limitation, data-subject rights, breach response and accountability. Compliance should be treated as a baseline; a legally permitted design may still be ethically inappropriate or technically unsafe.

Best-Practice Checklist

• Use HTTPS and secure transport configurations everywhere.
• Hash passwords with a modern adaptive password-hashing algorithm and unique salts.
• Prefer phishing-resistant multifactor authentication for sensitive accounts.
• Rotate sessions after login and privilege changes; protect cookie attributes.
• Use Authorization Code with PKCE for suitable OAuth clients.
• Validate token issuer, audience, signature, expiry and flow-specific claims.
• Keep access scopes narrow and enforce authorization on the server for every object.
• Use parameterized queries and context-aware output encoding.
• Apply CSRF defenses to cookie-authenticated state-changing requests.
• Store secrets in a managed system, not source code or logs.
• Minimize personal data, explain processing and enforce retention limits.
• Threat-model changes, test denied cases and monitor security events.

Chapter Summary

Web security, privacy and identity are related but distinct disciplines. Authentication establishes an identity claim, authorization determines permitted actions, and auditing supports accountability. Secure web applications use layered controls: strong password and multifactor practices, protected sessions, least privilege, explicit server-side authorization, safe OAuth and OIDC flows, validated tokens, authenticated encryption, managed secrets and secure coding.

Injection is controlled through parameterization and safe APIs. XSS requires context-aware output encoding and careful sanitization; CSRF requires browser-aware request defenses; and broken access control requires object-level policy checks rather than hidden interface elements. Privacy-by-design adds minimization, purpose limitation, meaningful consent, transparency, retention management and user control. A secure development lifecycle integrates these concerns from requirements through retirement. No single technology eliminates risk, so effective security combines sound architecture, testing, monitoring, governance and responsible human judgment.

Key Terms

Authentication: Process of establishing the identity of a user, service or device.

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

OAuth 2.0: Framework for delegated authorization to access protected resources.

OpenID Connect: Identity layer built on OAuth 2.0 that provides authentication and identity claims.

Access token: Credential presented to a resource server to request authorized access.

ID token: OIDC token intended to convey authentication information to the client.

PKCE: OAuth extension that binds an authorization-code exchange to a client-generated verifier.

Session fixation: Attack in which an attacker causes a victim to use a session identifier known to the attacker.

Least privilege: Granting only the permissions necessary for a task.

Injection: Manipulation of an interpreter through unsafe inclusion of untrusted input.

Cross-site scripting: Execution of attacker-controlled script in another user’s browser context.

CSRF: Abuse of a victim’s authenticated browser to send an unwanted request.

Hashing: One-way transformation used for password verification and other integrity-related purposes.

Authenticated encryption: Encryption that provides confidentiality and integrity together.

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

Threat modelling: Structured analysis of assets, trust boundaries, threats and mitigations.

Data minimization: Limiting collection and retention to what is necessary for a stated purpose.

Pseudonymization: Replacing direct identifiers with values that require additional information for attribution.

Content Security Policy: Browser-enforced policy that restricts permitted content sources and execution behavior.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. Why is a unique salt used when storing password hashes?
3. What is the purpose of PKCE in an OAuth authorization-code flow?
4. State two differences between an OIDC ID token and an OAuth access token.
5. Name three important cookie attributes and explain their purposes.

Long Answer Questions

1. Explain how a web application should manage authentication, sessions, logout and account recovery.
2. Compare role-based, attribute-based and relationship-based access control, giving an example of each.
3. Describe the causes and layered mitigations of SQL injection, XSS and CSRF.
4. Explain how privacy-by-design principles influence data collection, logging, retention and deletion.
5. Discuss the role of threat modelling and security testing across the software development lifecycle.

Analytical / Application Questions

1. A student can change an order identifier in an API URL and view another student’s order. Identify the vulnerability, explain why changing identifiers is not a sufficient defense, and propose a server-side authorization design.
2. A single-page application stores a long-lived access token in browser local storage and accepts unsanitized rich text. Analyse the likely attack paths and recommend a revised identity, token and content-handling architecture.
3. A university wants to use an external analytics service that receives full names, precise timestamps and page activity. Evaluate the proposal using data minimization, purpose limitation, transparency, retention and security principles, and recommend a safer alternative.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may do, while authorization verifies a password.

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

C. Authentication encrypts data, while authorization compresses data.

D. Authentication records logs, while authorization deletes accounts.

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

Question 2

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

A. To make the password reversible by administrators

B. To replace the need for an adaptive password-hashing algorithm

C. To ensure identical passwords do not produce identical stored hash values

D. To allow a browser to authenticate without a password

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

Question 3

Which OAuth approach is generally preferred for browser-based and mobile clients?

A. Authorization Code with PKCE

B. Password grant with a shared administrator password

C. Implicit transfer of a permanent access token in the URL

D. Unvalidated redirect-based token exchange

Correct Answer: A. Authorization Code with PKCE

Question 4

What is the intended primary audience of an OIDC ID token?

A. The database engine

B. The client application relying on the authentication result

C. Any unrelated resource server

D. The browser’s CSS processor

Correct Answer: B. The client application relying on the authentication result

Question 5

Which control most directly prevents SQL injection?

A. Hiding database errors from users only

B. Changing sequential record identifiers to random values

C. Using parameterized queries

D. Adding a visual CAPTCHA to the login page

Correct Answer: C. Using parameterized queries

Question 6

Why does output encoding need to be context-specific for XSS prevention?

A. Different output contexts interpret characters and markup differently.

B. Encoding is needed only for database passwords.

C. All contexts safely accept the same unmodified input.

D. Context-specific encoding disables HTTPS.

Correct Answer: A. Different output contexts interpret characters and markup differently.

Question 7

Which situation is most directly an object-level authorization failure?

A. A user submits a password over HTTPS.

B. A user changes an order ID and reads another customer’s order.

C. A server rotates a session identifier after login.

D. A system expires an access token.

Correct Answer: B. A user changes an order ID and reads another customer’s order.

Question 8

Which property is characteristic of authenticated encryption?

A. It provides confidentiality and integrity together.

B. It stores passwords in reversible plaintext.

C. It eliminates the need for key management.

D. It authenticates a user without any credential.

Correct Answer: A. It provides confidentiality and integrity together.

Question 9

Which practice best supports data minimization?

A. Collecting every available user attribute for possible future use

B. Keeping all logs indefinitely

C. Collecting only information necessary for a defined purpose

D. Publishing personal data to improve transparency

Correct Answer: C. Collecting only information necessary for a defined purpose

Question 10

What is a key privacy risk of pseudonymization?

A. Pseudonymized data can never be linked to a person.

B. The data may still be re-identified when combined with additional information.

C. Pseudonymization automatically grants user consent.

D. Pseudonymization prevents all unauthorized access without encryption.

Correct Answer: B. The data may still be re-identified when combined with additional information.