Introduction to Cybersecurity

Most security bugs in web applications are ordinary programming mistakes with an unusual consequence.

A query gets assembled by pasting strings together. A template writes a visitor's name straight into the page. A route reads an id out of the URL and returns the record without checking who asked.

Each reads as reasonable in review, right up to the moment you see the request that takes advantage of it.

Security work is mostly the habit of asking what a hostile version of this input would do.

Every one of those bugs sits on a trust boundary, which is the most useful idea in this handbook.

What is a trust boundary?

A trust boundary is the line between a part of your system you control and a part you do not: the browser, a third-party API, an uploaded file. Anything crossing that line has to be checked on the far side.

How to think about security covers where to draw those lines in a typical web app.

What this handbook covers

This is application security for developers: the security of code you write, review and ship.

It doesn't cover network security, malware analysis, blue team monitoring, red team operations or compliance frameworks. Those are large fields with their own literature, and anyone who came looking for them is better served there.

Every code sample is Node and Express, with Zod for describing the shape of data you expect, so the examples look like a service you might already maintain.

The chapters run in four parts, meant to be read in order the first time, because the later ones lean on vocabulary the first one sets.

Part	What it covers	Start at
1 · Thinking like an attacker	Spotting where outside data enters, STRIDE for predicting threats, OWASP for naming ones already found, and how to write up a bug	How to think about security
2 · Input and data safety	The famous attacks, which turn out to be one mistake in different costumes, then the validation that closes them at once	Never trust user input
3 · Authentication and identity	HTTP forgets you between requests, so every app picks a way to remember. Three ways, compared	Authentication vs authorization
4 · Rate limiting and throttling	Keeping the service answering when the traffic is unfriendly. Five algorithms and two responses	Rate limiting basics

JunoWhat this handbook covers We stay in one corner of security: the code you write and review, on Node and Express with Zod checking whatever arrives.

Four parts, opening on how to think and closing on keeping a service standing. I still go back to the first part more than any of the others.

JunoWhat this handbook covers Scope is application security on Node, Express and Zod. Networks, malware, blue team and compliance are out.

Read the parts in order the first time. Part 3 assumes the input vocabulary from part 2, and part 4 assumes you can already identify a client, which part 3 sets up.

JunoWhat this handbook covers The scope is narrow on purpose: the code you're answerable for, and none of the other fields filed under the same word.

Worth knowing what the narrowness costs. Password storage, access control patterns, CSRF, response headers and supply chain risk get mentioned where a chapter needs them, and none has a chapter of its own.

When you hit one for real, go to the OWASP cheat sheet for it. This handbook will have given you the vocabulary to read it.

What you need to know first

You'll get most from this if you can write a little JavaScript and have seen a small Node and Express server. Enough to recognise a route and a middleware function when one goes past.

One idea does more work here than any other. When someone visits your site, their browser sends a request: the address they asked for, some headers, and often a body carrying whatever they typed.

Every one of those pieces was written by them, including the ones your own page filled in.

Nothing stops a person skipping your page and sending whatever they like.

One Express detail belongs up front, since most of the fixes rest on it. Middleware runs in the order you register it, so a check has to sit before the route that trusts its result. One registered afterwards protects nothing.

The JavaScript handbook covers the language side, and its chapter on the DOM sets up the chapters here on escaping what you write into a page.

JunoWhat you need to know first JavaScript and a little Node is enough to start. The idea to carry with you is that every part of a request was typed by whoever sent it, including the fields your own page filled in.

It took me a while to stop treating my own front end as a trustworthy source, and almost everything here gets easier once you do. No prior security knowledge is assumed either.

JunoWhat you need to know first Treat every field on req as attacker-controlled. The request arrives through several properties and a check on one says nothing about the others: req.params holds the path segments, req.query the query string, req.body the parsed body, req.headers the rest.

So a schema on req.body leaves a handler that later reads req.query.sort completely unchecked.

JunoWhat you need to know first The threat model is the whole request: headers, cookies, body, path, every field your own client populates.

