Community resourceWorksheet

J277 2.3.1 Defensive design and authentication

Part 1 of 7 · J277 2.3 · Producing robust programs

The first robust programs worksheet for OCR J277 2.3.1, on anticipating misuse and confirming who a user is.

Students will:

  • explain what defensive design means
  • anticipate accidental and deliberate misuse of a program
  • describe how authentication confirms a user's identity
  • separate authentication from input validation
  • write a simple authentication check in Python

Inside: 5 explanation cells, 2 runnable Python tasks, 2 multiple-choice questions, 1 fill-in-the-blanks cell and 3 written answers. 17 marks, about 45 minutes.

Series: J277 2.3 · Producing robust programs, part 1 of 7.

Shared by Coding PathwayVerified teacher

  • 13 cells
  • About 45 minutes
  • CC BY-SA 4.0
  • Shared 17 Aug 2026
  • Updated 9 Sept 2026

Preview

The whole resource, exactly as a class sees it. Answers and marking are held back.

Defensive design and authentication

A robust program continues to behave sensibly when people make mistakes, enter unexpected values or try to use it in a way the programmer did not intend. Defensive design means thinking about those possibilities while the program is being designed, then adding suitable safeguards.

OCR names two important defensive design considerations:

  • anticipating misuse, which means predicting accidental or deliberate misuse and reducing the opportunity for it;
  • authentication, which means confirming that a user is who they claim to be, often by checking a username and password.

Input validation is another part of robust programming. It checks whether entered data meets rules before the program uses it. Authentication and validation are related, but they answer different questions: authentication asks “Who is this user?”, while validation asks “Is this input acceptable?”

Multiple choice1 mark

A shared rehearsal-room system requires each student to sign in before changing a booking. Which defensive design consideration is being used?

  • AAuthentication
  • BIteration
  • CDecomposition
  • DSorting

Anticipating likely misuse

Programmers should consider all likely input values, not only the values a careful user is expected to enter. Misuse may be accidental, such as leaving a required field empty, or deliberate, such as repeatedly guessing account details.

Possible behaviourSensible defensive response
A quantity is entered as -4Reject it if the permitted quantity must be positive.
A required name is left emptyDisplay a clear message and ask again.
A user enters an event code that does not existCheck it against the accepted codes before saving.
Incorrect sign-in details are suppliedRefuse access and allow another appropriate attempt.

Defensive design is not about guessing every imaginable event. It is about recognising likely problems and making sure the program has a controlled response rather than accepting unsuitable data or producing misleading results.

Fill in the blanks3 marks
Complete the summary using the answer bank. label 1 means designing for likely problems. label 2 confirms a user's identity. label 3 checks whether entered data meets stated rules.
  • Defensive design
  • Authentication
  • Validation
  • Testing
  • Maintainability
Multiple choice1 mark

Which action is input validation rather than authentication?

  • AComparing a username and password with stored details
  • BChecking that a ticket quantity is between 1 and 6
  • CConfirming a user's identity before showing an account
  • DRefusing access after incorrect sign-in details

A simple authentication check

The program below compares both entered values with stored details. Access is granted only when both comparisons are true. The details are fictional and used only to demonstrate the logic.

Before running it, predict the output. Then change either entered value and run it again. Notice that authentication depends on the complete condition, not just a correct username or just a correct password.

Worked example
stored_username = "stage_manager"
stored_password = "Lantern7"

entered_username = "stage_manager"
entered_password = "Lantern7"

if entered_username == stored_username and entered_password == stored_password:
    print("Access granted")
else:
    print("Access denied")

Supported practice: authenticate a user

Complete the sign-in program. Ask for a username and password, then set access_granted to True only when both entries match the stored values. Otherwise it must remain False.

Use the two inputs supplied by the caller. Do not replace them with fixed answers. The checks will try one matching sign-in and two rejected sign-ins.

Coding task3 marks
stored_username = "equipment_lead"
stored_password = "Tripod4"

entered_username = input("Username: ")
entered_password = input("Password: ")
access_granted = False

# Set access_granted to True only when both details match.
Written answer2 marks

A video-sharing service lets users save private playlists. Describe one defensive design method that would be suitable for this service.

Name the method, then describe how it would be used in this particular service. A generic method name alone is not enough.

Students type their answer here.

Written answer4 marks

A community equipment app allows a user to request an item and a quantity. Explain two ways the programmer could anticipate accidental or deliberate misuse.

For each way, use this structure: likely misuse, safeguard, effect on the program.

Students type their answer here.

Written answer3 marks

Explain the difference between authentication and input validation.

State the question each process answers and give one brief example of each.

Students type their answer here.

Review

Close your notes and retrieve these three ideas: what defensive design means, one example of anticipating misuse, and the difference between authentication and validation. Then check your wording against the opening explanation.

In an OCR response, a method name may earn one mark, but describe requires detail about how the method works or how it applies to the scenario.