Who it is for
- Penetration testers and bug bounty hunters who want to move from black-box testing to source code.
- Application security engineers who need a repeatable review method and help triaging scanner output.
- Senior developers and tech leads who review pull requests and want to catch security flaws before merge.
What you will be able to do
- Map an unfamiliar repository: entry points, trust boundaries and the code worth your time.
- Trace untrusted input from source to sink and tell a real finding from a scanner false positive.
- Find authentication, authorization, tenant-isolation and business-logic flaws that tools miss.
- Prove exploitability in a local lab and justify severity in terms a product owner accepts.
- Find variants of a known vulnerability with patch diffing and custom Semgrep or CodeQL queries.
- Write findings with root cause, evidence and a fix, and review whether a proposed fix holds.
Before you start
- You can read code comfortably in at least one of JavaScript/TypeScript, PHP, Java or Python.
- You know HTTP and the common web vulnerability classes, at the level of the OWASP Top 10.
- You can use git, Docker and a terminal. We start with a short assessment of your level, so the plan fits you.
Syllabus
Eight modules. Your plan follows them in the order and depth that fit your level: quickly through what you know, longer where you need it.
Reading an unfamiliar codebase for securityTurn a repository you have never seen into a map of what an attacker can reach.
- Entry points: routes, controllers, jobs, webhooks and message consumers
- Framework conventions that hide routing and middleware
- A one-page threat model: assets, actors and trust boundaries
- Spending a time-boxed review where the risk is
Sources, sinks and data flowFollow untrusted input to the place where it does damage.
- Source-to-sink tracing by hand, including second-order flows
- Validation, sanitisation and encoding, and when each one protects
- SQL, command, template, file path, SSRF and deserialization sinks
- Triaging SAST output: confirm, dismiss or dig deeper
Authentication and sessionsReview the code that decides who the user is.
- Login, registration, password reset and MFA flows
- Token and session lifecycle: issue, validate, expire, revoke
- JWT verification mistakes, with the fast-jwt patch chain as a case
- OAuth and OpenID Connect redirect, state and audience checks
Authorization and tenant isolationFind the missing check that lets one customer reach another customer’s data.
- Object- and function-level checks (BOLA, BFLA, IDOR) in handlers, middleware and ORM queries
- Mass assignment and over-posting
- Tenant scoping in queries, caches and background jobs
- GraphQL resolvers and administrative endpoints
Business logic, state and concurrencyFind code that breaks the rules the product depends on.
- Invariants: what must always be true, and the code that breaks them
- Race conditions in payments, coupons and quotas
- Trusting client-supplied prices, roles and identifiers
- Arithmetic: overflow, truncation and shift width (CVE-2025-37858)
Parsers, platforms and the supply chainReview the assumptions your code makes about everything around it.
- Path normalisation and parser differentials (CVE-2026-21589, CVE-2026-104935)
- Checks that disappear after a failed lookup (CVE-2024-26855)
- Server-side rendering boundaries after React2Shell
- Dependencies, build scripts and lockfiles after the Axios npm compromise
Proving exploitability and impactMove from a suspicious line to a confirmed, prioritised finding.
- Preconditions, reachability and attacker control
- A minimal proof in a local lab
- Severity with CVSS and business context
- Patch diffing and variant analysis with Semgrep and CodeQL
Fixes, reports and AI-written codeGet the vulnerability fixed, and keep it fixed.
- Findings developers accept: location, root cause, evidence, fix
- Reviewing a proposed fix and its regression test
- Secure defaults that remove a whole class of bug
- Reviewing AI-generated code, and checking what an AI reviewer tells you
Practical work
Trace labs
Guided reviews of applications I prepared for the course, where you follow input through real framework code to the vulnerable line.
Variant hunts
Start from a published patch in an open-source project, then look for the same mistake elsewhere in that codebase at the vulnerable version.
Fix reviews
Decide whether a proposed fix removes the root cause or only the reported symptom, and write the test that proves it.
Final assessment
Review a multi-tenant web application
A time-boxed review of an application built for the course, with source code and a running copy. You write a professional findings report, and we go through it together in a final session.
How it is assessed
- Coverage map of entry points and trust boundaries
- Confirmed findings with evidence and reproduction steps
- Correct root cause for each finding
- Severity reasoning a product owner can follow
- Fixes that close the cause, with a test
- Few false positives, clearly separated from open questions
How this course is different
One student, one instructor
Every session is with me, and the plan follows your progress rather than a class timetable.
Real cases, not toy snippets
You review code from published vulnerabilities, including ones I analysed or fixed myself, alongside applications prepared for the course.
Method before tools
Scanners are covered for what they are good at. You learn to judge their output and to find what they cannot model.
Tools you will use
Standards and references
- OWASP Code Review Guide
- OWASP Application Security Verification Standard (ASVS)
- OWASP Cheat Sheet Series
- CWE Top 25 Most Dangerous Software Weaknesses
- NIST SP 800-218, Secure Software Development Framework
Case studies you can read now
- fast-jwt algorithm confusion: fixed on the third try
- CVE-2026-21589: Atlassian’s file read that hides behind ::
- CVE-2024-26855: when a missing attribute becomes a NULL dereference
- After React2Shell: three security boundaries every server component review needs
Questions about this course
Which programming languages do I need?
Labs use TypeScript/Node.js, PHP and Java, with C for the native-code case studies. You need to read one of these comfortably; the method transfers between languages, and we practise that.
How long does it take?
It depends on your starting level and the time you have between sessions. We agree a plan after the initial assessment and adjust it as you progress.
Is this the same as preparing for OSWE?
No. OSWE certifies white-box exploitation through an exam. This course teaches a review method, root-cause analysis and fix quality, under personal supervision. Many skills overlap, and the course is good preparation for any white-box work.
Do I need a commercial scanner?
No. Everything in the course runs on free and open-source tools.
When can I start?
Send a short message about your level and goals. I reply within three days to arrange a free 20-minute assessment call, and we agree your plan and start date after it.
How much does it cost?
Each course costs $1,490 for about 10 one-to-one sessions of 90 minutes, with labs, exercise review, a final assessment and a certificate. Both courses together cost $2,690, and a single 90-minute session costs $150.
How does one-to-one training work?
We meet online for live sessions. Between sessions you work on labs and exercises I set for your level, and in the next session we go through your results. The pace follows your progress, not a fixed timetable.
Which language are the sessions in?
English for international students. Arabic speakers can choose Arabic or English; Arabic sessions keep the English terms you will see in tools, reports and job listings.
Is any of the training in person?
No. All sessions, labs, exercises and feedback are online.
Will I receive a certificate?
You receive a certificate of completion when you pass the final assessment. It is issued by me and is not an industry certification such as OSWE. What an employer can check is the work itself: your final report.
Are the hands-on exercises legal?
Yes. All practical work uses applications I prepared for the course and open-source projects at versions with published advisories, running on your own machine. You never test a system you do not own or have written permission to test.
What if I need more time?
If you need more sessions than planned, each extra session costs $150, and we agree it before it happens.
Next
Continue with the code-assisted web and API penetration testing course.