Application Security, Privacy and Responsible Computing

Introduction and Context

A full-stack application is not secure merely because it uses a modern framework, encrypted connections, or a cloud platform. Security is a system property produced by coordinated decisions across the user interface, application programming interfaces (APIs), business logic, databases, infrastructure, development workflow, and organisational governance. Privacy and responsible computing extend this view: an application must not only resist unauthorised access but also collect, process, explain, and retain information fairly and lawfully.

In Full Stack Project–I, security and privacy should be treated as design requirements rather than final-stage testing activities. A project team must identify assets and threats, reduce unnecessary data collection, enforce authorisation on the server, protect secrets, validate input, log meaningful events, and prepare for incidents. Responsible computing additionally requires consideration of accessibility, discrimination, environmental effects, professional accountability, and the social consequences of automated decisions.

This chapter presents an integrated approach suitable for postgraduate full-stack development. It combines threat modelling, secure architecture, application controls, privacy engineering, governance, testing, and incident response.

Learning Objectives

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

1. distinguish application security, cybersecurity, information security, privacy, and responsible computing;
2. analyse assets, trust boundaries, threats, vulnerabilities, and risks in a full-stack system;
3. design authentication, authorisation, session, input-validation, and data-protection controls;
4. apply secure development, testing, logging, dependency-management, and deployment practices;
5. evaluate privacy using principles such as purpose limitation, data minimisation, transparency, and retention control;
6. assess ethical, legal, accessibility, algorithmic, and sustainability implications of a project; and
7. respond systematically to a security incident and communicate its consequences to stakeholders.

1. Essential Concepts and Terminology

Application security concerns protecting software and its data from unauthorised access, misuse, alteration, disclosure, and disruption. Cybersecurity is broader and includes networks, devices, identities, operations, and resilience. Information security protects confidentiality, integrity, and availability of information regardless of its format.

The classic CIA triad is a useful starting model:

• Confidentiality: information is disclosed only to authorised subjects.
• Integrity: information remains accurate, complete, and protected from unauthorised modification.
• Availability: authorised users can access services and information when required.

Other properties are equally important in contemporary systems. Authenticity concerns whether an identity or message is genuine. Accountability connects actions to responsible identities through reliable records. Non-repudiation provides evidence that an action or communication occurred, although technical evidence alone cannot solve every legal dispute.

A threat is a potential cause of harm, such as credential theft. A vulnerability is a weakness that can be exploited, such as missing authorisation checks. An exploit is a technique or code that takes advantage of a vulnerability. Risk is the possibility of loss arising from a threat exploiting a vulnerability. A simple qualitative model is:

Likelihood and impact may be rated qualitatively, for example from 1 to 5. The expression is a prioritisation aid, not a universal physical law. Ratings must be defined consistently, and the model does not capture uncertainty, dependencies, or correlated failures. In professional practice, risk registers should record assumptions, owners, controls, residual risk, and review dates.

An asset may be data, an account, a payment function, source code, a service, or organisational reputation. A trust boundary is a point at which data or control moves between components with different security assumptions—for example, between a browser and API, or between an API and a third-party payment provider.

2. Threat Modelling for Full-Stack Systems

Threat modelling is a structured process for anticipating abuse before implementation. A practical sequence is:

1. describe the system and its data flows;
2. identify assets, actors, entry points, and trust boundaries;
3. enumerate threats and abuse cases;
4. assess likelihood and impact;
5. select preventive, detective, and corrective controls; and
6. validate the model as the system changes.

A data-flow diagram normally identifies the browser or mobile client, web server, API gateway, application services, database, object storage, identity provider, message broker, administrators, and external services. Threats should be considered at each boundary rather than only at the login screen.

The STRIDE mnemonic is often used to organise analysis:

Threat modelling should include misuse cases. For example, “a customer views another customer’s invoice by changing an identifier in the URL” identifies an authorisation threat that ordinary functional requirements may overlook. Security controls should be mapped to threats and tested with explicit acceptance criteria.

3. Secure Architecture and the Principle of Least Privilege

A defensible architecture separates presentation, application, domain, and data concerns. This separation is not automatically secure, but it makes validation, authorisation, testing, and change control more manageable. The client should be treated as untrusted: hidden fields, disabled buttons, and client-side route guards improve usability but do not enforce security. The server must independently authenticate the caller, authorise the requested action, validate the data, and apply business rules.

Important design principles include:

