NCEA Level 3 Digital Technology

Lesson 6: Authentication, Security & Row-Level Security (RLS)

Developing a complex digital outcome to solve a real-world problem for NCEA Level 3 Digital Technologies.

🎯 Ngā Whāinga Akoranga | Learning Intentions

🧠 Students will know:

Authentication vs authorization, JWT tokens, password hashing, SQL injection prevention, cross-site scripting (XSS) sanitization, and database Row-Level Security (RLS) policies.

✏️ Students will demonstrate:

Implement user authentication flows (login, signup, session storage), configure database RLS security policies, and sanitize user inputs against XSS.

🎥 Media Anchor & Pedagogical Scaffold

Web Security, JWT Authentication & Row-Level Security

Video Clip: “Session vs Token Authentication in 100 Seconds” — 2 min 18 s.

🧠 1. Before Viewing (Activate & Predict)

What stops one logged-in user from reading or overwriting another user's private data in a multi-tenant web application?

👁️ 2. During Viewing — watch the full 2m18s clip, capturing as you go

  • Capture: Distinguish authentication (who are you?) from authorization (what are you allowed to do?).
  • Capture: Write Supabase/PostgreSQL Row-Level Security (RLS) policies restricting data access by auth.uid().
  • Capture: Sanitize HTML inputs to prevent stored XSS attacks.

🗣️ 3. After Viewing & Kaiako Move (Process & Apply)

Kaiako Move: Demonstrate live penetration testing concepts (attempting to bypass frontend validation to show why backend RLS is mandatory).

Immediate Task: Complete Section 6 of your Digital Tech Portfolio: Security Architecture & RLS Policy Verification Matrix.

⚡ Whakaoho | Do Now: The User ID Came From the Browser. Do You Trust It?

Your front end sends: delete record 47, I am user 12.

Two minutes: what actually stops user 12 deleting a record belonging to someone else? If your answer is "the interface only shows them their own records", you do not have security. You have a hidden button, and hidden buttons are found.

📖 Activity 1: Separate Authentication From Authorisation, Then Attack It

Build both, distinctly (13 min). Implement signup, login and session handling. Then, separately, write down for three actions in your app exactly who is permitted to perform them. Authentication proves who someone is; authorisation decides what they may do. Collapsing the two is the most common serious bug in student projects — and in shipped ones.

Enforce it at the database (12 min). Write row-level security policies so the database itself refuses unauthorised reads and writes, then try to break in using a valid session belonging to a different user. A policy you have never attacked is a policy you have never tested.

📝 Activity 2: Level 3 Digital Technology Portfolio Task & Merit/Excellence Scaffolding (20 mins)

Portfolio Section 6. Submit: (1) a working authentication flow with session handling explained; (2) your RLS policies plus evidence of an attempted cross-user access being refused; (3) your sanitisation approach for injection and XSS, naming which layer performs it and explaining why doing it only in the browser fails.

🏫 Kaiako Planning & Pedagogy Notes

NCEA Level 3 Alignment: Direct preparation for Level 3 Digital Technology (Develop a complex digital outcome to solve a specified problem). Emphasise systematic testing, stakeholder feedback loops, and technical code refinement for Merit/Excellence grades.