Application & API Security

The transport is encrypted, the caller is authenticated, the policy engine says yes — and the request still deletes someone else's record, because the handler took an id from the URL and trusted it. This domain is about the code you personally write: the place where the abstract guarantees of the layers below are either honoured or quietly thrown away, one function at a time.

It teaches one lens and then applies it relentlessly. The lens is that input from outside your process is data, never instruction, and never proof of permission. Under it, a family of vulnerabilities that look unrelated turn out to be the same mistake: SQL injection and path traversal are both a string crossing a boundary it should have been parameterised across, while IDOR and mass assignment are both a caller choosing which object or which field they get to touch. You will meet these as fix-the-function katas — the broken version, the exploit that proves it is broken, the repair, and a test that keeps it repaired — with the OWASP Top 10 as the map rather than the syllabus. The domain then moves outward to design: where authentication and authorization belong in a request's life, and how to return errors that do not become an enumeration oracle. Its flagship capstone hands you a working but vulnerable API and asks you to harden it. It closes on the build itself — keeping credentials out of the repository by scanning before they land, and keeping dependencies pinned and patched — because a perfect handler shipped with a leaked key is not secure.