• Least privilege: each user, service, process, and database credential receives only the permissions needed for its task.
• Deny by default: access is refused unless a rule explicitly permits it.
• Complete mediation: each protected operation is checked, not merely the first page visit.
• Fail securely: errors should not expose secrets or silently grant access.
• Secure defaults: initial configuration should be restrictive.
• Separation of duties: sensitive actions may require independent roles or approvals.
• Defence in depth: several partially independent controls reduce the chance that one failure becomes a breach.
• Secure by design: security requirements are considered during modelling and architecture, not appended after coding.

A common failure is confusing authentication with authorisation. Authentication answers “Who are you?” Authorisation answers “What may this authenticated identity do to this particular resource in this context?” A role such as staff is often insufficient. Object-level checks must verify ownership, organisational scope, or delegated permission.

4. Identity, Authentication and Authorisation

Authentication can use knowledge factors, possession factors, inherence factors, or combinations of them. Passwords should be long enough, checked against compromised-password lists where feasible, and stored using a dedicated password-hashing algorithm with a unique salt and an appropriate work factor. Passwords must never be stored as reversible encryption or plaintext. Multi-factor authentication substantially reduces the impact of password compromise, especially for administrators and high-value operations.

Sessions require careful lifecycle management. A secure design should rotate the session identifier after authentication or privilege elevation, expire sessions according to risk, invalidate sessions on logout or account recovery, and protect cookies with Secure, HttpOnly, and an appropriate SameSite attribute. Token-based systems require equivalent attention to audience, issuer, expiry, signature validation, revocation strategy, storage, and key rotation. A signed token is not necessarily confidential; signing proves integrity, whereas encryption provides confidentiality.

Authorisation can be implemented through:

• Role-based access control (RBAC): permissions are assigned to roles.
• Attribute-based access control (ABAC): decisions use attributes of the subject, resource, action, and environment.
• Relationship-based access control: permissions depend on relationships such as owner, member, or delegated representative.

For example, an invoice policy may require that the requester is authenticated, belongs to the invoice’s organisation, and has the view_invoice permission. This rule should be enforced in a service or policy layer and tested directly, not inferred from a user-interface condition.

5. Input, Output and Application-Logic Security

All external input is untrusted, including request bodies, query parameters, headers, uploaded files, webhooks, and data returned by third parties. Validation should be based on an allow-list and the expected type, length, range, format, and business meaning. Validation is not a substitute for safe database APIs or output encoding.

Injection occurs when untrusted data changes the meaning of an interpreter command. Parameterised queries or a carefully used object-relational mapper prevent SQL injection by separating data from query structure. Command execution, template rendering, directory paths, and expression languages require analogous controls.

Cross-site scripting (XSS) occurs when attacker-controlled content is interpreted as executable browser code. Context-sensitive output encoding, safe templating, content security policy, and avoiding unsafe HTML construction are central defences. Sanitisation is needed when a legitimate feature permits restricted markup.

Cross-site request forgery (CSRF) exploits a browser’s automatic credential submission to cause an unwanted state-changing action. Same-site cookies, CSRF tokens, origin checks, and suitable API design reduce the threat. CSRF analysis must reflect the selected authentication mechanism and browser behaviour.

Business-logic vulnerabilities are often more serious than syntactic bugs. Examples include applying a discount twice, approving one’s own request, bypassing a workflow step, reusing a one-time token, or changing a price between display and purchase. Security tests must therefore include abuse cases and invariant checks, not only malformed input.

File upload features need strict size and type limits, content inspection where appropriate, safe randomised names, storage outside executable web roots, malware scanning for relevant contexts, and authorisation checks on download. Server-side resource limits help reduce denial-of-service risks from large files, expensive searches, or uncontrolled pagination.

6. Data Protection and Privacy Engineering

Privacy is not identical to secrecy. An organisation may misuse data even when no attacker obtains it. Privacy engineering embeds legal, ethical, and user-control considerations into system design.

Widely recognised privacy principles include:

• lawfulness, fairness, and transparency;
• purpose limitation;
• data minimisation;
• accuracy;
• storage limitation;
• integrity and confidentiality; and
• accountability.

The exact legal duties vary by jurisdiction and sector. A project team must identify applicable law, contractual duties, international transfers, children’s data requirements, health or financial-data rules, and organisational policies rather than assuming that one regulation applies universally.

A data inventory records what data is collected, its source, purpose, classification, location, recipients, retention period, and deletion process. A privacy impact assessment examines necessity, proportionality, risks to individuals, mitigations, and residual risk for processing likely to create significant effects.

Privacy-enhancing techniques include pseudonymisation, aggregation, access segmentation, encryption, tokenisation, selective disclosure, and privacy-preserving analytics. Pseudonymisation reduces direct identification but does not make data anonymous if re-identification remains reasonably possible. Anonymisation is a stronger claim that must be assessed against available auxiliary information.

