AutoCore RBAC Auditability and Testing
Provides a testable model for roles, permissions, ownership, and high-risk actions.
Authorization tests should exercise direct API calls as well as the Admin UI. The evidence should distinguish authentication failures, missing permissions, ownership denial, invalid state, and configuration-disabled behavior.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Matrix | Test each sensitive operation with the intended role, a lower role, an unrelated dealer member, and an unauthenticated caller. |
| Mutation | Role changes, session actions, provider actions, refunds, and integrity repairs require audit evidence. |
| Protection | Super-admin grant/revoke and self-demotion safeguards are explicit test cases. |
| Negative path | A hidden UI control must still fail when called directly without authorization. |
| Evidence | Keep route, role, permission, resource scope, result, and audit ID without private user data. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.