1 min lesson
The three seeded flaws
Choose two examples from the table in "The three seeded flaws" and explain what each teaches you to do.
Step 1 of 2
The three seeded flawsWhat review should surface
- Flaw
- Broken object-level authz (IDOR)
- Where
- No check that
req.userowns invoiceid - Impact
- Any authed user reads any invoice by guessing IDs
- Severity
- Critical
- Flaw
- SQL injection
- Where
idconcatenated into the query string- Impact
- Full read/write of the DB, auth bypass, data exfil
- Severity
- Critical
- Flaw
- Secret in logs
- Where
STRIPE_SECRETwritten to stdout- Impact
- Live key leaks to log aggregation, on-call screens, retention
- Severity
- High
| Flaw | Where | Impact | Severity |
|---|---|---|---|
| Broken object-level authz (IDOR) | No check that req.user owns invoice id | Any authed user reads any invoice by guessing IDs | Critical |
| SQL injection | id concatenated into the query string | Full read/write of the DB, auth bypass, data exfil | Critical |
| Secret in logs | STRIPE_SECRET written to stdout | Live key leaks to log aggregation, on-call screens, retention | High |
Rank by impact and exploitability, then fix the criticals first.
Prioritize the way the review system does. The SQLi and the IDOR are both critical and trivially exploitable, so they block the PR. The logged secret is high, separately tracked because it needs a key rotation, not just a code change - the key is already compromised the moment it hits a log.