Defensive design — OCR GCSE Computer Science
Teaching note checked against the official specification.
Test yourself on Defensive design with OCR GCSE practice questions.
A week of Premium from your first lesson · Then the free plan continues · No card, no charge
Defensive design explained
Defensive design covers 3 specification points, including Defensive design considerations Anticipating… and Input validation.
Read the full explanation
Open a point below for its explanation and revision guidance.
Defensive design considerations Anticipating misuse Authentication
Defensive design means writing programs that stay reliable and secure even when users behave unexpectedly or maliciously. Anticipating misuse involves thinking about every way a user could enter wrong, missing or harmful data, or use the system in an unintended order, and then building safeguards before release. Authentication is the process of confirming that a user is who they claim to be, usually by checking a username with a password, a PIN, a security token or biometric data. Together they reduce crashes, data corruption and unauthorised access. For example, a login form should limit password attempts, lock an account temporarily after repeated failures and never reveal whether the username or the password was wrong.
Input validation
Input validation checks that data entered by a user is sensible, complete and in the expected format before the program processes it. It is a defensive measure because it stops bad data causing crashes, incorrect results or security problems. Common checks include a range check for numbers between limits, a length check for a minimum or maximum number of characters, a presence check for required fields, a format check for patterns such as an email address, and a lookup check against a list of allowed values. For example, a program asking for an exam mark from 0 to 100 should reject 150 and ask again. Validation cannot prove data is true, only that it is reasonable, so it is different from verification.
Maintainability Use of sub programs Naming conventions Indentation Commenting
Maintainability means another programmer can read, understand and safely change a program later. Four techniques help. Sub programs break a large task into named modules, so each part can be tested and edited without disturbing the rest; for example, a quiz program might use separate sub programs for loading questions, checking an answer and updating the score. Naming conventions give variables and sub programs meaningful names such as totalScore or calculateAverage, so their purpose is obvious. Indentation shows which statements sit inside loops, selections and sub programs, making the control flow visible. Commenting adds short explanations of why code exists, what inputs and outputs a sub program expects, or which author and version applies. Together these reduce the chance that a change in one place breaks another part, and they speed up debugging and teamwork.
Your focus
- Define defensive design and explain why it is planned before a program is released.
- Describe at least two ways a user might misuse a system and a suitable safeguard for each.
- Explain how authentication verifies a user's identity and how failed attempts can be handled safely.
Show all 9 objectives
- State what input validation is and why programs use it.
- Select and describe suitable validation checks for given data, such as range, length, presence, format and lookup checks.
- Write or interpret code that rejects invalid input and prompts the user to try again.
- Identify sub programs, naming conventions, indentation and comments in a given program.
- Explain how each technique makes a program easier to understand, test or modify.
- Apply the techniques by rewriting a short section of code to improve its maintainability.
Defensive design exam tips
Marking Points
- Defensive design anticipates problems before they occur rather than fixing them after a system fails.
- Anticipating misuse includes considering invalid data, missing data, unexpected sequences of actions and deliberate attempts to break the system.
- Authentication verifies a user's identity, commonly through something the user knows, has or is.
- A typical authentication method combines a username with a password and may add a second factor such as a code sent to a phone.
- Good defensive design limits the number of login attempts and locks or delays access after repeated failures.
- Error messages should be helpful to legitimate users but should not reveal sensitive system details to an attacker.
- Validation checks that input is reasonable and in the expected format before it is used.
- A range check confirms a value lies between a lower and an upper limit.
- A length check confirms text has an acceptable number of characters.
- A presence check confirms that a required field has not been left empty.
- A format check confirms input matches an expected pattern, such as a postcode or date.
- A lookup check confirms input matches one of a set of allowed values.
- Validation reduces errors and crashes but does not guarantee that data is accurate or truthful.
- Explains that maintainability is about how easily code can be read, understood and modified by someone other than the original author.
- Describes how sub programs split a program into named, self-contained modules that can be developed, tested and reused independently.
- Explains that meaningful naming conventions make the role of variables, constants and sub programs clear without needing to trace every line.
- Describes how indentation visually groups statements inside selection, iteration and sub program blocks so the structure of the code is obvious.
- Explains that comments record purpose, assumptions, inputs, outputs or version information that the code alone does not convey.
- Links the techniques together, for example noting that a well-named, indented and commented sub program is easier to debug and reuse than an unnamed block of code.
Examiner Tips
- 💡Link each defensive measure to a specific misuse you are preventing, such as limiting attempts to stop repeated password guessing.
- 💡Use correct terminology: state that authentication verifies identity and give a concrete method rather than writing only 'make it secure'.
- 💡When asked to improve a program, name the check, say where it is placed and explain what happens when the check fails.
- 💡Name the specific validation check and state the exact condition, for example a range check of 0 to 100 inclusive.
- 💡Show the check in pseudocode or program code with a clear condition and a message for invalid input.
- 💡Explain the consequence of missing validation, such as a crash or corrupted stored data, to gain analysis credit.
- 💡When asked to improve a piece of code, name the specific technique you are applying, such as 'use a sub program' or 'add a comment', rather than writing only 'make it neater'.
- 💡If you rewrite code in an answer, keep the logic identical and change only the maintainability feature requested, so the marker can see exactly what you improved.
- 💡Use British spelling consistently, for example 'initialise' and 'colour', and keep code keywords in the case used by the language in the question.
Common Mistakes
- Confusing authentication with validation: authentication checks identity, while validation checks that data is sensible and in the correct format.
- Believing that a strong password alone is enough: authentication also needs secure storage, attempt limits and safe error messages.
- Assuming defensive design only matters for large systems: even a small quiz program should reject unexpected input and protect any stored user data.
- Confusing validation with verification: validation checks that data is sensible, while verification checks that data has been copied or entered accurately.
- Using only one type of check when several are needed, such as checking a password's length but not its format.
- Forgetting to handle the failed case: a validation check must also tell the user what is wrong and allow another attempt.
- Writing comments that merely restate the code, such as 'increment i by 1' next to i = i + 1; instead comments should explain why the step is needed or what the sub program expects.
- Using vague names such as data1, temp or thing; instead use descriptive names such as pupilMark or averageScore that reveal the purpose.
- Indenting only some lines inside a loop or selection, which hides the block structure; instead indent every statement within the block consistently and align the closing keyword with the opening one.