✅ CIA Triad + AAA Model | ✅ Cryptography (AES, RSA, hashing, salting)
✅ SQL injection, XSS, CSRF | ✅ Hardcoded secrets + .env pattern
✅ Security through obscurity | ✅ Insecure dependencies + supply chain
✅ Social engineering | ✅ SAST, DAST, penetration testing
The next module is Programming for the Web — the one that's probably most relevant to your day-to-day life as a developer. You've already built Volcanic Pantheon, you've hosted it on Vercel, you've set up authentication. You've been doing web programming. This module is about understanding what's actually happening underneath.
When you push code to Vercel and someone in another country visits your site — what is happening? What travels over the network, what does the browser do with it, and how does a server decide what to send back? You'll leave this module with clear answers to all of that.
HSC outcome covered: SE-12-05 — designs and implements solutions for the web, including using networking protocols, client-server architecture, and data exchange formats.
Six topics. Each gets its own lesson. Here's the map.
DNS, IP addresses, TCP/IP — what actually happens from the moment you type a URL to the moment a page loads. Every request your browser makes follows the same chain of steps.
The language of the web. HTTP defines how browsers ask for things and how servers respond — including methods (GET, POST, DELETE), status codes (200, 404, 500), and headers. HTTPS adds encryption on top.
The split between what runs in the browser (client) and what runs on a server. Static sites, dynamic sites, serverless functions, edge computing — what they are and when you'd choose each.
How services communicate with each other over HTTP. REST API conventions, JSON as the data format, authentication with API keys and tokens. This is how modern apps are glued together.
How data gets stored and retrieved — relational databases (SQL), document stores, and how a web server talks to a database to build a response. Includes the full request → server → database → response flow.
Putting it all together — building a simple web app that handles requests, talks to a data source, and returns a response. Form handling, validation, and what a basic backend looks like in practice.
Before we dive into anything, let's see what you already have in your head. Think through these — no pressure to get them right, this is just calibration.
The browser needs to figure out the IP address behind the domain name. That lookup is called DNS resolution — your device asks a DNS server "what IP address does volcanoic-pantheon.vercel.app point to?" and gets back something like 76.76.21.21. Only then can it open a connection and actually ask for the page.
GET requests ask for data — "give me this page, this image, this file." They don't change anything on the server and the parameters go in the URL. POST requests send data — "here's a form submission, here's a login, here's a new record." The data goes in the request body, not the URL. This is why login forms use POST — you don't want the password appearing in the URL bar.
HTTP status codes are grouped by their first digit: 2xx = success, 3xx = redirect, 4xx = client error (you asked for something wrong or missing), 5xx = server error (the server broke trying to respond). So 404 = "you asked for something that doesn't exist" and 500 = "the server crashed handling your request."
However many of those you knew, that's exactly the right starting point. The module will make all of it concrete with real examples and things you can observe in your own browser.
Before the next lesson, open your browser's DevTools → Network tab (F12 → Network) and reload any page — your own site, YouTube, anything. You'll see every single HTTP request the page makes.
Don't try to understand everything. Just notice:
We'll break down what you saw at the start of the next lesson.