Secure, Ethical and Governed Web Development

Introduction

Web applications process identities, payments, communications, health information, educational records and business data. Consequently, web development is not complete when features work; it is complete when the system protects people, respects rights, remains maintainable and can be held accountable. Security, ethics and governance are connected disciplines. A technically secure application may still be unethical if it manipulates consent, discriminates against users or misuses personal data. Conversely, a well-intentioned system may expose users through weak authentication or vulnerable dependencies.

This chapter presents a practical framework for developing responsible web applications. It focuses on common OWASP risks, identity and access management, encryption, secrets, dependency hygiene, privacy, consent, intellectual property, algorithmic fairness, data governance and responsible vulnerability disclosure.

Learning Objectives

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

1. Identify and mitigate common web application risks.
2. Design appropriate authentication and authorization controls.
3. Distinguish hashing, encryption and encoding.
4. Manage secrets and third-party dependencies safely.
5. Apply privacy, consent and data-governance principles.
6. Recognize intellectual-property and fairness concerns.
7. Prepare a responsible vulnerability-disclosure process.
8. Integrate security and ethics into a mini-project lifecycle.

Security as a Software Quality Attribute

Security is the protection of confidentiality, integrity and availability, commonly called the CIA triad.

• Confidentiality means that information is accessible only to authorized parties.
• Integrity means that information and system behaviour are not altered improperly.
• Availability means that authorized users can access services when required.

Other important properties include authenticity, accountability, privacy and non-repudiation. Security is also a risk-management activity. A risk exists when a threat can exploit a vulnerability and cause harm. Developers reduce risk through secure architecture, defensive coding, testing, monitoring and incident response.

Security should be considered throughout the software development life cycle:

A useful design principle is secure by default: the safest configuration should be the normal configuration, rather than an optional improvement.

Common Web Application Risks

The OWASP Top 10 is a widely used awareness framework for web application security. It is not a complete security standard, but it provides a practical vocabulary for reviewing systems.

Broken access control

Access control determines which authenticated or unauthenticated actor may perform an action on a resource. Broken access control occurs when a user can access another user’s records, invoke an administrative function or bypass a business rule.

Controls include:

• Check authorization on the server for every protected request.
• Deny access by default.
• Enforce object-level authorization, not merely page-level authorization.
• Avoid trusting user-supplied role or ownership fields.
• Apply least privilege.
• Test horizontal access, such as user A reading user B’s invoice, and vertical access, such as a student invoking an administrator endpoint.

Injection

Injection occurs when untrusted data is interpreted as code or commands. SQL injection is a classic example. The primary defence is parameterized queries or a properly used object-relational mapper. Input validation is useful as a supporting control but should not replace parameterization.

Unsafe conceptual code might construct a query by concatenating a username into a string. A safer design passes the username as a parameter, allowing the database driver to distinguish data from SQL syntax. Similar principles apply to operating-system commands, LDAP queries, template engines and shell scripts.

Cross-site scripting

Cross-site scripting (XSS) occurs when attacker-controlled content is executed in a victim’s browser. The main forms are stored, reflected and DOM-based XSS. Defences include context-sensitive output encoding, safe templating, input constraints, Content Security Policy and avoiding dangerous DOM operations such as inserting untrusted text with an HTML interpreter.

Validation asks whether data is acceptable; encoding asks how it must be represented safely in a particular output context. A value safe for HTML text may not be safe inside JavaScript, a URL or a CSS expression.

Cross-site request forgery

Cross-site request forgery (CSRF) tricks an authenticated browser into submitting an unwanted state-changing request. Anti-CSRF tokens, same-site cookies and re-authentication for sensitive actions are common protections. APIs using authorization headers rather than automatically transmitted cookies have a different risk profile, but authorization must still be enforced.

Identification and authentication failures

Authentication verifies identity; authorization determines permissions. Secure authentication requires strong password policies, slow adaptive password hashing, multi-factor authentication where appropriate, secure session handling and protection against credential stuffing.

