Secure, Ethical, and AI-Assisted Programming

Introduction

Programming is not only the activity of making software produce correct results. Professional programmers are also responsible for protecting users, respecting rights, reducing harm, and communicating honestly about how software was produced. A program can be functionally correct yet still be unsafe, discriminatory, inaccessible, legally problematic, or unfair to the people affected by it.

This chapter presents a practical foundation for secure and ethical programming in Java and Python. It focuses on input validation, safe data handling, privacy, intellectual property, accessibility, fairness, and responsible use of generative artificial intelligence (AI). These concerns are connected: weak validation can expose private data; poor access control can create unfair outcomes; copied code can introduce vulnerabilities; and unverified AI-generated code can appear plausible while being incorrect or unsafe.

Security and ethics are not final checks performed immediately before deployment. They are design responsibilities that should influence requirements, data collection, implementation, testing, deployment, and maintenance.

Learning Objectives

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

1. Explain common secure-coding principles and apply basic input validation.
2. Distinguish validation, sanitization, encoding, authentication, and authorization.
3. Handle personal and sensitive data responsibly.
4. Recognize important intellectual-property, licensing, accessibility, and fairness issues.
5. Use generative AI as an assistant while verifying its output and protecting confidential information.
6. Analyse a programming scenario and recommend proportionate safeguards.

1. Security, Ethics, and Professional Responsibility

Security protects the confidentiality, integrity, and availability of information and systems. Confidentiality means that data is disclosed only to authorized parties. Integrity means that data and programs are not altered improperly. Availability means that authorized users can access services when needed. These three goals are often called the CIA triad.

Ethics concerns the responsible use of knowledge and technology. Ethical programming asks questions such as:

• Who may be helped or harmed by this system?
• Is the data collection necessary and transparent?
• Can users understand and challenge important decisions?
• Does the system work for people with disabilities?
• Are the rights of creators and data subjects respected?

Security and ethics overlap but are not identical. A system may securely store data that it had no ethical justification to collect. Conversely, a system may be designed with good intentions but expose users through weak security.

A useful professional principle is least privilege: each user, process, or component should receive only the access required for its legitimate task. Related principles include:

• Secure defaults: the initial configuration should be reasonably safe.
• Defense in depth: use several independent protective layers.
• Fail securely: when an error occurs, do not reveal secrets or grant extra access.
• Economy of mechanism: simpler security mechanisms are easier to understand and test.
• Separation of duties: important actions should not depend on one unchecked individual or component.
• Accountability: maintain appropriate records so significant actions can be investigated.

No principle eliminates all risk. The objective is to identify, reduce, monitor, and communicate risk.

2. Input Validation and Safe Program Flow

Any data received from a user, file, network, environment variable, database, or external service should be treated as untrusted until its suitability for a specific operation has been established. “Untrusted” does not mean that the sender is dishonest; it means that the program has not yet verified the data.

Validation, sanitization, and encoding

These terms describe different operations:

• Validation checks whether data satisfies expected rules. For example, an examination mark may be required to be an integer from 0 through 100.
• Sanitization removes or transforms unwanted content. It can be useful, but it may also conceal invalid input or alter legitimate data.
• Encoding represents data safely in a particular context, such as HTML, a URL, or a database command. Correct context-specific encoding helps prevent interpretation as executable syntax.

Validation should be based on an allowlist whenever possible. An allowlist specifies what is permitted; a denylist attempts to list everything forbidden and is usually incomplete.

A robust validation process normally includes:

1. Identify the expected type, range, length, format, and meaning.
2. Parse the value using a suitable library rather than relying only on string operations.
3. Reject values that fail validation.
4. Produce an error that helps the legitimate user without revealing internal details.
5. Validate again at trust boundaries, such as an API or service boundary.
6. Test boundary, empty, malformed, oversized, and unexpected values.

For example, a Python function can validate an age as follows:

def parse_age(text):
    try:
        age = int(text)
    except ValueError:
        raise ValueError("Age must be a whole number")

    if not 0 <= age <= 130:
        raise ValueError("Age must be between 0 and 130")
    return age

The range is a domain assumption, not a universal truth. A real application should define its business rule explicitly and consider whether an age of 130 is meaningful for its context.

In Java, parsing and validation can be separated:

static int parseAge(String text) {
    final int age;
    try {
        age = Integer.parseInt(text);
    } catch (NumberFormatException ex) {
        throw new IllegalArgumentException("Age must be a whole number");
    }
    if (age < 0 || age > 130) {
        throw new IllegalArgumentException("Age is outside the permitted range");
    }
    return age;
}

