Search docs
Docs searchValidation rule
Back to Rule CatalogAP-AUTH-003AuthorizationAuthorization logic placed in wrong layer
Flags authorization logic placed in a layer that makes enforcement hard to reuse or audit.
warningviolationNo auto-fix
How to fix
- Move authorization to the request guard, policy service, or application service boundary.
- Keep persistence methods free of caller-role decisions.
- Retain UI gating only as presentation feedback, not enforcement.
What it means
Authorization decisions appear in persistence, presentation, or miscellaneous helper code instead of the expected boundary.
Why it matters
Authorization should be visible and reusable at stable request or service boundaries.
Common causes
- Role checks were embedded in repositories.
- UI-only checks were treated as server authorization.
- Authorization branches were added inside generic utilities.
Example bad pattern
A repository checks whether the current user is an admin before returning rows.Example good pattern
The route/service checks admin access, then calls a repository with scoped inputs.Related files/config
apps/api/srcapps/web/app/apipackages/db/prisma/schema.prisma
Related CLI commands
archpilot validatearchpilot validate --ci
Related docs