Computing · Secondary 4

Active learning ideas

Defensive Programming: Input Validation

Students learn defensive programming best by actively testing real-world risks in controlled settings. When they see how missing checks allow simple inputs to break systems, the need for validation becomes immediate and personal. Pair work and simulations turn abstract concepts into concrete lessons that stick.

• MOE Syllabus Outcomes
• MOE: Cybersecurity - S4
• MOE: Defensive Programming - S4

• 20–40 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Collaborative Problem-Solving
• 30 min · Pairs

Pair Programming: Validation Function Challenge

Pairs receive a basic user registration form code with no validation. They add checks for email format, password strength, and username length, then test with invalid inputs. Partners alternate coding and testing roles every 10 minutes.

How can input validation prevent common exploits like SQL injection and cross-site scripting?

Facilitation Tip

During Pair Programming: Validation Function Challenge, circulate and remind pairs to swap roles every 10 minutes so both students engage with the logic.

What to look for

Present students with a code snippet for a login form that lacks input validation. Ask them to identify at least two potential vulnerabilities and explain how an attacker might exploit them. For example: 'What happens if a user enters a very long username or special characters in the password field?'

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 02

• Collaborative Problem-Solving
• 40 min · Small Groups

Small Groups: Attack Simulation Lab

Groups get vulnerable code snippets prone to SQL injection. They input malicious payloads, observe failures, then implement parameterized queries and input sanitization. Groups share one successful fix with the class.

Analyze the potential risks of inadequate input validation in web applications.

Facilitation Tip

During Attack Simulation Lab, provide one intentionally vulnerable form per group and a checklist of common payloads to test against.

What to look for

Provide students with a scenario: 'Design input validation rules for a user's email address field on a registration form.' Ask them to list at least three specific rules (e.g., must contain '@', must end with a valid domain extension) and briefly explain why each rule is important for security.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 03

• Collaborative Problem-Solving
• 25 min · Whole Class

Whole Class: Code Review Hunt

Display anonymized student code on the board or shared screen. Class votes on risky inputs, discusses fixes collectively, and votes again on improved versions. Teacher facilitates with probing questions.

Design a set of input validation rules for a user registration form.

Facilitation Tip

During Code Review Hunt, display snippets on the board without line numbers so students focus on structure, not line counting.

What to look for

Facilitate a class discussion using the prompt: 'Imagine you are building a simple blog commenting system. What are the biggest risks of not validating comment input, and what specific validation techniques would you use to prevent them?' Encourage students to share examples of malicious inputs they have encountered or can imagine.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 04

• Collaborative Problem-Solving
• 20 min · Individual

Individual: Rule Design Portfolio

Each student designs validation rules for three form fields, codes them, and documents test cases with screenshots of passes and fails. Submit digitally for peer review next lesson.

How can input validation prevent common exploits like SQL injection and cross-site scripting?

Facilitation Tip

During Rule Design Portfolio, ask each student to include a reflection on one rule they initially missed and how the activity helped them catch it.

What to look for

Present students with a code snippet for a login form that lacks input validation. Ask them to identify at least two potential vulnerabilities and explain how an attacker might exploit them. For example: 'What happens if a user enters a very long username or special characters in the password field?'

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

A few notes on teaching this unit

Start with the Attack Simulation Lab to make threats visible before theory. Use Code Review Hunt to build a shared vocabulary for vulnerabilities. End with Rule Design Portfolios so students apply lessons to their own design decisions. Avoid teaching validation as a separate step; integrate it into every example from the first lesson.

By the end of the activities, students will write validation functions that handle edge cases, explain why layered checks matter, and recognize vulnerabilities in sample code. They will shift from assuming safety to actively proving security through testing.

---

Watch Out for These Misconceptions

• During Pair Programming: Validation Function Challenge, watch for students assuming their partner's test cases cover all risks.

  After the challenge, require each pair to exchange their test cases with another pair and add at least two new edge cases based on the exchanged materials.

• During Attack Simulation Lab, watch for students believing length checks alone stop all injections.

  During the lab, provide a second form with only length checks and challenge groups to craft an input that bypasses it without exceeding character limits.

• During Rule Design Portfolio, watch for students dismissing validation overhead as insignificant.

  Ask students to benchmark their validation code against a version without checks using sample data they collected, then calculate the cost of a breach versus the overhead shown.

---

Methods used in this brief

• Collaborative Problem-Solving