Passwords should not be stored as plaintext or with fast general-purpose hashes. A password-hashing algorithm such as Argon2id, bcrypt or scrypt uses a salt and computational cost to make large-scale guessing expensive. Password reset tokens should be random, short-lived, single-use and stored or compared safely.

Cryptographic failures

Encryption protects confidentiality when correctly implemented. Use established protocols and libraries rather than designing cryptography. Transport Layer Security (TLS) protects data in transit. Authenticated encryption, such as AES-GCM or an approved modern alternative, protects stored data while also detecting tampering.

Hashing is a one-way transformation used for integrity checks and password storage; encryption is reversible with a key; encoding changes representation and provides no secrecy. Base64, for example, is encoding rather than encryption.

Keys require stronger protection than ordinary application data. They should be generated using a cryptographically secure random source, stored in a managed key system where feasible, rotated according to risk and never committed to source control.

Security misconfiguration

Examples include default passwords, verbose production error messages, unnecessary services, permissive cloud storage and missing security headers. Configuration should be versioned safely, reviewed and separated by environment. Production systems should not expose stack traces, debugging consoles or development credentials.

Vulnerable and outdated components

Modern applications depend on frameworks, packages, container images and operating-system libraries. Dependency hygiene includes maintaining an inventory, pinning or constraining versions appropriately, reviewing advisories, removing unused packages, applying updates and testing upgrades. A software bill of materials (SBOM) improves visibility into components and their versions.

Automated scanners help but do not prove safety. A package may be technically current yet unsuitable because of licensing, abandoned maintenance or insecure configuration.

Logging and monitoring failures

Logs should support detection, investigation and accountability without exposing passwords, access tokens or unnecessary personal data. Record security-relevant events such as failed logins, privilege changes and sensitive-data access. Use synchronized timestamps, controlled retention and restricted log access. Monitoring should generate actionable alerts rather than indiscriminate noise.

Identity and Access Control Architecture

A practical identity architecture separates four activities:

1. Identification: claiming an identity, such as an email address.
2. Authentication: proving control of that identity.
3. Session management: maintaining the authenticated state.
4. Authorization: deciding what the identity may do.

Role-based access control (RBAC) assigns permissions to roles such as learner, instructor and administrator. Attribute-based access control (ABAC) evaluates attributes such as department, ownership, time or device context. RBAC is simple to administer; ABAC can express more precise policies but may be harder to audit.

Authorization decisions should be centralized where practical and enforced at the API or service boundary. A front-end route guard improves user experience but is not a security control by itself.

Session cookies should be marked Secure, HttpOnly and, where appropriate, SameSite. Session identifiers should be regenerated after login or privilege changes. Logout should invalidate the server-side session or refresh token. Access tokens should have limited scope and lifetime. Refresh-token rotation and revocation reduce the consequences of theft.

Secrets Management and Dependency Hygiene

A secret is sensitive authentication or authorization material, such as an API key, database password, private key or signing key. Secrets must not be embedded in source code, client-side bundles, screenshots or ordinary configuration files committed to a repository.

A suitable approach is:

• Store secrets in a dedicated secret manager or protected deployment environment.
• Grant applications only the secrets they need.
• Separate development, testing and production credentials.
• Rotate exposed or expired secrets immediately.
• Audit access to secret stores.
• Prevent secrets from appearing in logs and error reports.

Dependency management is both a technical and governance practice. Teams should record package name, version, source, licence, maintainer status and known vulnerabilities. Lock files improve reproducibility, while update policies prevent obsolete components from accumulating. Security review should consider transitive dependencies because an application may depend indirectly on vulnerable code.

Privacy, Consent and Data Governance

Privacy is not simply secrecy. It includes appropriate collection, use, disclosure, retention and user control. A privacy-respecting application follows principles such as purpose limitation, data minimization, accuracy, storage limitation, transparency, security and accountability. Exact legal duties vary by jurisdiction; developers must consult applicable laws and organizational policy.

