Subject 02 / Course
Application security
Identity, permissions, untrusted input, and the mistakes that turn an API into an attack surface.
0 of 21 read
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#
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#
- The idea in one minute. The claim, before the detail.
- A picture of the attack or the defense.
- How it really works, precisely, with standards and tools named.
- Code: a small Python program using only the standard library. Vulnerable and fixed versions run against simulated applications inside the program.
- Where it breaks. The limits of the control.
- Remember this, Try it, and Check yourself.
What you need#
- Python 3.10 or newer and a terminal. Every program runs offline.
The modules
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.
Authentication
How an application decides who is making a request: stored credentials, sessions, delegated sign-in, tokens, and the second factors that resist phishing.
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.
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.
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.