Encryption should be applied in transit and, where appropriate, at rest. Key management is more important than merely selecting an algorithm: keys should be generated securely, access-controlled, rotated according to risk, backed up safely, and separated from encrypted data where feasible. Secrets belong in a managed secret store or protected deployment mechanism, not in source control, client bundles, or log files.

Retention must be operational. A statement such as “data is retained as long as necessary” should be translated into schedules, deletion jobs, archival rules, legal holds, backup treatment, and verification. Data minimisation also applies to telemetry: collect the least detailed event that supports a legitimate operational purpose.

7. Secure Development, Testing and Operations

Security is a lifecycle responsibility. During planning, teams should define security and privacy requirements, abuse cases, classification, regulatory constraints, and measurable acceptance criteria. During design, they should perform threat modelling and architectural review. During implementation, developers should use approved libraries, secure coding standards, peer review, and automated checks. During testing, they should combine static analysis, dependency scanning, dynamic testing, API tests, authorisation tests, and targeted penetration testing.

Security tools produce findings, not certainty. A scanner may report a false positive, miss a business-logic flaw, or identify a technically real issue with low practical risk. Findings should be triaged by exploitability, affected assets, exposure, compensating controls, and remediation cost. Exceptions require documented approval, expiry, and ownership.

Dependency management is a security control. Projects should pin or constrain versions appropriately, generate a software bill of materials where required, monitor advisories, remove unused packages, verify package provenance, and review transitive dependencies. Build pipelines should protect source repositories, signing credentials, deployment tokens, and artifact stores.

Production systems need secure configuration, network segmentation where justified, vulnerability management, backups, restoration tests, monitoring, alerting, and incident playbooks. Logs should support detection and investigation without recording passwords, access tokens, payment secrets, or unnecessary personal data. A useful security event generally records a timestamp, actor or service identity, action, target, outcome, and correlation identifier, with access controlled and retention justified.

8. Incident Response and Resilience

No realistic system has zero risk. Incident response should therefore be planned before an incident. A common lifecycle is preparation; detection and analysis; containment; eradication; recovery; and lessons learned. The sequence is iterative: new evidence may require returning to analysis or containment.

The response team should define technical roles, escalation paths, legal and communications contacts, evidence-preservation procedures, and notification criteria. Containment must balance stopping harm with preserving evidence and maintaining essential services. Recovery should include credential rotation, integrity checks, restoration from trusted backups, heightened monitoring, and validation that the original weakness is closed.

Post-incident analysis should focus on contributing conditions rather than blaming an individual. Questions include: Which control failed? Which warning was missed? Were responsibilities unclear? Did the architecture make safe operation difficult? Were users or regulators entitled to notification? Corrective actions should have owners and deadlines.

9. Responsible Computing

Responsible computing recognises that technical systems distribute benefits and burdens. A responsible project considers:

• Fairness: whether outcomes systematically disadvantage groups.
• Explainability: whether affected users can understand relevant decisions.
• Human oversight: whether people can review, contest, or override consequential outcomes.
• Accessibility: whether people with disabilities can perceive, operate, and understand the service.
• Safety: whether foreseeable misuse can cause physical, financial, psychological, or social harm.
• Sustainability: whether design choices create avoidable energy, hardware, or e-waste impacts.
• Professional accountability: whether decisions, evidence, and limitations are documented.

AI features require additional discipline. Training and evaluation data may encode historical bias, omit populations, or contain personal information. Accuracy averages can hide unequal error rates. A model should not be deployed solely because it performs well on an aggregate test set. Teams should define the decision’s purpose, affected groups, unacceptable errors, review process, data provenance, monitoring, and decommissioning conditions. Generative AI output must be treated as untrusted content requiring verification, privacy review, and protection against prompt injection or data leakage.

Accessibility is both an ethical and often a legal concern. Semantic HTML, keyboard operation, adequate contrast, labelled controls, meaningful errors, captions, scalable text, and screen-reader testing are practical minimums. Accessibility testing should involve automated checks and human evaluation.

10. Applied Case: Illustrative University Clinic Portal

Background

Consider an illustrative project in which a university team builds a clinic portal. Students book appointments, clinicians record notes, and administrators produce operational reports. The system processes identity information, appointment history, symptoms, prescriptions, and contact details.

Problem

The initial prototype stores all fields in one database, uses a shared administrator account, places an API key in the frontend bundle, and permits users to request /appointments/{id} without an object-level ownership check. Logs contain request bodies, including symptoms. The team believes that HTTPS and login protect the system.

