Read Backend Security

How to use this book

This book follows Backend Security: Everything You Need to Know (youtube.com/watch?v=xB1C1xZZW4k, 2h50, the longest lecture in the Backend from First Principles playlist), and it borrows the lecture's best decision: it does not hand you a list of named vulnerabilities to memorise.

It teaches one question instead, and then shows the same question producing every vulnerability in turn.

The goal is not to make you able to recite OWASP. It is to make you slightly paranoid in a useful way, so that when you write a handler you notice the moment you assumed the input was clean, the caller was who they claimed, or nobody would open the network tab.

Scope

Security is enormous: network, transport, operating system, physical, social. This book is scoped exactly where the lecture is, to the application you write: your handlers, your queries, your session logic, your headers.

The five block types

Block	What it means
Interviewer asks	A real follow-up you should expect. Answer it out loud before reading on.
Senior signal	The specific sentence that separates a senior answer from a mid-level one.
Trap	A common answer that sounds right and is wrong.
Do this	The concrete practice, with the parameter or command.
Key idea	The one thing to carry out of that section.

The marks

Mark	Means
peach	The sentence to carry away
rose	The wrong answer, the thing that bites
mint	The correct practice
pink	A definition, at the point it is first defined
underline	The phrase the sentence turns on
circle	The thing you will be asked about

The whole book in one question

Every vulnerability here is the same shape. Something crosses a boundary, and on the far side it is treated as more than it was.

  USER INPUT ──▶ your code ──▶ another system that PARSES it
                                       │
                                       ├─ SQL          ──▶ SQL injection
                                       ├─ a shell      ──▶ command injection
                                       ├─ HTML in a    ──▶ XSS
                                       │  browser
                                       ├─ your auth    ──▶ broken authz
                                       │  check
                                       └─ a log, an    ──▶ leaks
                                          error page

Three questions to ask of any handler you write, and they are the whole method:

Where is data crossing a boundary?
What am I assuming about it?
What happens if that assumption is wrong?

Part I · The attacker's question

1Assumptions are the vulnerability

An attacker does not care what framework you used. They care about exactly one thing: which sentence in your head was "that will never happen".

  "the input will be clean"              ──▶ injection
  "they are who they say they are"       ──▶ broken authentication
  "they only see their own ids"          ──▶ broken authorization
  "nobody will open the network tab"     ──▶ all of the above
  "nobody will guess this URL"           ──▶ IDOR
  "the frontend already validated it"    ──▶ everything

Every one of those is reasonable under a deadline, and every one is a happy-path assumption: the user fills the form correctly, clicks the right buttons, navigates the way you designed. Attackers do not use your app. They probe it: every input, every parameter, every header, every id.