Validation is not a substitute for authorization. A value can be valid in form but still not be permitted for the current user. For example, a valid account number does not prove that the requester may view that account.

Injection and parameterized operations

Injection occurs when data is accidentally interpreted as program instructions. SQL injection is a common example. Building a database command by concatenating user input is unsafe:

# Unsafe pattern: do not use
query = "SELECT * FROM users WHERE name = '" + name + "'"

The safer approach is a parameterized query, where the database driver treats the value as data:

cursor.execute(
    "SELECT id, name FROM users WHERE name = ?",
    (name,)
)

The exact placeholder syntax depends on the database library. Similar principles apply to shell commands, HTML, log files, template engines, and directory paths. Avoid passing untrusted strings to an operating-system shell. Use APIs that accept argument lists and apply context-appropriate output encoding.

Errors and logging

Errors should be useful to developers but restrained in user-facing messages. A public error should not expose passwords, access tokens, database connection strings, internal file paths, or full stack traces. Logs should support investigation while respecting privacy. Do not log sensitive values merely because logging is convenient.

3. Authentication, Authorization, and Data Protection

Authentication answers “Who are you?” Authorization answers “What are you allowed to do?” They are separate controls. A system that authenticates a user but fails to check authorization may allow one user to access another user’s records.

Passwords should not be stored as plain text or with reversible encryption. They should be processed using a password-hashing function designed for this purpose, with a unique salt and an appropriate work factor. Application developers should normally use a maintained library rather than implementing password hashing themselves. Multi-factor authentication can reduce the consequences of password compromise.

Sensitive operations should use secure transport, such as correctly configured HTTPS. Secrets should not be embedded in source code or committed to a public repository. Use protected configuration, secret-management facilities, and restricted permissions. Rotate exposed credentials and remove them from future versions, while remembering that deleting a file does not necessarily remove it from repository history.

Privacy by design

Privacy is broader than secrecy. It includes appropriate collection, use, retention, sharing, and deletion of information about identifiable people. Personal data may include names, contact details, identifiers, location, online identifiers, health information, financial information, or combinations of data that permit identification.

A practical privacy process asks:

• What data is necessary for the stated purpose?
• What is the lawful or legitimate basis for collecting it in the relevant jurisdiction?
• How will users be informed?
• Who can access it, and why?
• How long will it be retained?
• Can it be corrected or deleted where applicable?
• What happens if there is a breach?

Important techniques include data minimization, purpose limitation, access control, retention schedules, pseudonymization, and encryption. Pseudonymized data may still be re-identified when combined with other information; it should not automatically be treated as anonymous. Anonymization is a stronger claim and can be difficult to achieve.

Privacy law varies by jurisdiction. Regulations such as the European Union General Data Protection Regulation and other national or sector-specific laws may impose requirements concerning transparency, rights, security, breach response, and transfers. Programmers should consult organizational policy and qualified legal or privacy professionals rather than assuming that a general rule applies everywhere.

4. Intellectual Property and Open-Source Software

Software may involve copyright, patents, trademarks, database rights, contractual restrictions, and trade secrets. Copyright commonly protects the expression of code, documentation, images, and other creative works, while ideas and general algorithms may receive different treatment depending on jurisdiction. A programmer must not assume that material found online is free to copy.

A software license grants permissions subject to conditions. Examples include attribution, preservation of license notices, disclosure of source for derivative works, or restrictions on certain uses. Open-source does not mean “without rules.” Before incorporating a dependency, examine its license, version, maintenance status, known vulnerabilities, and compatibility with the project’s distribution model.

Good practice includes:

• keeping a dependency inventory;
• preserving required copyright and license notices;
• avoiding unapproved copying of proprietary code;
• recording the source and version of third-party components;
• checking whether generated code resembles protected or confidential material;
• respecting trademarks and organizational policies.

A citation or attribution does not automatically grant permission. Attribution and permission are separate questions.

5. Accessibility and Inclusive Design

Accessibility means that people with varied abilities can perceive, understand, navigate, and operate a system. It is not merely a compliance exercise. Accessible design often improves usability for everyone, including users on small screens, in noisy environments, with temporary injuries, or with limited bandwidth.