Analysis

The assets include health information, identities, clinician notes, appointment availability, and administrative credentials. Threat modelling identifies unauthorised record access, insider misuse, credential theft, accidental disclosure through logs, ransomware or service disruption, and inappropriate administrative reporting. The risk is high because the data is sensitive, the endpoint is externally reachable, and the prototype lacks effective authorisation.

Approach and Solution

The team first classifies data and creates a data inventory. It separates clinical records from general appointment data, limits each role’s fields, and establishes retention and deletion rules subject to applicable health-record obligations. Authentication is integrated with the institution’s identity provider and multifactor authentication is required for privileged users. Clinician and administrator permissions are distinct.

The API implements a policy such as: a student may view only that student’s appointments; a clinician may view records for assigned patients; and an administrator may access operational aggregates but not clinical notes unless explicitly authorised. Every request performs a server-side object-level check. Parameterised queries, schema validation, output encoding, rate limits, safe file handling, and secure cookies are added.

The API key is removed from the client and rotated. Secrets move to a managed secret store. Logs record event metadata rather than symptom text or tokens. Encryption is enabled in transit and at rest, backups are tested, and an incident playbook is approved. Security tests include attempts to alter appointment identifiers, escalate roles, replay tokens, submit oversized files, and infer sensitive data from reports.

Outcome

The redesigned portal reduces unnecessary exposure and produces evidence for review. It does not eliminate risk: authorised users could still misuse access, a compromised identity provider could affect many accounts, and privacy obligations may change. Continuous monitoring, access reviews, user education, and periodic assessment remain necessary.

Learning Points

The case demonstrates that security depends on authorisation and data governance as much as authentication and encryption. Privacy is improved by collecting and exposing less data. Responsible computing requires attention to patients, students, clinicians, administrators, and people who may be affected by incorrect or inaccessible services.

11. Contemporary Developments and Critical Limitations

Modern teams increasingly use zero-trust principles, passkeys, confidential-computing capabilities, automated supply-chain attestations, and privacy-preserving analytics. These technologies can improve assurance but do not replace sound requirements or governance. Zero trust does not mean “trust nothing” in an absolute sense; it means access decisions should be explicit, continuously evaluated where appropriate, and not based solely on network location.

Automation also creates limitations. Static tools cannot fully understand business context. Machine-learning detection may generate unequal false positives. Encryption can complicate lawful discovery and recovery. Strict retention controls may conflict with legitimate audit or safety requirements. More logging can improve detection while increasing privacy risk. Every control therefore involves trade-offs that should be documented and reviewed.

A mature project uses proportionality: stronger controls are justified for more sensitive assets, higher-impact actions, greater exposure, and less reversible harm. Decisions should be evidence-based, tested with representative scenarios, and revisited when the application, threat environment, law, or user population changes.

Best-Practice Checklist for Full-Stack Project–I

• Model assets, actors, flows, and trust boundaries before implementation.
• Treat every client-controlled value as untrusted.
• Enforce authentication and object-level authorisation on the server.
• Use secure password hashing, multifactor authentication for high-risk accounts, and protected session handling.
• Use parameterised queries, allow-list validation, context-aware output encoding, and safe file controls.
• Minimise personal data and document purpose, retention, access, and deletion.
• Protect secrets and keys throughout development, CI/CD, and production.
• Scan dependencies and review findings rather than accepting tool output uncritically.
• Log security-relevant events without unnecessary personal data or credentials.
• Test abuse cases, recovery procedures, accessibility, and privacy assumptions.
• Prepare incident contacts, escalation procedures, backups, and notification decisions.
• Document ethical trade-offs, limitations, assumptions, and residual risks.

Chapter Summary

Application security is a lifecycle and architectural discipline covering confidentiality, integrity, availability, authenticity, and accountability. Threat modelling helps teams identify assets, trust boundaries, misuse cases, and prioritised controls. Secure full-stack systems enforce least privilege, deny-by-default access, complete mediation, server-side authorisation, safe input handling, protected sessions, secure dependencies, and operational monitoring.

Privacy requires more than encryption. Purpose limitation, data minimisation, transparency, retention control, access governance, privacy impact assessment, and responsible key management reduce risks to individuals. Responsible computing extends the analysis to fairness, accessibility, explainability, human oversight, sustainability, and professional accountability. Incident response, testing, and continuous review are necessary because no control is perfect and system conditions change.

Key Terms

Application security: Protection of software, services, and their data from misuse and attack.

Authentication: Verification of an identity claim.

Authorisation: Determination of what an authenticated subject may do.