Before collecting data, ask:

• What purpose requires it?
• Is each field necessary?
• What is the lawful or ethical basis for collection?
• How will users be informed?
• Who may access it?
• How long will it be retained?
• How can it be corrected or deleted?
• What happens if a breach occurs?

Consent should be informed, specific, freely given and withdrawable where consent is the relevant basis. A preselected box, confusing interface or service refusal for unrelated processing may undermine meaningful consent. Privacy notices should use clear language and describe purposes, categories of data, sharing, retention and user rights.

Data governance assigns responsibility for data quality, ownership, classification, retention and access. A simple classification scheme might distinguish public, internal, confidential and highly restricted data. Classification should influence encryption, logging, access review and disposal.

Anonymization attempts to prevent re-identification, whereas pseudonymization replaces direct identifiers but may remain linkable. Removing names does not guarantee anonymity if rare combinations of attributes can identify individuals.

Intellectual Property and Open Source

Web projects use code, images, fonts, datasets, documentation and model outputs that may be protected by copyright, patents, trademarks or contractual terms. Developers must establish that they have permission to use each significant asset.

Open-source licences impose different obligations. Permissive licences commonly require attribution and preservation of notices. Reciprocal licences may require corresponding source distribution when specified conditions apply. Licence compatibility must be checked rather than assumed. “Available online” does not mean “free to copy.”

Teams should maintain an asset register recording source, licence, author, permission and required attribution. Third-party code should not be copied without understanding its licence and security implications.

Algorithmic Fairness and Responsible AI

Automated decisions can reproduce historical discrimination, encode biased proxies or disadvantage people with disabilities and limited connectivity. Fairness is context-dependent: equal error rates, equal opportunity and equal outcomes are different objectives and may conflict.

Responsible practice includes:

• Define the decision and affected populations.
• Identify protected or sensitive characteristics and plausible proxies.
• Examine data quality and representation.
• Test performance across relevant groups.
• Provide human review for high-impact decisions.
• Explain decisions at an appropriate level.
• Provide appeal and correction mechanisms.
• Monitor outcomes after deployment.

A model with high overall accuracy may perform poorly for a minority group. Therefore, aggregate metrics should not be the only evidence. Developers should also consider accessibility, language, socioeconomic effects and the possibility that an apparently neutral feature acts as a proxy for protected status.

Generative AI introduces additional risks: confidential-data leakage, fabricated content, insecure generated code, unclear authorship and overreliance on automated suggestions. AI output requires human review, testing, licence scrutiny and disclosure where organizational policy requires it.

Threat Modelling and Secure Design

Threat modelling makes security reasoning explicit. A small project can use the following process:

1. Draw the system boundary and data flows.
2. Identify assets and trust boundaries.
3. List likely threats using categories such as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
4. Estimate impact and likelihood qualitatively.
5. Select preventive, detective and corrective controls.
6. Assign owners and verify controls through tests.

Threat modelling is not a one-time document. New integrations, data types and deployment environments can change risk.

Illustrative Case Study: Campus Skills Portal

Background

A fictional college develops a portal where learners submit assignments, instructors grade them and administrators generate reports. The system stores names, email addresses, grades and feedback.

Problem

During a review, the team discovers that assignment URLs contain predictable learner identifiers. The front end hides administrator buttons, but the API does not consistently check roles. Uploaded files are displayed without adequate content controls. A cloud-service key is present in a public repository, and the portal collects phone numbers without explaining why.

Analysis

The risks include broken object-level authorization, privilege escalation, stored XSS through uploaded content, credential compromise and excessive data collection. The issue is not one coding error; it is a failure to connect architecture, governance and operations.

Approach and solution

The team first revokes and rotates the exposed key, reviews access logs and checks for misuse. It then:

