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.

• Year 11
• Computing
• 4 activities
• 25 min–45 min

Learning Objectives

1. Analyze potential vulnerabilities in a given program by identifying common input validation weaknesses.
2. Create defensive code snippets to sanitize user input against SQL injection and cross-site scripting (XSS) attacks.
3. Evaluate the trade-offs between implementing strict input validation rules and maintaining user experience in a web application scenario.
4. Design an authentication mechanism using hashed passwords and salt to protect user credentials.
5. Compare and contrast the effectiveness of input validation versus input sanitization in preventing specific types of security threats.

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.

Prepare & details

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.

Setup: Group tables with puzzle envelopes, optional locked boxes

Materials: Puzzle packets (4-6 per group), Lock boxes or code sheets, Timer (projected), Hint cards

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

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.

Prepare & details

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.

Setup: Group tables with puzzle envelopes, optional locked boxes

Materials: Puzzle packets (4-6 per group), Lock boxes or code sheets, Timer (projected), Hint cards

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

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.

Prepare & details

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.

Setup: Group tables with puzzle envelopes, optional locked boxes

Materials: Puzzle packets (4-6 per group), Lock boxes or code sheets, Timer (projected), Hint cards

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

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.

Prepare & details

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.

Setup: Group tables with puzzle envelopes, optional locked boxes

Materials: Puzzle packets (4-6 per group), Lock boxes or code sheets, Timer (projected), Hint cards

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Quick Check

After Pair Programming: Login Validator, collect each pair’s final validator code and ask them to annotate two lines: one for validation and one for sanitization, explaining their choices in one sentence each.

Discussion Prompt

During Authentication Debate, pause and ask each side to summarize the strongest user complaint against their position, then have the class vote on which balance of security and usability feels most reasonable.

Peer Assessment

After Edge Case Tester, have students exchange their edge case test scripts and review each other’s findings, providing written feedback that names one flaw in the original code and suggests one improvement.

Extensions & Scaffolding

• Challenge: Ask students to design a validation rule for a phone number that accepts international formats without rejecting valid inputs.
• Scaffolding: Provide a partially completed sanitization function with comments guiding where to strip HTML or SQL fragments.
• Deeper exploration: Have students research how CAPTCHA fits into authentication and compare its effectiveness to password policies in a short written analysis.

Key Vocabulary

Input Validation	The process of checking user-supplied data to ensure it meets predefined criteria for type, format, length, and range before it is processed by the program.
Input Sanitization	The process of cleaning or modifying user input to remove or neutralize potentially harmful characters or code, such as HTML tags or SQL commands.
Authentication	The process of verifying the identity of a user or system, typically by requiring credentials like a username and password.
SQL Injection	A code injection technique that exploits security vulnerabilities in an application's software, allowing an attacker to interfere with the queries that an application makes to its database.
Cross-Site Scripting (XSS)	A type of security vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users, potentially leading to session hijacking or data theft.