如果您的代码是不会被其他代码调用的应用程序的一部分，那么安全性很简单，并且可能不需要特殊的编码。但请记住，恶意代码可以调用您的代码。虽然代码访问安全性机制可以阻止恶意代码访问资源，但此类恶意代码仍然可以读取可能包含敏感信息的字段或属性的值。
此外，如果您的代码可以从 Internet 或其他不可靠的来源接受用户输入，则必须小心恶意输入。
有关详细信息，请参阅本文的确保状态数据的安全和用户输入。
本机代码实现的托管包装程序通常在此情况下，某些有用的功能是在本机代码中实现的，并且您想在不改写它的情况下将其用于托管代码。托管包装程序很容易编写为平台调用或使用 COM 互操作。但是，如果您这样做，包装程序的调用方必须拥有非托管代码的权利，调用才能成功。在默认策略下，这意味着从 Intranet 和 Internet 下载的代码将不会与包装程序配合工作。
更好的方法是将这些非托管代码权利只授予包装程序代码，而不要授予使用这些包装程序的所有应用程序。如果基础功能很安全（不公开任何资源）并且实现也很安全，则包装程序只需要断言它的权利，这将使任何代码都能够通过它进行调用。如果涉及到资源，则安全编码应与下一部分中描述的库代码情况相同。因为包装程序向调用方潜在地公开了这些问题，所以需要对本机代码的安全性进行仔细验证，这是包装程序的责任。
有关详细信息，请参阅本文的非托管代码和评估权限部分。
公开受保护资源的库代码这是功能最强大因此也是潜在最危险（如果方法不正确）的安全编码方式：您的库充当了其他代码用来访问特定资源（这些资源以其他方式是不可用的）的接口，正如 .NET 框架类对它们所使用的资源施加权限一样。无论在哪里公开资源，代码都必须先请求适用于资源的权限（即，执行安全检查），然后通常需要断言它执行实际操作的权利。
有关详细信息，请参阅本文的非托管代码和评估权限部分。
安全编码的最佳做法注 除非另行指定，代码示例都是用 C# 编写的。
权限请求是使代码获得安全性的好方法。这些请求可让您做两件事：
•请求代码运行所必需的最低权限。
•确保代码所接收的权限不会超过它实际需要的权限。
例如：
[assembly:FileIOPermissionAttribute (SecurityAction.RequestMinimum, Write="C:\\test.tmp")] [assembly:PermissionSet (SecurityAction.RequestOptional, Unrestricted=false)] …SecurityAction.RequestRefused_
文章来源于领测软件测试网 https://www.ltesting.net/
