Defensive design

Defensive design means writing programs that work correctly and safely even when users enter unexpected input, make mistakes or deliberately try to misuse the system. OCR J277 Paper 2 tests input validation, authentication, and writing maintainable code.

Why is defensive design needed?

• Users make mistakes (typos, wrong format).
• Some users deliberately enter malicious input to break or exploit a system.
• Programs that crash or produce wrong output due to bad input are unreliable and unsafe.
• A defensively designed program handles these situations gracefully.

1. Input validation

Validation checks that input data meets predefined rules before it is used. It does not check whether the data is truthful — only that it is in the correct format.

Types of validation

Validation check	What it does	Example
Range check	Ensures value is within acceptable range	Age must be 1–120
Type check	Ensures data is the correct type	Score must be an integer
Length check	Ensures string is correct length	Password must be 8–20 characters
Presence check	Ensures a field is not empty	Username cannot be blank
Format check	Ensures data matches a pattern	Email must contain @ and .
Lookup check	Ensures value is from an accepted set	Gender must be M, F or X

Validation loop (OCR pseudocode)

age = USERINPUT
WHILE age < 1 OR age > 120
    OUTPUT "Invalid age. Please enter a value between 1 and 120."
    age = USERINPUT
END WHILE

2. Input sanitisation

Sanitisation cleans or neutralises input before it is processed or stored — removing dangerous characters.

• Removing HTML tags from user input prevents cross-site scripting (XSS) attacks.
• Escaping or removing SQL special characters prevents SQL injection attacks.
• Example: replacing <script> with <script> in a comment field.

Sanitisation goes further than validation: it modifies the input to make it safe.

3. Authentication

Authentication verifies that a user is who they claim to be.

• Username + password: the most common method. Passwords should be hashed (not stored in plain text).
• Two-factor authentication (2FA): requires a second factor (e.g. SMS code, authenticator app) in addition to a password.
• CAPTCHA: distinguishes humans from automated bots (distorted text, image identification).
• Biometrics: fingerprint, facial recognition — increasingly common on mobile devices.

4. Code maintainability

Defensive design also means writing code that is easy to read, modify and debug.

• Comments: explain what code does and why, not how.
• Meaningful variable names: studentScore not x; isAuthenticated not flag1.
• Subroutines/functions: break code into reusable, single-purpose blocks.
• Indentation: consistent indentation makes structure clear.
• Constants: use named constants instead of magic numbers (MAX_SCORE = 100 not just 100).

Why maintainability matters

• Code is read far more than it is written.
• Other developers (or your future self) need to understand and modify it.
• Bugs are easier to find in well-structured, well-named code.

Common OCR exam mistakes

1. Confusing validation with verification — validation checks format/range; verification checks that data entered matches a source (e.g. re-entering a password twice).
2. Saying validation checks if data is "correct" — it only checks if it meets the format rules. A valid age of 999 is still nonsensical but passes a 1–999 range check.
3. Forgetting sanitisation is different from validation — sanitisation modifies input; validation only accepts or rejects.
4. Listing "using functions" as just a good practice — in the context of defensive design, subroutines improve maintainability, reducing error-prone code duplication.