Authorized Attributes Laravel Package

Technical Evaluation

Architecture fit: The package adds attribute-level (field-level) authorization to Eloquent models — a capability Laravel only partially covers with $hidden/$visible and controller-level Gate checks. It targets a real gap: deciding, per authenticated user, which model fields may be read or written (e.g., salary, ssn, internal admin columns). Architecturally this is a thin, additive layer: one or more traits on models plus a policy/ability contract that hooks into Laravel's existing Gate system. That is a good fit for apps that already centralize authorization in Policies and expose data through APIs. The main friction points are the serialization surface (toArray, toJson, API Resources, JsonResource collections) and the boundary between package-level attribute filtering and Laravel's own fillable/hidden/guarded semantics — a TPM must confirm the two don't disagree.

Integration feasibility: Composer-installable, Laravel package auto-discovery, MIT license. With 0 dependents and 23 stars there is essentially no ecosystem validation, so feasibility rests on a time-boxed proof of concept rather than reputation. The scope appears small enough that a spike can answer the critical questions in a day or two.

Technical risk: Three risks dominate. First, fail-open behavior — if authorization is applied on read but not write, or if it is silently skipped when a policy is missing, you leak sensitive fields; this is the difference between a bug and an incident. Second, bypass surface — attribute authorization at the model layer does nothing for raw query builder usage, DB::table() reads, or third-party consumers that hydrate models directly; the effective coverage is narrower than it looks. Third, behavioral coupling with serialization — if the package overrides toArray/attributesToArray, it can conflict with casts, accessors, API Resources, and existing $hidden rules, producing subtle output changes. Low star count and single-org ownership also mean unknown test coverage and unproven Laravel 11/12 compatibility.

Key questions:

• Which Laravel and PHP versions are supported, and is there CI proving it against the current LTS?
• Does it enforce write authorization (mass assignment) as well as read, or read only?
• What is the failure mode when no policy/ability exists for an attribute — deny by default or allow?
• How does it compose with $hidden, $visible, $fillable, API Resources, and JsonResource?
• Is authorization evaluated per attribute per model instance (N×M Gate calls), and is there a caching or precomputation path?
• Does it support attribute groups/wildcards and per-role matrices, or only per-attribute abilities?
• Is there published documentation and a test suite we can audit?

Integration Approach

Stack fit: Best suited to a Laravel + Eloquent + API-Resource stack with Sanctum/Passport and a policy-driven authorization culture (possibly Spatie permissions). It is a poor fit for apps that serialize models ad hoc, expose models directly from controllers, or rely heavily on query-builder reads outside Eloquent.

Migration path: Do not retrofit across the domain. Start with one bounded context where field sensitivity is already a known concern (e.g., a User or Employee resource), wrap the model in the package's trait, and express existing $hidden/controller-scoped logic as attribute abilities. Compare output byte-for-byte against current API responses to catch serialization drift, then expand model by model.

Compatibility: Pin the package and verify against the app's PHP and Laravel versions in CI before adoption. Watch specifically for interaction with casts, accessors/mutators, API Resource when()/whenHas() logic, and any global scopes. Keep Laravel's native $hidden as the last line of defense rather than relying solely on the package.

Sequencing:

1. Source review and test-suite audit (fail-closed check, write-path check).
2. One-day spike on a non-production branch against a single model.
3. Contract tests asserting both allowed and denied fields for representative users/roles, including a "no policy defined" case.
4. Roll out to one read endpoint behind a feature flag; monitor serialization diffs.
5. Extend to write/mass-assignment paths only after read-path behavior is proven.
6. Decide fork-vs-depend based on audit findings.

Operational Impact

Maintenance: The primary long-term cost is the dependency's lifecycle, not its code. A single-org, 23-star package with no dependents carries meaningful abandonment risk and no external pressure to keep pace with Laravel majors. MIT licensing means we can vendor/fork if needed, but that converts an external dependency into an owned one — budget for that outcome in the adoption decision.

Support: Expect self-support. No community, thin issue history, and answers will come from reading source. Any production issue lands on our on-call, not the maintainer's.

Scaling: Attribute-level checks imply repeated authorization calls on hot serialization paths. At low traffic this is invisible; at scale it becomes an N×attributes×models Gate-call multiplier. Confirm whether abilities are memoized per request and whether policy lookups hit the DB. For high-volume list endpoints, prefer explicit API Resources over model-level filtering.

Failure modes:

• Silent field leak (highest severity): missing policy or fail-open default exposes sensitive attributes — treat as a security incident class.
• Bypass: non-Eloquent reads and direct DB access bypass enforcement entirely.
• Breaking output changes: serialization overrides alter API contracts for existing consumers.
• Upgrade breakage: Laravel major upgrades outpace package maintenance.
• Performance regression: per-attribute authorization on collection serialization.

Ramp-up: Low. The package surface is small and the concepts map onto Laravel authorization that the team already knows; a mid-level Laravel engineer can be productive in under a day. The real ramp is organizational: establishing the discipline that sensitive fields are declared in one place and that reviewers check attribute policies on every model change.

TPM recommendation: Adopt only after a time-boxed source audit confirming fail-closed behavior and write-path enforcement, then pilot on one sensitive model behind a flag. If the audit is inconclusive, the safer path is a small in-house trait backed by Laravel Gates — the concept is sound, but at 23 stars with zero dependents the package's value is in the pattern, not the provenance.