• Adds server-side ownership and role checks to every assignment and grading endpoint.
• Uses opaque identifiers but does not treat them as authorization.
• Validates upload type and size, stores files outside executable paths and serves them with safe headers.
• Applies context-sensitive output encoding and a restrictive Content Security Policy.
• Moves secrets into a managed secret store.
• Removes the phone-number field unless a documented purpose is established.
• Publishes a clear privacy notice and defines retention for grades and submissions.
• Adds dependency scanning, code review and security regression tests to the delivery pipeline.
• Creates an incident and vulnerability-disclosure procedure.

Outcome

The portal reduces unauthorized access risk, limits unnecessary personal-data collection and improves operational accountability. The team also documents residual risks, including denial-of-service attacks and the need for periodic review.

Learning points

Security controls must be enforced at trusted boundaries. Privacy decisions should precede data collection. Secret rotation is an incident response activity, not merely a configuration task. A secure feature is one that remains secure under ordinary maintenance and future change.

Responsible Disclosure and Incident Response

When a vulnerability is discovered, the finder should avoid unnecessary access, data copying or service disruption. A responsible report normally includes affected component, reproduction steps, impact, evidence limited to what is necessary and a safe contact method.

Organizations should publish a security contact, acknowledge reports, assess severity, protect reporters acting in good faith where legally possible, remediate the issue and communicate appropriately. Severe incidents may require notification to regulators, customers or partners under applicable law.

A basic incident process is: prepare, detect, contain, eradicate, recover and learn. Evidence should be preserved carefully. After remediation, conduct a blameless review that identifies process and design improvements rather than focusing only on individual error.

Mini-Project: Governed Web Application

Students can build a small service such as a course-resource portal, appointment system or community marketplace. The submission should include:

• Asset and data inventory.
• Data-flow diagram and trust boundaries.
• Threat model and risk register.
• Authentication and authorization design.
• Input-validation and output-encoding examples.
• Encryption and secret-management plan.
• Dependency inventory and licence review.
• Privacy notice and consent flow.
• Retention and deletion policy.
• Accessibility and fairness review.
• Security test results and disclosure procedure.

Assessment should reward evidence, not claims. For example, a student should demonstrate that a user cannot retrieve another user’s record, that passwords are never logged, that expired sessions fail and that a revoked credential no longer works.

Challenges and Limitations

No system can eliminate all risk. Strong controls may increase cost, complexity or friction. Encryption cannot correct an authorization error; consent cannot justify collecting unnecessary data; automated scanners cannot understand every business rule; and compliance checklists cannot replace professional judgment. Small teams must prioritize high-impact assets and realistic threats while maintaining a documented improvement plan.

Security also changes over time. New vulnerabilities, regulations, dependencies, attack techniques and social expectations require continuous review. Ethical governance is similarly iterative because affected communities may identify harms that developers did not anticipate.

Chapter Summary

Secure, ethical and governed development treats security, privacy and responsibility as core engineering requirements. Developers should protect confidentiality, integrity and availability; validate inputs; encode outputs; parameterize database access; enforce authorization on the server; manage sessions securely; use established cryptography; protect secrets; and maintain dependencies.

Responsible development also requires data minimization, meaningful consent, retention controls, transparent privacy practices, licence compliance and fairness evaluation. Threat modelling, testing, monitoring and incident response provide practical mechanisms for managing uncertainty. A professional web developer therefore delivers not only working software, but software whose risks, decisions and responsibilities are understood and governed.

Key Terms

Access control: Rules determining which actors may perform actions on resources.

Authentication: Verification of a claimed identity.

Authorization: Decision about what an authenticated actor may do.

CIA triad: Confidentiality, integrity and availability.

Consent: Informed and meaningful agreement to specified processing.

CSRF: Attack that induces an authenticated browser to perform an unwanted action.

Encryption: Reversible transformation using a key to protect confidentiality.

Hashing: One-way transformation used for integrity or password protection.

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

OWASP: Organization providing widely used application-security guidance.

Pseudonymization: Replacing identifiers while retaining a possibility of re-linking.

RBAC: Access control based on assigned roles.

Secret: Sensitive credential or cryptographic material.

Threat modelling: Structured identification and treatment of security threats.

