Would you voluntarily spend another five hours on this kind of problem? Why?
Application Security · 75–120 min
Threat-model and protect one tiny feature
Experience application security as design, evidence, a fix and regression protection—not scanner output.
Start the experiment01 · Setup
What you need
- A tiny local app you own with one form or API and source access, already set up. Work only on that app or an explicitly authorized training lab; never test a public target.
You may stop when the timebox ends. An incomplete result is still useful evidence.
02 · Task
The work sequence
- 01
Draw the feature's browser/client, server and data store. Mark user-controlled input, identity, sensitive data and every trust-boundary crossing.
- 02
Write three abuse cases in the form ‘someone could… causing…’. Rank them by plausible impact and likelihood in this local system.
- 03
Choose one input-validation or authorization risk. Reproduce it only with harmless fictional data and record exact evidence; stop if the scope is unclear.
- 04
Implement the smallest server-side fix and one regression test that fails before the fix and passes after it. Do not rely only on client-side validation.
- 05
Write a short report: authorized scope, threat, evidence, impact, fix, verification and remaining risk. Ask a peer to review the reasoning without sharing secrets.
03 · Pay attention
Watch your reaction, not only the output
- Did preventing the weakness feel as interesting as finding it?
- Can you explain the risk without exaggeration, blame or a vulnerability score alone?
Plot twist
Difficulty does not mean the career is a bad fit. The useful question is whether curiosity returned after the difficulty.
04 · Reflect
Three honest questions
Which part gave you energy, and which part drained it?
What evidence—not a salary video—would you gather before choosing this path?
This site does not save your answers. Put them in your own notebook if useful.
05 · Where to go next