Almost every application vulnerability is one of two failures. Either data reached a position where something parsed it as instructions — a query, markup, a shell line, a serialized object — or a boundary was crossed without re-checking what the caller may actually do. Injection and cross-site scripting are the first shape; broken access control and request forgery are the second. Read this for the two shapes rather than for a list of attack names. The defences that hold are the ones that make a failure structurally impossible, and they are a small set of moves repeated in different syntax.
Each chapter opens with the short version. Tap one to read the detail.
The two failures, and the words the field uses for them
~2 min
Security is one question asked in two places: does data cross into a position where something parses it, and does a caller cross a boundary without being re-authorized? Taxonomies and top-ten lists are vocabulary over those two shapes.
Authorize the object, not the route
~2 min
Authentication answers who; authorization answers what they may do — and it must be answered again for every object, on the server, on every request. The most common serious flaw in real applications is a valid token used on somebody else's record.
Data crossing into the instruction position
~3 min
Injection and cross-site scripting (XSS) are one bug at two ends of the system: a value you treat as data lands where some parser reads syntax. Going in, the fix is binding; coming out, it is encoding chosen for the exact destination.
What the browser enforces, and what it only advises
~2 min
The same-origin policy stops one origin's script reading another's response; it does not stop the request being sent. Security headers are the rest of the browser-side toolkit — instructions the browser follows on your behalf, never controls on your server.
The confused deputy, in both directions
~2 min
Two attacks share one shape: something trusted is talked into spending its authority for somebody else. In the browser the deputy is the user's session; on the server it is your own outbound request. Neither is fixed by checking who sent the request.
Proving who, storing the proof, and carrying it around
~3 min
Three things carry the weight: a second factor that cannot be relayed, a stored password that is expensive to crack, and a token you verify on your own terms. Composition rules and forced rotation buy none of them, and current guidance has dropped both.
The small amount of cryptography you actually choose
~2 min
You will seldom design a cryptosystem and constantly choose four things: a mode, a nonce, where the key lives, and how you compare secrets. That is where real systems break. The primitives themselves almost never do.
Blast radius: identity, network and the container
~2 min
Cloud and cluster incidents are rarely exotic. They are a wildcard permission, a long-lived key, a flat network and a workload running as root — each turning a small compromise into a large one. The configuration is the part that stays yours.
The code you did not write, and finding bugs before shipping
~2 min
Most of what you ship is other people's code, resolved by a package manager and assembled by a runner holding your deploy credentials. Inventory comes first: you cannot answer a new advisory about a component you cannot list.
Secrets, logs, and the day it goes wrong
~2 min
A committed secret is compromised the moment it lands, and deleting the file does not remove it. Logs are the mirror problem — the mechanism that copies sensitive values into every store you own.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.