静态代码分析警告CA2104为何属于安全问题而非代码质量问题？

你提到的这个疑问非常合理——乍看之下把可变类型标记为readonly确实更像数据完整性或代码质量问题，而非安全漏洞。但微软将CA2104归类为安全警告，核心原因是这种写法很容易在涉及信任边界、敏感数据的场景下引发可被利用的安全风险，而不只是内部逻辑的小问题。具体来说，主要有这几个关键场景：

• 跨信任域的敏感数据篡改：如果你的代码是被外部不受信任的代码（比如第三方插件、其他类库）引用的类库，当你把一个可变对象（比如List<string>、自定义的UserSettings类）标记为readonly字段时，外部代码虽然无法重新赋值这个字段，但可以直接修改对象的内部属性或调用其可变方法。举个例子：如果这个readonly字段存储的是系统权限列表，不受信任的代码可以直接调用Add方法给自己添加管理员权限，这就直接绕过了权限控制，构成了典型的权限提升漏洞。

• 错误的安全信任假设：readonly修饰符会给开发者传递“这个字段的内容不可变”的信号，后续维护代码的人（包括未来的你）可能会基于这个假设编写安全校验逻辑。比如，假设某个接口的访问权限依赖于readonly对象的IsAdmin属性，但实际上这个属性可以被任意修改，那原本的权限校验就完全失效了，导致未授权用户能访问敏感资源。这种基于错误假设的安全逻辑，本质上就是安全漏洞。

• 多线程环境下的状态不一致风险：即使是在内部代码中，readonly的可变对象在多线程场景下可能被并发修改。如果这个对象存储的是与安全相关的状态（比如当前会话的用户权限、加密密钥的缓存），线程间的意外修改可能导致状态混乱——比如一个线程刚完成权限校验，另一个线程就修改了权限值，导致后续操作越权执行敏感操作。

总结一下：CA2104的警告确实兼顾了代码质量，但被归为安全问题，是因为它的存在会破坏开发者对“不可变安全状态”的信任，并且在跨信任边界的场景下很容易被恶意利用，进而引发权限提升、数据篡改等直接的安全风险。

内容的提问来源于stack exchange，提问作者Dave