For command-line programs, accessibility may include clear text, predictable prompts, meaningful error messages, keyboard operation, and compatibility with assistive technologies. For graphical or web systems, consider semantic structure, keyboard navigation, visible focus, sufficient contrast, scalable text, alternatives for non-text content, captions, and labels that are associated with controls.

Do not communicate essential information by colour alone. A red field without an accompanying message may be unusable for some people. Avoid rapidly flashing content and allow users to control timing where appropriate. Test with automated tools, manual keyboard use, screen readers, and people with relevant lived experience when possible.

Accessibility should be included in requirements and acceptance tests. Retrofitting it after implementation is often more costly and less effective.

6. Fairness, Bias, and Human Impact

Software can reproduce or amplify unfairness even when its source code contains no explicit discriminatory rule. Bias can enter through historical data, missing groups, inappropriate labels, proxy variables, measurement choices, model objectives, or unequal access to the system.

A basic fairness review asks:

1. Which people are affected, and which groups may be vulnerable?
2. Is the data representative of the intended population?
3. Are outcome errors distributed unevenly?
4. Could a seemingly neutral variable act as a proxy for a protected characteristic?
5. Can people obtain an explanation, correction, or human review?
6. What monitoring will detect changes after deployment?

Fairness criteria can conflict. For example, equal error rates across groups and equal positive prediction rates may not both be achievable when groups have different base rates. Therefore, fairness is a contextual and governance question, not a single universal metric. Technical measurements should support, not replace, legal, social, and domain-specific judgment.

High-impact decisions should generally include meaningful human oversight, documentation of limitations, an appeal route, and careful monitoring. A human who merely approves an automated result without understanding or authority to challenge it is not meaningful oversight.

7. Responsible Use of Generative AI

Generative AI systems can produce explanations, code, tests, documentation, and design suggestions. They can accelerate learning and prototyping, but they do not guarantee truth, security, originality, or suitability. They may generate code that does not compile, use obsolete libraries, contain vulnerabilities, invent citations, reproduce biased assumptions, or mishandle edge cases.

A responsible workflow

A disciplined workflow includes the following stages:

Define the task. State the language version, framework, input assumptions, security constraints, performance needs, and required output. Vague prompts encourage vague solutions.

Protect information. Do not submit passwords, private keys, personal records, confidential source code, unpublished research, or proprietary business information to a public or unapproved AI service. De-identify examples and use approved enterprise tools when available.

Request reasoning-supporting artifacts. Ask for assumptions, tests, limitations, threat considerations, and explanations. This does not make the output correct, but it makes review easier.

Verify independently. Compile and run code in a controlled environment. Read every line. Check dependencies and licenses. Test normal, boundary, invalid, adversarial, and accessibility-related cases. Compare important claims with authoritative documentation.

Review security and quality. Check authentication, authorization, validation, error handling, secret exposure, injection risks, concurrency, resource limits, and data retention. Static analysis and dependency scanning can assist but cannot replace human review.

Document use and attribution. Follow institutional and workplace policy. Record substantial AI assistance where required. Do not claim personal authorship of work that policy requires you to disclose. Attribution is not a substitute for checking correctness or obtaining permission.

Maintain accountability. A human developer or organization remains responsible for deployed software. “The model generated it” is not a defense for preventable harm.

AI output should be treated as an untrusted draft, much like code copied from an unknown online source. A particularly important risk is automation bias, the tendency to accept a confident-looking answer without sufficient scrutiny.

8. A Practical Secure Development Process

Security and ethics are strongest when integrated throughout the software life cycle:

Threat modelling can begin with a simple question: what assets need protection, from whom, and through which paths could they be attacked or misused? The answer should lead to controls that are proportionate to the risk. Security reviews should not focus only on malicious attackers; accidental disclosure, misuse by authorized users, service failure, and unfair outcomes also matter.

9. Illustrative Case: A Student-Bursary Application

Background

A college develops a Python web application that helps students apply for a bursary. Applicants enter identity details, household income, disability-related information, and supporting documents. A scoring component recommends whether an application should receive priority.

Problem

An early prototype has several weaknesses. It stores uploaded files under predictable names, logs full form submissions, uses a machine-generated scoring script without documentation, and displays different messages depending on whether an email address exists. A developer also copied a data-processing utility from an online repository without recording its license.

Analysis

The predictable filenames may permit unauthorized document access. Full logs create unnecessary privacy exposure. Different account-existence messages can enable account enumeration. The scoring component may encode historical disadvantage or use variables that act as proxies for protected characteristics. The unrecorded utility creates intellectual-property and maintenance risk. Because the application affects access to financial support, errors and unfair outcomes have serious consequences.

