Search docs

Docs search
Back to Rule Catalog
AP-AUTH-003Authorization

Authorization 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

  1. Move authorization to the request guard, policy service, or application service boundary.
  2. Keep persistence methods free of caller-role decisions.
  3. 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/src
  • apps/web/app/api
  • packages/db/prisma/schema.prisma

Related CLI commands

  • archpilot validate
  • archpilot validate --ci
AP-AUTH-003 - Authorization logic placed in wrong layer | ArchPilot Docs