Complete Security Tutorial

Security bugs are not a separate category of bug. They are ordinary bugs in code that happens to sit on a trust boundary — and the reason they keep recurring is that the boundary is rarely where the author thought it was. SQL injection is a string-building bug. XSS is an escaping bug. SSRF is a bug about which hostnames your server is willing to resolve. Log4Shell was a logging call.

Which makes this track less about attack catalogues and more about one repeated question: at this line, is the data I am about to interpolate, render, deserialise, or fetch coming from somewhere I control? Almost every item below is an answer to that question going wrong, and almost every fix is structural — a parameterised API, a strict allow-list, a verified signature — rather than a filter that tries to recognise bad input.

The one pattern behind injection, XSS and template abuse

Every injection class has the same shape: a string is assembled from code plus data, then handed to an interpreter that cannot tell which part was which. SQL, HTML, shell, LDAP, XPath and log formats are all interpreters. Escaping tries to fix this after the fact by making the data unrecognisable as code, and it works right up until the context changes — the same string is safe in an HTML text node and dangerous inside a <script> block or an onclick attribute.

Parameterisation fixes it at the source by never assembling the string at all. The query and the values travel to the interpreter separately, so there is no point at which the value could be reinterpreted as syntax. That is why it is the only defence that does not degrade as your code grows.

# Vulnerable: the value becomes part of the query text
cur.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Safe: placeholders in the SQL, values in a second argument.
# The driver never concatenates; the server receives them apart.
cur.execute("SELECT * FROM users WHERE email = %s", (email,))

# Identifiers cannot be parameterised — allow-list them instead.
SORTABLE = {"created_at", "email", "last_login"}
if sort not in SORTABLE:
    raise ValueError(f"unsortable column: {sort!r}")
cur.execute(f"SELECT * FROM users ORDER BY {sort} DESC LIMIT %s", (limit,))

Authentication tokens fail in three specific ways

JWTs concentrate a lot of trust in a small string, and the failures cluster. Signature verification failed is usually a key mismatch after a rotation or a deploy to a different environment — the token is genuine, just signed by a key this service no longer has. An expired token that is still accepted is almost always clock skew: the verifier's leeway is generous, or the two machines disagree about the time.

The third failure is the dangerous one, because it produces no error at all: decoding a token without verifying it. Several libraries expose a decode function that parses the payload and checks nothing, and it is very easy to reach for it while debugging and never take it back out.

Password storage: the only question is cost

MD5 and SHA-256 are not broken as hashes in the way people usually mean. They are wrong for passwords because they are fast, and speed is exactly what an attacker with a stolen database wants. A modern GPU tries enormous numbers of SHA-256 candidates per second; the same hardware against bcrypt or Argon2 at sane parameters is reduced to a crawl, because those algorithms are deliberately expensive and, in Argon2's case, deliberately memory-hungry so that GPUs lose their advantage.

Salting is a separate concern and solves a different problem: it stops one precomputed table from cracking every account at once. Modern password hashes generate and embed the salt for you, which is why the stored value contains its own parameters — and why you should never implement the format by hand.

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher()            # sane defaults; tune per your hardware

stored = ph.hash(password)       # salt + parameters are inside the string
# $argon2id$v=19$m=65536,t=3,p=4$<salt>$<hash>

try:
    ph.verify(stored, submitted)
    if ph.check_needs_rehash(stored):     # parameters raised since signup
        stored = ph.hash(submitted)       # upgrade transparently on login
except VerifyMismatchError:
    pass                                  # generic failure to the caller

Server-side trust: SSRF, IDOR and dependency confusion

The three vulnerabilities in this track that hurt mature codebases most are the ones where the code is doing exactly what it was told. An IDOR is an endpoint that loads the record whose id was requested — correctly — without asking whether the caller owns it. SSRF is an image-fetcher or webhook that resolves the hostname it was given, including 169.254.169.254 and anything else inside your network. Dependency confusion is a package manager resolving the highest version it can find, which may be an attacker's upload to a public registry under your internal package name.

None of these are caught by input validation, because the input is well-formed. They are caught by making authority explicit: every query scoped to the caller, every outbound fetch checked against an allow-list after DNS resolution, every internal package name claimed and every registry pinned.