Approach and solution

The team first maps data flows and classifies information. It minimizes collection, defines a retention schedule, restricts access by role, encrypts transport and appropriately protected storage, and generates non-predictable object identifiers. Uploaded files are checked for permitted type, size, and safe handling; they are stored outside directly executable web locations. Logs record event identifiers and operational facts rather than full personal submissions.

The login flow uses a consistent response for unknown and known email addresses, rate limiting, secure password handling, and multi-factor authentication for staff. Authorization is checked for every document request rather than inferred from a URL.

The scoring component is documented as decision support rather than an unquestionable decision maker. The college checks data quality and group impacts, provides human review and an appeal process, and monitors outcomes. Applicants receive an understandable explanation of relevant factors and information about how to request correction.

The team audits the utility’s license, replaces it if its terms are incompatible, and records approved dependencies. AI is used to suggest test cases, but all generated code is reviewed, tested, and scanned before use. A privacy notice and accessibility testing plan are added to the release criteria.

Outcome

The revised design reduces unnecessary exposure, makes access decisions auditable, improves accessibility, and creates a mechanism for correcting both data and decisions. It does not eliminate all risk. Continuous monitoring, staff training, dependency updates, and periodic fairness review remain necessary.

Learning points

1. Privacy and security requirements should be designed before implementation.
2. Valid input is not necessarily authorized input.
3. High-impact automated recommendations require explanation, oversight, and appeal.
4. Dependencies and AI-generated code require the same professional review as manually written code.
5. Ethical quality includes accessibility, fairness, and respect for creators as well as technical protection.

Challenges and Limitations

No checklist can guarantee secure or ethical software. Threats evolve, libraries change, and a system’s social context may shift. Encryption does not solve excessive collection; validation does not solve broken authorization; an accessibility statement does not prove actual usability; and a fairness metric may conceal harms that were not measured.

Security controls can also introduce usability costs. Strong authentication may inconvenience users, monitoring may affect privacy, and extensive review may delay release. These are reasons to design proportionate controls and explain trade-offs, not reasons to abandon responsibility. When risk is uncertain, teams should document assumptions, seek specialist advice, test with affected users, and prefer reversible decisions.

Best-Practice Checklist

Before releasing a Java or Python program, ask:

• Are all external inputs parsed, constrained, and validated?
• Are database and system operations parameterized rather than constructed by concatenation?
• Are authentication and authorization implemented separately?
• Are secrets excluded from source code, logs, and error messages?
• Is personal data minimized, protected, retained only as needed, and handled transparently?
• Are third-party licenses and vulnerabilities reviewed?
• Can users with disabilities operate and understand the system?
• Have possible bias, unequal error, and appeal processes been considered?
• Has AI-generated material been tested, reviewed, and appropriately disclosed?
• Are failures, incidents, updates, and ownership responsibilities defined?

Chapter Summary

Secure, ethical, and AI-assisted programming requires more than producing code that works on ordinary input. Programmers must validate data, use parameterized operations, separate authentication from authorization, protect secrets, and design for failure. Privacy requires minimizing collection and controlling access, use, retention, and disclosure. Intellectual-property obligations apply to copied code, dependencies, generated material, and documentation. Accessibility and fairness must be considered from requirements through testing and operation.

Generative AI can support programming, but its output is an untrusted draft. Responsible use requires protecting confidential information, stating constraints, verifying code and claims, checking licenses and security, testing edge cases, and preserving human accountability. A secure development life cycle integrates these practices into requirements, design, implementation, testing, deployment, and maintenance.

Key Terms

Authentication: Verification of a user or system identity.

Authorization: Determination of which actions or resources an authenticated identity may access.

Allowlist: An explicit set of accepted values, formats, or actions.

Data minimization: Collection and retention of only the data necessary for a defined purpose.

Defense in depth: Use of multiple independent protective controls.

Encoding: Representing data safely for a particular context.

Fairness: The context-dependent requirement that systems do not impose unjustified unequal treatment or impact.

Input validation: Checking whether data satisfies specified type, range, format, and meaning requirements.

Least privilege: Granting only the access required for a legitimate task.

Pseudonymization: Replacing direct identifiers while recognizing that re-identification may remain possible.

Sanitization: Transforming or removing unwanted content from data.

Secure default: An initial configuration that favors protection rather than openness.

