Computing · Year 11

Active learning ideas

Defensive Design and Validation

Defensive design and validation require students to shift from writing code that works to writing code that withstands scrutiny. Active learning lets them experience the moment a hacker bypasses a weak check or a user finds a loophole, turning abstract concepts into immediate, memorable lessons.

• National Curriculum Attainment Targets
• GCSE: Computing - Programming
• GCSE: Computing - Software Development

• 25–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Escape Room
• 35 min · Pairs

Pair Programming: Login Validator

Pairs code a login function with validation for username length, password complexity, and sanitization against SQL injection. They exchange code with another pair to test malicious inputs like ' OR 1=1--. Pairs then patch vulnerabilities and report findings. End with whole-class share of toughest exploits.

How can we anticipate and neutralize malicious user input before it reaches the system core?

Facilitation Tip

During Pair Programming: Login Validator, circulate and ask each pair to explain why they chose a particular validation rule for one field, ensuring reasoning is explicit.

What to look for

Present students with a simple Python function that takes user input for a username. Ask them to write two lines of code: one to validate that the username is not empty, and another to sanitize it by removing any HTML tags.

• Remember
• Apply
• Analyze
• Relationship Skills
• Self-Management

Activity 02

• Escape Room
• 45 min · Small Groups

Small Groups: Vulnerability Hunt

Groups receive a flawed program handling file uploads. They generate test cases with oversized or malicious payloads to crash it. Refactor by adding range checks and content filters, then demo attacks and fixes to the class.

Why is it impossible to create a perfectly secure program through validation alone?

Facilitation Tip

For Vulnerability Hunt, assign each group a different program type (e.g., file uploader, login form) so they see how sanitization applies outside web contexts.

What to look for

Pose the question: 'Imagine a login form that requires a password to be at least 8 characters long and contain a mix of uppercase, lowercase, numbers, and symbols. Discuss the potential user frustration this strict validation might cause, and suggest one way to balance security with user convenience.'

• Remember
• Apply
• Analyze
• Relationship Skills
• Self-Management

Activity 03

• Escape Room
• 25 min · Whole Class

Whole Class: Authentication Debate

Present code snippets with varying authentication strengths, from basic passwords to multi-factor. Class discusses trade-offs in security versus speed, votes on best for scenarios like banking apps, and codes a simple improvement together.

What are the trade-offs between user convenience and strict data validation?

Facilitation Tip

Before the Authentication Debate, give students three minutes to jot down two strong arguments for one side so quieter voices have prepared contributions.

What to look for

Students exchange small code snippets they've written for input validation. They review each other's code, identifying one potential flaw in the validation logic and suggesting one improvement. They then provide written feedback to their partner.

• Remember
• Apply
• Analyze
• Relationship Skills
• Self-Management

Activity 04

• Escape Room
• 30 min · Individual

Individual: Edge Case Tester

Each student writes a data entry form with full validation suite. They create 10 edge-case inputs, run tests, and log failures. Submit logs for peer review to identify overlooked sanitization needs.

How can we anticipate and neutralize malicious user input before it reaches the system core?

Facilitation Tip

During Edge Case Tester, ask students to document how their test case exposes a flaw in the original code before moving to a fix.

What to look for

Present students with a simple Python function that takes user input for a username. Ask them to write two lines of code: one to validate that the username is not empty, and another to sanitize it by removing any HTML tags.

• Remember
• Apply
• Analyze
• Relationship Skills
• Self-Management

A few notes on teaching this unit

Start with a quick demonstration of a vulnerable input field being exploited, then immediately have students try to break it themselves. Research shows that hands-on penetration attempts solidify understanding faster than lectures. Emphasize that defensive design is iterative: initial checks get refined after testing. Avoid presenting validation as a single-step checklist; instead frame it as a conversation between security and usability.

By the end of these activities, students will confidently apply input validation, sanitization, and authentication in code while explaining why each layer matters. They will also critique designs for usability and security trade-offs, using evidence from peer testing and debates.

---

Watch Out for These Misconceptions

• During Pair Programming: Login Validator, watch for students assuming their validation rules catch everything.

  After their validator passes their own tests, hand them a cheat sheet of edge cases (e.g., SQL injection payloads, Unicode spoofing) and ask them to test again—this shows that validation catches common errors but needs layered defenses like authentication.

• During Vulnerability Hunt, watch for students thinking sanitization only applies to web forms.

  During the hunt, have each group test a different input stream (e.g., file upload, network packet) and present how sanitization prevents exploits outside websites, proving it’s a universal practice.

• During Authentication Debate, listen for students claiming strict validation always ruins the user experience.

  After the debate, have students draft a revised login screen with relaxed rules but additional safety cues (e.g., password strength meter), using real feedback from peers to balance security and convenience.

---

Methods used in this brief

• Escape Room