CIA triad: Confidentiality, integrity, and availability.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited.

Exploit: A method of taking advantage of a vulnerability.

Risk: The possibility of harm arising from threats and weaknesses.

Asset: Something valuable that requires protection.

Trust boundary: A point where security assumptions change.

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

RBAC: Access control based on assigned roles.

ABAC: Access control based on subject, resource, action, and environmental attributes.

Injection: Manipulation of an interpreter through unsafe external data.

XSS: Execution of attacker-controlled script in a user’s browser.

CSRF: Unauthorised state-changing action caused through a victim’s browser.

Pseudonymisation: Replacing identifying attributes while retaining a re-identification possibility.

Privacy impact assessment: Structured analysis of privacy risks and mitigations.

Incident response: Organised detection, containment, recovery, and learning after a security event.

Responsible computing: Development and operation that address technical, ethical, social, legal, and environmental effects.

Review Questions

5 Short Answer Questions

1. Distinguish authentication from authorisation.
2. What is a trust boundary? Give one full-stack example.
3. State the three elements of the CIA triad.
4. Why should secrets not be placed in frontend code?
5. What is the purpose of data minimisation?

5 Long Answer Questions

1. Explain how threat modelling can be applied to a browser–API–database architecture.
2. Discuss least privilege, deny by default, complete mediation, and defence in depth.
3. Explain the principal controls for preventing injection, XSS, CSRF, and insecure file uploads.
4. Analyse how privacy engineering differs from conventional confidentiality protection.
5. Describe the incident-response lifecycle and the role of post-incident learning.

3 Analytical / Application Questions

1. A student can change an appointment identifier in a URL and view another student’s record. Analyse the vulnerability, affected security properties, likely causes, and remediation tests.
2. Design a privacy and responsible-computing assessment for an AI system that prioritises student support requests. Identify data, affected groups, possible harms, human oversight, and monitoring requirements.
3. A team proposes logging complete request bodies to improve debugging. Evaluate the proposal and recommend a logging design that balances detection, troubleshooting, confidentiality, and retention.

Multiple Choice Questions with Answers

Question 1

Which control must be enforced by the server even when a client interface hides an administrative button?

A. Object-level authorisation

B. Screen-reader support

C. Image compression

D. Client-side routing

Correct Answer: A. Object-level authorisation

Question 2

What does least privilege require?

A. All users receive the same broad permissions

B. Each subject receives only the permissions needed for its tasks

C. Administrators share one account

D. Permissions are never reviewed

Correct Answer: B. Each subject receives only the permissions needed for its tasks

Question 3

Which practice most directly prevents SQL injection?

A. Increasing browser cache duration

B. Using parameterised queries

C. Disabling application logs

D. Adding more database tables

Correct Answer: B. Using parameterised queries

Question 4

Which statement about signed tokens is correct?

A. A signature automatically makes token contents confidential

B. A signature helps protect integrity and authenticity

C. A signature eliminates the need for expiry

D. A signature prevents all credential theft

Correct Answer: B. A signature helps protect integrity and authenticity

Question 5

Which privacy principle limits collection to information needed for a legitimate purpose?

A. Data minimisation

B. Non-repudiation

C. Availability

D. Separation of duties

Correct Answer: A. Data minimisation

Question 6

Which log entry is generally most appropriate for a security event?

A. A user’s password and access token

B. The complete clinical request body

C. Timestamp, actor, action, target, and outcome

D. An unverified personal opinion

Correct Answer: C. Timestamp, actor, action, target, and outcome

Question 7

What is a primary purpose of threat modelling?

A. To guarantee that no vulnerability can ever exist

B. To identify threats and select proportionate controls before or during development

C. To replace all security testing

D. To optimise image loading only

Correct Answer: B. To identify threats and select proportionate controls before or during development

Question 8

Which example is an authorisation failure?

A. A user enters an incorrect password

B. A database query runs slowly

C. A customer accesses another customer’s invoice by changing its identifier

D. A page uses large images

Correct Answer: C. A customer accesses another customer’s invoice by changing its identifier

Question 9

Which activity belongs to incident recovery?

A. Rotating compromised credentials and validating restored services

B. Adding unreviewed dependencies

C. Publishing secret keys

D. Disabling all backups

Correct Answer: A. Rotating compromised credentials and validating restored services

Question 10

Why is pseudonymised data not automatically anonymous?

A. Pseudonyms always reveal names directly

B. Re-identification may remain possible using additional information

C. Pseudonymisation prevents encryption

D. Pseudonymisation applies only to passwords

Correct Answer: B. Re-identification may remain possible using additional information