我已经看到您可以使用反射来操纵私有和内部成员。我还看到它说“密封”类比非密封类更安全。
修饰符“public、protected、internal、private、abstract、sealed、readonly”是否仅仅是关于设计和 API 使用的君子协议，只要您可以访问反射就可以打破？如果黑客已经在运行调用你的 API 的代码，那么游戏就已经失败了，对吧？
以下是否比任何其他类更安全？
//private class
sealed class User
{
private string _secret = "shazam";
public readonly decimal YourSalary;
public string YourOffice{get;};
private DoPrivilegedAction()
{
}
}
首先，回答您的问题：安全系统旨在保护好用户免受不良代码的侵害；它显然不是为了保护GOOD CODE 免受 BAD USERS的影响。您的访问限制减轻了部分受信任的恶意代码对您的用户的攻击。它们不会减轻敌对用户对您的代码的攻击。如果威胁是恶意用户获取您的代码，那么您就有大问题了。安全系统根本无法减轻这种威胁。
其次，要解决之前的一些答案：理解反射和安全之间的完整关系需要仔细注意细节并很好地理解 CAS 系统的细节。先前发布的答案指出，由于反射，安全性和访问之间没有联系，这是误导和错误的。
是的，反射允许您覆盖“可见性”限制（有时）。这并不意味着访问和安全之间没有联系。联系是使用反射覆盖访问限制的权利与CAS系统有多种方式的深度联系。
首先，为了任意这样做，代码必须获得 CAS 系统的私有反射权限。这通常只授予完全受信任的代码，毕竟这些代码已经可以做任何事情了。
其次，在新的 .NET 安全模型中，假设程序集 A 被 CAS 系统授予程序集 B 的授权集的超集。在这种情况下，程序集 A 中的代码可以使用反射来观察 B 的内部。
第三，当您将动态生成的代码加入其中时，事情变得非常复杂。解释“Skip Visibility”与“Restricted Skip Visibility”是如何工作的，以及它们如何改变反射、访问控制和安全系统之间的交互，在运行时代码被吐出的情况下，这将花费我比我更多的时间和空间有可用的。如果您需要详细信息，请参阅 Shawn Farkas 的博客。
访问修饰符不是关于安全性，而是良好的设计。类和方法的适当访问级别驱动/实施良好的设计原则。理想情况下，反射应该只在使用它的便利性比违反（如果有的话）最佳设计实践的成本提供更多效用时使用。密封类仅用于防止开发人员扩展您的类并“破坏”它的功能。关于密封类的实用性有不同的看法，但由于我做 TDD 并且很难模拟密封类，所以我尽可能避免它。
如果您想要安全，您需要遵循防止坏人进入和/或保护机密信息不被检查的编码实践，即使发生入侵也是如此。入侵防御、入侵检测、加密、审计等是您需要使用的一些工具来保护您的应用程序。设置限制性访问修饰符和密封类与应用程序安全性无关，IMO。
不，这些与安全无关。反射打破了它们。
关于反射和安全性的评论 - 考虑到 mscorlib.dll 中有许多内部类型 + 成员调用本机 Windows 函数，如果恶意应用程序使用反射调用它们，可能会导致不良后果。这不一定是问题，因为不受信任的应用程序通常不会被运行时授予这些权限。这（以及一些声明性安全检查）是 mscorlib.dll 二进制文件如何将其类型公开给各种受信任和不受信任的代码，但不受信任的代码无法绕过公共 API。
这实际上只是触及了反射+安全问题的表面，但希望它足以引导您走上正确的道路。
我总是试图将事情锁定在所需的最小访问权限内。就像 tvanfosson 所说，这实际上是关于设计而不是安全性。
例如，我将公开一个接口，以及我的内部实现，然后是一个公共工厂类/方法来获取实现。这几乎迫使消费者始终将其键入为接口，而不是实现。
话虽如此，开发人员可以使用反射来实际实例化实现类型的新实例。没有什么能阻止他/她。但是，我可以放心，因为我让违反设计至少有些困难。