Subject 02 / Course

Application security

Identity, permissions, untrusted input, and the mistakes that turn an API into an attack surface.

5 modules21 lessons≈ 7 h reading
Start with lesson 1.a

The application decides who can act, on what, and under which conditions. Every request carries claims (a session, a token, an object ID, a URL to fetch) and the application has to decide which of them to believe. Most serious application vulnerabilities are a belief the code should not have held.

The course follows those decisions through a request: how identity is established, how authorization is enforced object by object and tenant by tenant, what happens when input is interpreted rather than merely stored, and how a team builds software where the secure path is the default one. It assumes you can read Python and know HTTP. It does not assume a security background.

The path#

A request, boundary by boundary
flowchart LR
  R["<b>Request</b><br/><small>attacker-controlled</small>"] --> AN["<b>Authentication</b><br/><small>who is this?</small>"]
  AN --> AZ["<b>Authorization</b><br/><small>may they, on this object?</small>"]
  AZ --> IN["<b>Input handling</b><br/><small>parse, never interpret</small>"]
  IN --> E["<b>Effect</b><br/><small>data, files, outbound calls</small>"]
  class R warn
  class AN,AZ good
  class IN compute
  class E memory
classDef neutral fill:#faf9f5,stroke:#5f5e55,color:#141413,stroke-width:1.5px
classDef compute fill:#f9e2e9,stroke:#b3154f,color:#141413,stroke-width:1.5px
classDef memory fill:#f9e2e9,stroke:#b3154f,color:#141413,stroke-width:1.5px
classDef queue fill:#f9e2e9,stroke:#b3154f,color:#141413,stroke-width:1.5px
classDef io fill:#f9e2e9,stroke:#b3154f,color:#141413,stroke-width:1.5px
classDef default fill:#f9e2e9,stroke:#b3154f,color:#141413,stroke-width:1.5px
classDef warn fill:#f9e2e9,stroke:#b3154f,color:#141413,stroke-width:2px,stroke-dasharray:5 3
classDef good fill:#e2efd8,stroke:#2b6a24,color:#141413,stroke-width:2px

How each lesson works#

  1. The idea in one minute. The claim, before the detail.
  2. A picture of the attack or the defense.
  3. How it really works, precisely, with standards and tools named.
  4. Code: a small Python program using only the standard library. Vulnerable and fixed versions run against simulated applications inside the program.
  5. Where it breaks. The limits of the control.
  6. Remember this, Try it, and Check yourself.

What you need#

  • Python 3.10 or newer and a terminal. Every program runs offline.

The modules

1

Foundations

Where trust is decided in an application, how to find what can go wrong before writing code, and the handful of root causes behind the long vulnerability lists.

  1. 1.aThe request is a trust boundary20 min
  2. 1.bThreat modeling an API21 min
  3. 1.cThe vulnerability classes that matter20 min
2

Authentication

How an application decides who is making a request: stored credentials, sessions, delegated sign-in, tokens, and the second factors that resist phishing.

  1. 2.aStoring credentials21 min
  2. 2.bSessions and cookies19 min
  3. 2.cOAuth and OpenID Connect19 min
  4. 2.dTokens and JWT pitfalls17 min
  5. 2.eMFA and passkeys19 min
3

Authorization

Authentication says who is calling; authorization decides what they may do to this object, in this tenant, right now. This module covers object-level checks, access-control models, tenant isolation, and centralized policy.

  1. 3.aBroken object level authorization19 min
  2. 3.bRBAC, ABAC and relationships17 min
  3. 3.cTenant isolation19 min
  4. 3.dCentralizing policy20 min
4

Untrusted input

Input becomes dangerous when a program interprets it instead of storing it. This module covers injection, cross-site scripting, server-side request forgery, unsafe parsers and deserializers, and file paths.

  1. 4.aInjection and parameterization20 min
  2. 4.bXSS and output encoding18 min
  3. 4.cServer-side request forgery23 min
  4. 4.dParsers and deserialization23 min
  5. 4.eFiles and paths21 min
5

Building it secure

The earlier modules found vulnerabilities one class at a time. This module is about the engineering habits that stop them recurring: secure defaults, adversarial tests, a controlled dependency supply, and security-focused code review.

  1. 5.aSecure defaults19 min
  2. 5.bAdversarial testing18 min
  3. 5.cDependencies and supply chain20 min
  4. 5.dSecurity code review19 min
← Back to the library