Bring the runtime along too. The reasoning ports between stacks; the defaults and the concurrency model rarely do. Node's single event loop is the sharpest case, since a regular expression built to backtrack, or a synchronous hash call in a handler, stalls every other request in flight.

An input-size bug a thread-per-request server absorbs as latency becomes an availability failure here.

How we teach vulnerabilities

Every chapter covering a real weakness walks the same four steps, so once you've read one you know your way around all of them.

1. The broken code, short enough to read in one go and close to something you'd find in a real project.
2. The payload, the actual input or request that breaks it.
3. Why it works, traced through the code, because a fix you can't explain is a fix you'll undo later.
4. The correction, with a note on the variants it does and doesn't cover.

At the size an introduction can carry, all four look like this:

// Vulnerable: the name is pasted straight into the query text
app.get('/users', (req, res) => {
  const rows = db.query(`SELECT * FROM users WHERE name = '${req.query.name}'`)
  res.json(rows)
})

// Payload: /users?name=' OR 1=1 --
// The quote closes the string early, so OR 1=1 lands in the query as a
// condition of its own and matches every row in the table.

// Fixed: the value travels beside the query and is never parsed as SQL
const rows = db.query('SELECT * FROM users WHERE name = ?', [req.query.name])

Showing the payload is deliberate. Injection described in the abstract slides past you, and the same bug is hard to spot at three in the afternoon in someone else's pull request.

One boundary applies throughout

These payloads are here so you can find this class of bug in code you're responsible for. Run them against systems you own or have written permission to test, and nowhere else.

The handbook stays inside that line too: no scanning tools, no third-party targets, no detection evasion, and no walkthroughs of chaining one weakness into another.

JunoHow we teach vulnerabilities Seeing a working payload can feel strange at first, like being handed something off-limits. It's the same reason a food-safety class shows you what spoiled food looks like: recognising it is the whole point.

The rule to carry with you is to only ever run these against your own projects.

JunoHow we teach vulnerabilities Same four steps every time: vulnerable code, payload, why it works, the fix. Read the payload carefully each time, because that's what you'll be pattern-matching against in review later.

The step people skip is the third. A fix you adopted without understanding gets removed by the next person who finds it inconvenient.

JunoHow we teach vulnerabilities Exploitability separates a finding worth fixing this week from a note in the backlog, and you can only judge it against a concrete payload. That's why each chapter carries one.

Step four matters as much. A fix with no stated scope becomes folklore: someone applies it to a case it never covered, and the gap survives a review that felt thorough. Every fix here says what it does and does not close.

Meet your guides

Three guides host this handbook, and you pick which one shows you around.

Everyone reads the same foundation, written plainly for someone meeting security for the first time. Picking a deeper guide adds material on top: the wider pattern, the cases the first fix misses, the tradeoffs behind it. Your guide also sets the voice.

Switch guide any time from the picker at the top of any page, or open Preferences at the bottom right to change guide or font size.

The level is the depth you want on the day, so change it whenever a chapter feels thin or dense. Moving up part way through adds the extra material in place, leaving what you've read where it was.

JunoMeet your guides Hello again, it's me. Beginner here doesn't mean beginner at coding, it means new to security, and that's most people.

If a chapter feels heavy, try dropping a level for that page. Nothing is lost, and the foundation is the same underneath.

JunoMeet your guides The base page is the same whichever guide you pick. What changes is who's standing next to you and how deep they go.

Worth switching around on a topic you already know well: it's the fastest way to work out which level suits you for the rest of the track.

JunoMeet your guides The depth here is production judgement rather than internals for their own sake: what a fix costs, where it stops working, and which tradeoff you're accepting.

Pick this level because it's the depth you want today, not because of how long you've been doing this. Plenty of experienced developers read the base path on an unfamiliar topic and come back up.

Where this goes next

Four parts, thirty-two chapters, one working example broken and repaired throughout.

What is cybersecurity? narrows the word before any of the vocabulary arrives, then how to think about security starts the habit the rest of the handbook runs on.

Prefer to learn by building?Scrimba's Learn Cybersecurity course covers the same ground through interactive challenges you solve in the browser.→