Cookies Section — how cookies work, sessions, attributes, and vulnerabilities.
🌐 Why Web Security Feels Different (and Harder)
Steve opens with something that immediately reframed things for me: the web was never designed to be an application platform. It was a text document viewer where clicking words took you somewhere else. We decided to build the world's largest distributed application runtime on top of that. That comes with quirks.
What makes the web uniquely tricky for security is that we compile and run untrusted code in the user's browser — on their machine. That's fundamentally different from downloading a compiled, signed app from a store. It's powerful, it's convenient, and yes, it's the scary part too.
"The good parts are also the squirrely parts at the same time."
The web is also a decades-long accumulation of decisions — some thoughtful, some ad hoc, some just... forgotten. There are overlapping terms that mean similar-but-not-quite-the-same things (spoiler: "site" vs "origin" is going to matter a lot). Understanding the mental model requires a bit of historical context, not just a checklist.
🧠 The Real Problem: Missing Mental Models, Not Missing Effort
This is where it clicked for me. Steve's honest about something most courses skip: most security vulnerabilities aren't there because a developer didn't care. They're there because of one of two things:
- "I didn't even know that was a thing."
- "We had to do it like that because of [reasons]" — and someone approved it in code review without understanding the implications.
When you lack the mental model, you can't evaluate trade-offs. You just stamp the PR and ship it.
"By having this mental model, we have the ability to get a sense of exactly what we're dealing with — rather than just looking at it and going 'no, I have to do this thing.' Maybe you don't. Maybe there's a better way."
The goal of this course isn't a security checklist. It's building the intuition to recognize when something feels off.
⚖️ Security Always Has Trade-offs
Steve is refreshingly pragmatic here. Almost every security measure involves a cost:
| Security Choice | Potential Trade-off |
|---|---|
| Stricter cookie settings | Degrades user experience |
| Strongest encryption algorithm | Login could take 10 minutes |
| Strict CORS/CSP policies | Breaks if your API is on a different domain |
| Session invalidation | Complexity in infrastructure |
Not all of us work on greenfield apps. Sometimes the right answer is "I understand the risk, and here's why we're making this trade-off consciously" — not "implement the most secure thing possible regardless of context."
"Perfect is almost definitely the enemy of the good in this case."
🔐 You're the Front Line — Even as a Frontend Dev
A tempting thought: "I'm just a frontend engineer. It's text files on the internet. We should be fine."
Steve dismantles this immediately. You are the first point of contact between the user and the entire backend system. If an attacker can compromise the frontend — steal a session token, escalate privileges, inject a script — they can become that user. And if that user has admin privileges? Keys to the castle.
"On the internet, nobody really knows who you are — which is good and bad. We assume a user is who they are because they have a certain auth token or a cookie."
The scary part: even if you use React or any modern framework, you can still write business logic that no framework will protect you from. Frameworks are not a security guarantee.
🧅 Defense in Layers, Not Silver Bullets
One of the core themes Steve establishes upfront: security isn't a single switch you flip. It's layers.
- Sanitize inputs
- Set proper cookie attributes
- Implement a Content Security Policy
- Use CSRF tokens
Maybe you can't implement all of them perfectly for your situation. But stacking even two or three layers means an attacker who slips through one still hits another. The goal is to reduce the attack surface, not achieve theoretical perfection.
🗺️ What This Course Covers
Steve frames the course around breaking things first, so you understand why the defenses exist:
- Common vulnerabilities found across web applications (SQL injection, XSS, CSRF, session hijacking, clickjacking, and more)
- Hands-on demos with intentionally vulnerable apps — explore and try to cause damage
- The trade-offs of each mitigation strategy
- A holistic way of thinking, not a checklist
The examples are written in Node.js + Express as a lingua franca — but the principles apply regardless of backend language or framework.
One fun/terrifying note: Steve admits some of the intentionally broken demo apps may have more vulnerabilities than he intended, because he forgot where he hid some of the trapdoors. If you find something new, bring it up.