Robust and secure programming

Robust software works correctly not just for expected inputs but also for unexpected, missing or malicious ones. Secure software protects against deliberate attacks. AQA GCSE focuses on four strategies: validation, authentication, defensive programming and anticipating misuse.

Validation

Validation checks that data is reasonable and in the correct format before processing it. It does NOT check whether the data is true — it can't know if "John Smith" is a real person.

Common validation checks:

Check	Purpose	Example
Range check	Value within acceptable limits	Age between 0 and 120
Type check	Correct data type	Postcode must be a string
Length check	Not too short/long	Password 8–20 characters
Presence check	Field not empty	Username cannot be blank
Format check	Matches a pattern	Email must contain @
Lookup check	Value in permitted set	Country code in approved list

AQA pseudocode — range-checked age entry:

REPEAT
  OUTPUT "Enter your age (1-120): "
  USERINPUT age
UNTIL age >= 1 AND age <= 120

Authentication

Authentication confirms that a user is who they claim to be. This is separate from authorisation (what an authenticated user is allowed to do).

Common authentication methods:

• Username and password — most common; vulnerable if passwords are weak or reused
• PIN — short numeric code; fast but less secure
• Biometrics — fingerprint, face recognition; difficult to fake but raises privacy concerns
• Two-factor authentication (2FA) — combines two of: something you know (password), something you have (phone/token), something you are (biometric)
• CAPTCHA — confirms the user is human, not an automated bot

Good password practices:

• Minimum length (e.g., 8+ characters)
• Mix of upper/lowercase, digits and symbols
• Never stored as plaintext — always hashed
• Account lockout after repeated failed attempts

Defensive programming

Defensive programming means writing code that anticipates problems and handles them gracefully, rather than crashing or producing wrong results.

Techniques include:

1. Input validation (see above) — reject bad data early
2. Error handling — use try/except (or equivalent) to catch runtime errors
3. Meaningful error messages — tell the user what went wrong and how to fix it
4. Sensible defaults — provide fallback values when input is missing
5. Code commenting — so future programmers (including yourself) understand the logic

AQA pseudocode — defensive integer input:

SUBROUTINE getPositiveInt(prompt)
  REPEAT
    OUTPUT prompt
    USERINPUT value
  UNTIL value > 0 AND value = INT(value)
  RETURN value
ENDSUBROUTINE

Anticipating misuse and edge cases

Edge cases are inputs at the boundary of what is valid (e.g., exactly 0, or the maximum allowed value). Misuse includes:

• Entering letters into a numeric field
• Deliberately entering SQL injection strings
• Uploading oversized files
• Leaving required fields blank
• Clicking "Submit" multiple times

A good programmer tests with:

• Normal data — typical, expected input
• Boundary data — at the edge of valid range (just inside and just outside)
• Erroneous data — completely wrong type or format

Why it matters

A program that crashes on unexpected input is unreliable. A program with no authentication lets anyone access private data. Robust, secure programs build user trust and reduce support burden.