Chapter 3 — Programming I

Lesson map

Lesson 03 published. Map, example, EX007.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Processing records"]
  N2["3.2 Allow-lists over block-lists"]
  N3["3.3 Secrets out of code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX007"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Processing records"]
  N2["3.2 Allow-lists over block-lists"]
  N3["3.3 Secrets out of code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]

[Learning outcomes]
    |
    v
[3.1 Processing records]
    |
    v
[3.2 Allow-lists over block-lists]
    |
    v
[3.3 Secrets out of code]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX007]

Learning outcomes

You will (1) write simple Python programs that process records safely; (2) validate inputs with allow-lists; (3) avoid hard-coding secrets.

3.1 Processing records

Lucas's first programs read order records from synthetic CSV files and compute totals. Dr Bellini adds a security lens from the start: every input is untrusted until checked. Lucas writes functions that check each field: order identifiers must match a fixed pattern, quantities must be positive integers below a limit and postcodes must match an allowed format. Records that fail are set aside with a reason. Programming habits formed in the first year last, so the course treats validation as part of correct programming rather than an advanced security topic added later.

3.2 Allow-lists over block-lists

Lucas first tries to block dangerous characters in product names. Dr Bellini shows him that block-lists are always incomplete: there are many ways to encode dangerous input. An allow-list, describing what valid input looks like, is safer: product names may contain letters, digits, spaces and a few punctuation marks, up to sixty characters. Anything else is rejected. Lucas rewrites his checks this way and finds the code shorter and clearer. The principle applies at every scale, from a single field to firewall rules, where allowing known-good flows is safer than blocking known-bad ones.

3.3 Secrets out of code

Lucas's program needs to call a synthetic stock service with an API key. His first version writes the key in the source file. Dr Bellini explains that source code is copied, shared and often published by mistake, so keys in code leak. Lucas moves the key to an environment variable read at runtime and adds the configuration file to the ignore list of his version control system. He also learns that if a key is ever committed, removing it from the file is not enough; it must be revoked and replaced, because copies of the history may exist.

Worked example

Lucas writes an order-record checker with allow-list validation and moves an API key from source code to an environment variable.

Synthetic case. Records, services and keys are synthetic.

Errors and limits

Allow-lists can reject valid unusual inputs, such as names with accents, unless designed carefully. Environment variables are not a full secrets-management solution.

Exercises

• EX007 — Block-list weakness. Why are block-lists weaker than allow-lists?
  Show marking criteria

  Rubric: 3 = dangerous input has many encodings, so block-lists are always incomplete;; 2 = incomplete;; 1 = stronger;; 0 = none.
• EX008 — Product name rule. Describe Lucas's allow-list for product names.
  Show marking criteria

  Rubric: 3 = letters, digits, spaces and a few punctuation marks, up to sixty characters;; 2 = rule;; 1 = block-list;; 0 = none.
• EX009 — Committed key. What must happen if an API key is committed to version control?
  Show marking criteria

  Rubric: 3 = revoke and replace it, not just delete it from the file;; 2 = revoke;; 1 = delete only;; 0 = none.

Synthesis

Secure programming starts with validating every input against what is allowed and keeping secrets out of code.

Continue studying — chapter 03 of 40

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →