ddadminandClaude Opus 4.6
515820abed
Fixes from adversarial code-vs-plan review (3 rounds): - Verdict format in prompts now matches parser (bare tokens) - Missing verdict treated as parse failure, not approval - README: softened backend swappability to "designed for extensibility" - Example: replaced incorrect FK scenario with valid transaction bug - Example: aligned fixes and round-2 summary with round-1 finding Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
78 lines
2.7 KiB
Markdown
78 lines
2.7 KiB
Markdown
# Example: Adversarial Code Review Output
|
|
|
|
This is a synthetic example showing what a typical adversarial review looks like.
|
|
|
|
---
|
|
|
|
## Adversarial Review — Round 1 (mode: code, model: gpt-5.4)
|
|
|
|
## Summary
|
|
|
|
This change adds a user deletion endpoint to the API. The endpoint accepts
|
|
a user ID, deletes the user record, and returns 204. The implementation
|
|
handles the happy path correctly but has two significant issues around
|
|
data integrity and authorization.
|
|
|
|
## Findings
|
|
|
|
### [severity: critical] User deletion without transaction leaves partial state on failure
|
|
|
|
- **File:** src/api/users.py lines 45-52
|
|
- **What can go wrong:** The `delete_user()` function deletes from `sessions`,
|
|
`orders`, and `users` in three separate queries without a transaction.
|
|
If the process crashes or the DB connection drops after deleting sessions
|
|
but before deleting the user, the user record persists with missing session
|
|
history. There is no retry or cleanup mechanism.
|
|
- **Why vulnerable:** The function calls `db.sessions.delete(user_id)`,
|
|
`db.orders.delete(user_id)`, and `db.users.delete(user_id)` sequentially
|
|
without wrapping them in `db.transaction()`.
|
|
- **Impact:** Data loss. Partial deletion leaves the database in an
|
|
inconsistent state that requires manual intervention to fix.
|
|
- **Recommendation:** Wrap all three deletes in a single transaction:
|
|
`with db.transaction(): ...`. If any step fails, the entire operation
|
|
rolls back.
|
|
|
|
### [severity: high] Missing authorization check on delete endpoint
|
|
|
|
- **File:** src/api/users.py lines 38-40
|
|
- **What can go wrong:** Any authenticated user can delete any other user
|
|
by sending `DELETE /api/users/{id}`. The endpoint checks authentication
|
|
(`@require_auth`) but not authorization — there is no admin role check
|
|
or ownership validation.
|
|
- **Why vulnerable:** The route decorator only has `@require_auth`, not
|
|
`@require_role('admin')`. The `user_id` parameter comes from the URL
|
|
path and is never compared to the authenticated user's ID.
|
|
- **Impact:** Privilege escalation. Any logged-in user can delete
|
|
arbitrary accounts including admins.
|
|
- **Recommendation:** Add `@require_role('admin')` decorator, or if
|
|
self-deletion is intended, verify `request.user.id == user_id`.
|
|
|
|
## Verdict
|
|
|
|
VERDICT: REVISE
|
|
|
|
---
|
|
|
|
### Fixes (Round 1)
|
|
|
|
- Wrapped all three deletes (`sessions`, `orders`, `users`) in `db.transaction()`
|
|
- Added `@require_role('admin')` to the delete endpoint
|
|
- Added test for unauthorized deletion attempt (returns 403)
|
|
|
|
---
|
|
|
|
## Adversarial Review — Round 2 (mode: code, model: gpt-5.4)
|
|
|
|
## Summary
|
|
|
|
Both issues from round 1 are resolved. The transaction wraps all deletes
|
|
atomically and the authorization check is in place. No new issues found.
|
|
|
|
## Findings
|
|
|
|
No actionable findings.
|
|
|
|
## Verdict
|
|
|
|
VERDICT: APPROVED
|