Robust and Secure Programming
Why Robust and Secure Programming Matters
A program is robust if it handles unexpected or invalid inputs without crashing or producing incorrect results. It is secure if it prevents unauthorised access to data and functionality.
Real programs receive data from users who may enter values that are empty, out of range, or of the wrong type entirely. Without code that validates input and controls access, programs fail in unpredictable ways — or worse, allow malicious users to exploit them.
Two key mechanisms:
| Mechanism | Purpose | Example |
|---|---|---|
| Validation | Check that data entered is acceptable before it is processed | Reject an age of –5 or 999 |
| Authentication | Verify the identity of a user before granting access | Require a matching username and password |
Two types of programming error must also be understood:
| Error type | When it occurs | Example |
|---|---|---|
| Syntax error | The code violates the rules of the language — it cannot be run | WHILE x > 0 without ENDWHILE |
| Logic error | The code runs but produces the wrong result | Using > instead of ≥, causing an off-by-one result |
Knowing the difference between syntax and logic errors is an exam requirement. A syntax error prevents the program from running at all. A logic error allows the program to run but produces incorrect behaviour.
Data Validation
Validation checks whether data entered by a user is acceptable — within the expected format, range, or content — before the program acts on it.
Validation does not guarantee the data is correct. It only guarantees it is acceptable. A user entering a date of birth of 01/01/2000 when their real birthday is 01/02/2000 passes all validation checks — the data is plausible but wrong.
Three validation checks required by the specification:
1. Range check — confirms that a value lies within an acceptable range:
OUTPUT "Enter a score (1–100): "
score ← USERINPUT
WHILE score < 1 OR score > 100 DO
OUTPUT "Invalid. Enter a value between 1 and 100: "
score ← USERINPUT
ENDWHILE
2. Minimum length check — ensures a string meets a minimum number of characters:
OUTPUT "Enter a username (at least 3 characters): "
username ← USERINPUT
WHILE LEN(username) < 3 DO
OUTPUT "Too short. Enter at least 3 characters: "
username ← USERINPUT
ENDWHILE
3. Empty string check — prevents a blank entry being accepted:
OUTPUT "Enter your name: "
name ← USERINPUT
WHILE name = "" DO
OUTPUT "Name cannot be empty. Try again: "
name ← USERINPUT
ENDWHILE
Writing Validation Routines
Validation is best implemented as a subroutine so it can be reused throughout a program. A validation function performs the check and returns the validated value to the caller.
Worked example — a reusable range-checking function:
FUNCTION getValidAge()
OUTPUT "Enter age (1–120): "
age ← INT(USERINPUT)
WHILE age < 1 OR age > 120 DO
OUTPUT "Invalid age. Enter a value between 1 and 120: "
age ← INT(USERINPUT)
ENDWHILE
RETURN age
ENDFUNCTION
studentAge ← getValidAge()
def get_valid_age():
age = int(input("Enter age (1-120): "))
while age < 1 or age > 120:
print("Invalid age. Enter a value between 1 and 120.")
age = int(input("Enter age (1-120): "))
return age
student_age = get_valid_age()
Combining checks: a password field might require both a minimum length and a non-empty value. Both conditions can be placed in a single WHILE loop using AND/OR:
OUTPUT "Enter password: "
password ← USERINPUT
WHILE LEN(password) < 8 OR password = "" DO
OUTPUT "Password must be at least 8 characters: "
password ← USERINPUT
ENDWHILE
Authentication Routines
Authentication verifies that the person attempting to access a program or system is who they claim to be. AQA requires knowledge of username-and-password authentication using plain text only — passwords are stored and compared as plain text strings, without encryption.
Worked example — a simple login routine with a limit on attempts:
FUNCTION login()
attempts ← 0
WHILE attempts < 3 DO
OUTPUT "Username: "
username ← USERINPUT
OUTPUT "Password: "
password ← USERINPUT
IF username = "admin" AND password = "pass123" THEN
OUTPUT "Access granted"
RETURN TRUE
ELSE
OUTPUT "Incorrect credentials"
attempts ← attempts + 1
ENDIF
ENDWHILE
OUTPUT "Too many failed attempts. Access denied."
RETURN FALSE
ENDFUNCTION
def login():
attempts = 0
while attempts < 3:
username = input("Username: ")
password = input("Password: ")
if username == "admin" and password == "pass123":
print("Access granted")
return True
else:
print("Incorrect credentials")
attempts += 1
print("Too many failed attempts. Access denied.")
return False
In this specification, passwords are handled as plain text. Students are not required to understand encryption of passwords. In real-world systems, passwords are never stored as plain text — but that is beyond the scope of AQA 8525.
How much of this have you taken in?
Quiz yourself on this section — free, no card needed.
Testing and Types of Test Data
Testing means running a program with carefully chosen inputs to check whether it produces the correct outputs and behaves as expected. Testing is used both to confirm correct behaviour and to find errors.
The specification requires knowledge of three types of test data:
| Type | Description | Example (valid range: 1–10) |
|---|---|---|
| Normal (typical) | A value well within the acceptable range, representing typical use | 5, 7 |
| Boundary (extreme) | Values at the very edge of the acceptable range — both just inside and just outside | 0, 1, 10, 11 |
| Erroneous | Data that is completely invalid — wrong type, nonsensical, or far outside the range | "hello", -50, 9999 |
Boundary data explained: For a range of 1 to 10, the boundary values are 0, 1, 10, and 11 — the values immediately outside and immediately inside each boundary. Programs most commonly fail at boundaries, so testing both sides of each limit is essential.
Why each type matters:
- Normal data confirms the program works for typical cases
- Boundary data reveals off-by-one errors (e.g.
>instead of≥) - Erroneous data confirms the program handles invalid input gracefully rather than crashing
Worked example — justifying test data for an age validation routine that accepts 1–120:
| Test value | Type | Expected result | Reason for choosing |
|---|---|---|---|
25 | Normal | Accepted | Typical valid age |
1 | Boundary | Accepted | Lower boundary — just inside |
0 | Boundary | Rejected | Just below lower boundary |
120 | Boundary | Accepted | Upper boundary — just inside |
121 | Boundary | Rejected | Just above upper boundary |
"abc" | Erroneous | Rejected | Non-numeric input |
Error Types
Understanding the difference between error types is directly assessed.
Syntax errors occur when code does not follow the grammatical rules of the programming language. The program cannot be run until all syntax errors are fixed. An interpreter or compiler reports them before execution begins.
Examples:
- Missing
ENDIFat the end of anIFblock - Using
=for assignment instead of←in AQA pseudocode - A misspelled keyword:
WHLIEinstead ofWHILE
Logic errors occur when the code is syntactically correct and runs without error, but produces an incorrect result because the logic is wrong. The program runs — it just does the wrong thing.
Examples:
- Using
>instead of≥means a value equal to the boundary is rejected when it should be accepted - Initialising
total ← 1instead oftotal ← 0before an accumulator loop - Using
ANDinstead ofORin a validation condition, causing the loop to behave incorrectly
Identifying and categorising errors — worked example:
# Which errors are present?
total ← 1
FOR i ← 1 TO 5
total ← total + i
NEXT i
OUTPUT total
total ← 1— logic error: accumulator should start at 0, not 1; the program runs and produces output, but the output is wrong (gives 16 instead of 15)
# A second example with a syntax error:
IF score > 50 THEN
OUTPUT "Pass"
# Missing ENDIF — syntax error: program cannot run
- Missing
ENDIF— syntax error: theIFblock is never closed; the program violates the language rules and cannot be executed
Common Exam Mistakes
1. Claiming validation ensures data is correct
Validation only checks that data is acceptable (within format/range). It cannot determine whether data is accurate. A user entering the wrong date of birth in the correct format passes validation but is factually incorrect.
2. Mixing up boundary test values
For a range of 1–10, the boundary values are 0, 1, 10, 11 — immediately outside and immediately inside each end. A common mistake is only testing 1 and 10 (just the limits), missing 0 and 11 (the values just outside them).
3. Confusing syntax and logic errors
A syntax error stops the program from running at all — the error is in the structure of the code. A logic error allows the program to run but produces incorrect output — the error is in the reasoning. Describing a wrong condition as a "syntax error" is incorrect.
4. Limiting authentication attempts
For a more secure login routine, limiting failed attempts is a good improvement. If the question asks for secure authentication or allows design choices, include a maximum number of attempts and explain that it reduces brute-force guessing.
5. Omitting erroneous test data
Test plans that only include normal and boundary data are incomplete. Erroneous data (wrong type, wildly out of range) must be included to confirm the program handles invalid input without crashing.
Generate revision on any topic you study
Type any topic you're studying and Aicademy generates a complete lesson, quiz, and flashcard set — personalised to your level.
Lessons on anything
Structured, level-matched lessons on any topic you study
Practice quizzes
Find out what you actually know before the exam does
Flashcard sets
Lock in key concepts with instant revision cards
Ask Aica
Stuck on something? Get a clear explanation, any time
Subroutines: Procedures and Functions
Binary Numbers and Denary Conversion
Related lessons
7 Slides
7 Slides
7 Slides