TLS: Protocol providing protected communication over a network.

XSS: Injection of attacker-controlled script into a web context.

SBOM: Inventory of software components and their versions.

Data minimization: Collecting and retaining only necessary data.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. Why is Base64 not encryption?
3. State two protections against SQL injection.
4. What is the purpose of data minimization?
5. Why should secrets not be stored in source control?

Long Answer Questions

1. Explain how secure development activities should be integrated across the software development life cycle.
2. Compare RBAC and ABAC, including situations in which each is appropriate.
3. Describe the differences among hashing, encryption and encoding, and give a web-development use for each.
4. Explain how privacy, consent and data retention should shape a student web application.
5. Discuss how dependency hygiene and responsible disclosure contribute to organizational security.

Analytical / Application Questions

1. A learner can change an assignment ID in a URL and view another learner’s submission. Diagnose the weakness, explain why hiding interface controls is insufficient and propose tests and controls.
2. A web application has 98% overall classification accuracy but substantially higher false-negative rates for one demographic group. Analyze the ethical risks and propose a review and mitigation process.
3. During deployment, a developer discovers that a production API key was committed publicly. Construct an immediate response plan and a longer-term prevention plan.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents SQL injection?

A. Parameterized queries

B. Changing the page colour

C. Disabling browser cookies

D. Adding a logo to error pages

Correct Answer: A. Parameterized queries

Question 2

Which statement correctly distinguishes authentication and authorization?

A. Authentication verifies identity; authorization determines permitted actions.

B. Authentication encrypts data; authorization compresses it.

C. Authentication is optional after login; authorization verifies identity.

D. They are identical terms.

Correct Answer: A. Authentication verifies identity; authorization determines permitted actions.

Question 3

What is the primary purpose of the HttpOnly cookie attribute?

A. To prevent client-side scripts from reading the cookie

B. To make the cookie available over unencrypted HTTP

C. To increase database capacity

D. To replace server-side authorization

Correct Answer: A. To prevent client-side scripts from reading the cookie

Question 4

Which item is encoding rather than encryption?

A. Base64

B. AES-GCM

C. TLS

D. Argon2id

Correct Answer: A. Base64

Question 5

Which practice best protects a password database?

A. Store plaintext passwords for easy recovery

B. Use a slow, salted password-hashing algorithm

C. Encode passwords with Base64

D. Place passwords in browser local storage

Correct Answer: B. Use a slow, salted password-hashing algorithm

Question 6

What does data minimization require?

A. Collecting every possibly useful field

B. Collecting and retaining only data necessary for a defined purpose

C. Keeping data forever for future analysis

D. Removing all access controls after collection

Correct Answer: B. Collecting and retaining only data necessary for a defined purpose

Question 7

Why is server-side authorization necessary when a front end hides an administrator button?

A. Users can call the API directly and bypass interface restrictions.

B. Hidden buttons automatically delete records.

C. Front ends always encrypt database traffic.

D. Server-side checks are needed only for visual design.

Correct Answer: A. Users can call the API directly and bypass interface restrictions.

Question 8

Which statement about pseudonymization is correct?

A. It always guarantees complete anonymity.

B. It replaces identifiers but data may remain linkable.

C. It is the same as password hashing.

D. It removes the need for access controls.

Correct Answer: B. It replaces identifiers but data may remain linkable.

Question 9

What should normally happen first after a production secret is publicly exposed?

A. Ignore it if no misuse is visible

B. Revoke or rotate it and investigate possible use

C. Commit a second copy to a private repository

D. Publish additional secrets for comparison

Correct Answer: B. Revoke or rotate it and investigate possible use

Question 10

Which activity is part of responsible vulnerability disclosure?

A. Copying all customer data as proof

B. Reporting reproduction steps and impact while minimizing harm

C. Publishing exploit details immediately without contacting anyone

D. Continuing unauthorized access until the issue is fixed

Correct Answer: B. Reporting reproduction steps and impact while minimizing harm