Security triad: Confidentiality, integrity, and availability.

Threat modelling: Structured identification of assets, threats, attack paths, and controls.

Transparency: Providing understandable information about data use and significant system behavior.

Validation boundary: A point where data enters a component or trust domain and must be checked.

Vulnerability: A weakness that can be exploited or misused.

Automation bias: Uncritical reliance on an automated or AI-generated result.

Review Questions

Short Answer Questions

1. Distinguish input validation from encoding.
2. Why should authentication and authorization be treated as separate controls?
3. State two principles of privacy by design.
4. Why is open-source software not necessarily free of obligations?
5. Give two reasons AI-generated code must be independently reviewed.

Long Answer Questions

1. Explain how least privilege, defense in depth, and secure defaults contribute to secure program design.
2. Describe a responsible process for collecting, storing, using, and deleting personal data in an application.
3. Discuss how accessibility can be incorporated into requirements, implementation, and testing.
4. Explain how bias can enter a software system even when programmers do not explicitly use protected characteristics.
5. Describe the stages of a responsible generative-AI programming workflow.

Analytical / Application Questions

1. A Python program accepts a filename from a user and constructs a shell command by string concatenation. Identify the risks and propose a safer design.
2. A college uses an automated model to rank scholarship applicants, but one group receives substantially fewer recommendations. Design an investigation that considers data quality, fairness, human review, and privacy.
3. A student asks an AI service to improve a program by pasting a proprietary codebase and customer records into the prompt. Evaluate the risks and propose an alternative workflow.

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 identity.

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

C. Authentication encrypts data, while authorization validates input.

D. Authentication stores logs, while authorization deletes records.

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

Question 2

Which approach is generally safest for inserting a user-supplied value into a database query?

A. String concatenation after removing spaces

B. A denylist of special characters only

C. A parameterized query supported by the database driver

D. Converting the value to uppercase

Correct Answer: C. A parameterized query supported by the database driver

Question 3

What is the main purpose of data minimization?

A. To collect as much data as possible for future use

B. To collect and retain only data necessary for a defined purpose

C. To make all data publicly available

D. To replace authorization with encryption

Correct Answer: B. To collect and retain only data necessary for a defined purpose

Question 4

Which practice is appropriate when using generative AI to assist with programming?

A. Submit private keys so the model can diagnose authentication problems.

B. Assume generated code is secure if it looks professional.

C. Run, read, test, and independently verify generated code before use.

D. Remove all comments so AI assistance cannot be detected.

Correct Answer: C. Run, read, test, and independently verify generated code before use.

Question 5

Why is a valid account number not sufficient evidence that a requester may view an account?

A. Validation checks format or meaning, whereas authorization checks permission.

B. Account numbers cannot be validated.

C. Authorization is performed only by databases.

D. Valid values are always confidential.

Correct Answer: A. Validation checks format or meaning, whereas authorization checks permission.

Question 6

Which practice most directly supports accessibility?

A. Communicating all errors through colour alone

B. Requiring mouse input for every action

C. Providing keyboard operation and meaningful labels

D. Using rapidly flashing notifications

Correct Answer: C. Providing keyboard operation and meaningful labels

Question 7

What is pseudonymization?

A. Permanent deletion of all personal data

B. Replacing direct identifiers while recognizing re-identification may remain possible

C. Publishing personal data without names

D. Encrypting a password with a reversible key

Correct Answer: B. Replacing direct identifiers while recognizing re-identification may remain possible

Question 8

Which statement about open-source software is correct?

A. It has no licensing conditions.

B. It may be used only for educational purposes.

C. Its license may impose conditions such as attribution or source disclosure.

D. It cannot contain security vulnerabilities.

Correct Answer: C. Its license may impose conditions such as attribution or source disclosure.

Question 9

What does the principle of least privilege require?

A. Every component should have administrator access.

B. Access should be limited to what is necessary for the legitimate task.

C. Users should share one account to simplify auditing.

D. All files should be readable but not writable.

Correct Answer: B. Access should be limited to what is necessary for the legitimate task.

Question 10

Why can a human approval step fail to provide meaningful oversight of an automated decision?

A. Humans cannot use software.

B. Approval is not meaningful if the reviewer cannot understand or challenge the result.

C. Automated decisions are always legally invalid.

D. Human review prevents accessibility testing.

Correct Answer: B. Approval is not meaningful if the reviewer cannot understand or challenge the result.