eloquent 的 getattribute、setattribute 和访问器/修改器不提供安全边界，需通过输入验证、模型层钩子、api resource 白名单实现纵深防御，$hidden 和 $fillable 无法单独保障属性安全。
直接说结论：Eloquent 的 getAttribute、setAttribute 和访问器/修改器（accessor/mutator）本身不提供安全边界，所谓“Attribute Security States”不是 Laravel 内置概念，而是开发者需主动设计的纵深防御环节——关键在数据流出前过滤、写入时校验、敏感字段显式隔离。
哪些属性会意外暴露？$hidden 和 $casts 不够用
常见错误是以为设了 $hidden = ['password', 'api_token'] 就万事大吉。但以下场景仍可能泄露：
-
toArray()或json_encode($model)会绕过$hidden（如果模型被强制转数组且未调用makeHidden()） -
$casts只影响类型转换，不阻止原始值被读取（比如'is_admin' => 'boolean'不防 SQL 注入或越权读取） - 使用
getAttributes()直接获取全部原始属性，包括被隐藏字段 - 序列化时若未禁用
$appends中的敏感计算字段（如full_name拼接了身份证号）
怎么安全地控制属性读写？用 getAttribute + isDirty + 显式白名单
不要依赖魔术方法自动处理敏感逻辑。应在业务层明确拦截：
- 重写
getAttribute($key)：对敏感键（如'password_hash'）返回null或抛异常，而非让父类默认返回 - 写入前检查：
if ($this->isDirty('email') && ! $this->isValidEmail($this->email)) { throw new ValidationException(); } - 对外输出一律走白名单：
array_only($user->toArray(), ['id', 'name', 'avatar_url'])，而不是$user->toArray() - 避免在
toArray()中动态追加敏感字段；改用独立方法如public function toPublicArray()
为什么不能只靠 protected $fillable？massAssignment 漏洞仍在
$fillable 仅防批量赋值（create() / update()），但以下情况仍危险：
- 手动调用
$user->password = $input['password'];—— 绕过$fillable - 使用
fill()时传入用户可控数组，且未清理键名（如$user->fill(request()->all())） -
$guarded = []等价于允许所有字段，比留空更危险 - Laravel 10+ 默认启用
forceFill()保护，但开发者显式调用它时会跳过所有防护
真正起作用的纵深防御组合
单一机制必破。必须叠加三层：
- 输入层：Form Request 验证 +
request()->validate()强制字段白名单（如'email' => 'required|email'） - 模型层：重写
setAttribute对敏感字段加钩子（如if ($key === 'role') { throw_if(! auth()->user()->can('assign_role'), UnauthorizedException::class); }） - 输出层：API Resource 类中显式定义
return ['id' => $this->id, 'name' => $this->name]，绝不直接 return $this->resource
最易被忽略的是：Resource 类里调用 $this->when(...) 时，闭包内若用了未授权的属性（如 $this->password_hash），依然会触发 getter 并执行逻辑——哪怕字段没出现在最终 JSON 里。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
