API revision approve has no pending-status precondition and no self-approval guard

Area: mobieusKnow (audit p6) · Surface: POST /api/v1/know/revisions/{id}/approve (KnowledgeApiController@revisionsApprove) · Dimension: security · Severity: minor

OWASP A04:2021 Insecure Design. The API can re-'approve' an already-rejected or already-approved revision (resurrecting rejected content and re-pointing current_revision_id at it), and lets an author rubber-stamp their own edit. The web moderation flow explicitly prevents both.

Evidence

revisionsApprove (KnowledgeApiController.php:196-210) fetches the revision then unconditionally `UPDATE knowledge_revisions SET status = "approved", reviewed_by = :r ...` with no check that the current status is 'pending' and no check that the reviewer (key creator) differs from the author. The web path guards both: KnowledgeController::approveRevision (393-396) `if (!$rev || $rev['status'] !== 'pending')` and KnowledgeRevision::approve (KnowledgeRevision.php:73) selects `WHERE id = :id AND status = 'pending'`. notifyContributor (KnowledgeController.php:447) also skips self-approval; the API has no equivalent.

Suggested fix. Require status='pending' before approving (`WHERE id=:id AND status='pending'`), and enforce reviewer != author unless the key explicitly carries a moderator/elevated scope.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.