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, the 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 and write of the DB, plus data exfiltration
- Severity
- Critical
- Flaw
- Secret in logs
- Where
STRIPE_SECRETwritten to stdout- Impact
- Live key leaks to log aggregation and on-call screens, then sits in retention
- Severity
- High
| Flaw | Where | Impact | Severity |
|---|---|---|---|
| Broken object-level authz, the 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 and write of the DB, plus data exfiltration | Critical |
| Secret in logs | STRIPE_SECRET written to stdout | Live key leaks to log aggregation and on-call screens, then sits in retention | High |
Rank by impact and exploitability, then fix the criticals first.
Prioritize by impact and exploitability. The SQLi and the IDOR are both critical and trivially exploitable, so they block the PR. The logged secret is high and tracked separately, because it needs a key rotation, not just a code change. The key is already compromised the moment it hits a log.