排查访问修饰符安全漏洞需聚焦“谁该用、谁在用、谁可能滥用”，重点检查default隐性耦合、protected共享存储滥用、public方法缺失校验及反射setAccessible越权穿透。
排查访问修饰符引发的安全漏洞，关键不是逐行检查 public 或 private，而是聚焦“谁该用、谁在用、谁可能滥用”这三个实际协作场景。重点看修饰符是否让不该接触的代码获得了读写权限，尤其在多人维护、模块拆分、第三方集成时容易暴露。
扫描同包内无修饰符（default）成员的隐性耦合
default 修饰符等于向整个包开放读写权，但团队中没人记得谁调用了它。排查时重点关注：
- 搜索项目中所有未加
public/protected/private的字段和方法，尤其是含敏感词的：如context、cache、config、status、data - 检查这些成员是否被多个类直接赋值或修改，绕过了校验逻辑（比如订单状态字段被
RefundProcessor直接设为"CANCELLED"，跳过状态机流转） - 用 IDE 的“Find Usages”功能反查调用链，确认是否仅限本模块内部使用；若跨业务类（如
com.example.order下的PaymentHandler和ReportGenerator都在改同一个pendingOrders列表），就属于边界失效
识别 protected 字段被当共享存储滥用
protected 本意是支持继承扩展，不是给子类建全局 Map。这类问题常导致数据交叉、并发错乱：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 查找所有
protected的可变集合（Map、List、ConcurrentHashMap等）或非final对象引用 - 检查子类是否执行了
put、clear、set等写操作，特别是异步任务中多个子类实例共用同一父类字段 - 验证是否违反“最小暴露”：例如
protected Map<String, Object> context应改为protected void putContext(String key, Object value)，把写入口收束并加校验
审查 public 方法是否缺失校验与契约约束
一个 public 方法一旦发布，就是对外承诺——它会被前端、测试脚本、其他微服务甚至攻击者调用：
立即学习“Java免费学习笔记（深入）”；
- 筛选所有
public的 setter、getter、查询方法（如getAllOrdersForUser、setAmount），逐个确认是否有租户隔离、参数校验、权限判断 - 特别警惕带 ID 参数却未校验归属的方法，例如
public Order getOrderById(Long id)若没校验当前用户能否访问该 ID，就是水平越权温床 - 用静态分析工具（如 Fortify、SonarQube）配置规则：标记无输入校验的
public void setXxx(...)为中高风险项
发现反射中 setAccessible(true) 的越权穿透点
反射强行突破访问控制，是封装性最直接的破坏。排查不能只看有没有用，而要看为什么用、能不能替代：
- 全局搜索
setAccessible(true)，定位所有绕过private/protected的位置 - 区分合理场景（单元测试、框架初始化）和危险场景（业务逻辑中调用私有方法做关键校验、序列化/反序列化时暴力读写敏感字段）
- 优先用标准方式替代：例如用
ReflectionUtils.makeAccessible()（Spring 提供）代替裸setAccessible(true)；更优解是暴露受控接口，而非开放反射后门
