◇ OpenCyber Academy
Engineering · Chapter 9 · English

Chapter 9 — Programming II

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 9 — Programming II

Lesson map

Lesson 09 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Separating identifiers"]
  N2["9.2 Access checks in code"]
  N3["9.3 Property-based testing"]
  N4["9.4 Error handling"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Separating identifiers"]
  N2["9.2 Access checks in code"]
  N3["9.3 Property-based testing"]
  N4["9.4 Error handling"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX025"]

[Learning outcomes]
    |
    v
[9.1 Separating identifiers]
    |
    v
[9.2 Access checks in code]
    |
    v
[9.3 Property-based testing]
    |
    v
[9.4 Error handling]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) design data structures that separate identifiers; (2) apply access checks in code; (3) write tests for privacy properties.

9.1 Separating identifiers

In Programming II Zara designs Pellmore's patient record as two linked structures: an identity table with name and contact details, and a clinical table keyed by an internal identifier. Most services need only the clinical part or only the identity part, rarely both. Separating them in code makes it easy to give each service only what it needs. She recognises this as an implementation of data protection by design, where the structure of the software itself limits exposure rather than relying on every developer to remember a rule.

9.2 Access checks in code

Zara writes a function that every service must call before reading a record. It checks the caller's role and the purpose of the request against a policy table. A receptionist can read appointment times but not clinical notes; a clinician can read notes only for patients booked with them. The function logs each access with the purpose. She tests that a call without a purpose fails. Prof. Holm points out that putting checks in one place prevents inconsistent rules, which are a common source of over-broad access in real systems.

9.3 Property-based testing

Zara learns property-based testing, where a tool generates many random inputs to test general rules. She writes properties such as no function returning a clinical record to a receptionist role, and no export function ever including the identity table. The tool finds one bug: an export written by a classmate joins both tables for convenience. Fixing it removes a path by which full records could leave the system. She realises that testing privacy properties generally is more powerful than checking a few hand-picked examples.

9.4 Error handling

Error messages can leak data. Zara finds that a failed booking returns an error containing the patient's full record for debugging. She changes errors to return a reference code and logs details internally under access control. She also ensures that exceptions do not print stack traces with variable values to users. These small changes reduce accidental disclosure, which often happens through ordinary software paths such as errors rather than through dramatic attacks, and they make the system more professional in the eyes of patients and auditors.

Worked example

Zara separates identity from clinical data, centralises purpose-based access checks, finds an export bug with property-based tests and removes data from error messages.

Synthetic case. The code and patients are synthetic.

Errors and limits

Central checks become a single point of failure; they need their own tests and monitoring.

Exercises

Synthesis

Chapter 9 encodes privacy in programs. Chapter 10 considers ethics and safety.

Continue studying — chapter 09 of 50

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →