对于ADO.NET连接相关措施，这些攻击来自使用运行此代码的用户的权限执行的恶意代码， 其他攻击可能源自被攻击者利用的善意代码。 在规划安全性时，始终假设将出现最糟糕的情况。

您可以使用的一种措施是：尝试使用最小特权来运行代码，在代码周围树立尽可能多的障碍。 最小特权原则指出，ADO.NET连接应在完成工作所需的最短时间内向所需的最少代码授予任何给定的特权。

ADO.NET连接创建安全应用程序的最好方法是在开始阶段不授予任何权限，然后对执行的特定任务添加最有限的权限。 相反，ADO.NET连接如果开始具有所有权限而以后拒绝个别权限，就会导致难以测试和维护的不安全应用程序，因为无意中授予过多的权限会造成完全漏洞。#t#

连接到 Microsoft SQL Server 后，您便可以使用 Windows 身份验证（也称为集成安全），ADO.NET连接使用当前活动 Windows 用户的标识，而不是传递用户 ID 和密码。由于不会在连接字符串中公开用户凭据，因此强烈建议使用 Windows 身份验证。如果无法使用 Windows 身份验证连接到 SQL Server，请考虑使用 SqlConnectionStringBuilder 在运行时创建连接字符串。

用于身份验证的凭据需要根据应用程序的类型进行不同地处理。例如，ADO.NET连接在 Windows 窗体应用程序中，可以提示用户提供身份验证信息，也可以使用用户的 Windows 凭据。但是，Web 应用程序通常使用应用程序自身提供的凭据来访问数据，而不是使用用户提供的凭据。

（而不是作为 Transact-SQL 语句的一部分）进行传递，参数化命令可抵御 SQL 注入攻击。这样，便不会在数据源中执行插入到值中的 Transact-SQL 命令。相反，只会将这些命令作为参数值来计算。除具备安全优势外，参数化命令还提供一种便捷方法，使用该方法可组织随 Transact-SQL 语句传递或传递到存储过程的值。#t#

当具有最少的安全要求或没有安全要求时，Microsoft Access 和 Microsoft Excel 可充当 ADO.NET连接应用程序的数据存储区。其安全功能作为一种阻止手段固然有效，但其作用仅限于阻止不了解情况的用户乱摸乱动而已。Access 和 Excel 的物理数据文件位于文件系统上，并且注定可供所有用户访问。

这使得这些文件易受到攻击，从而导致文件失窃或数据丢失，ADO.NET连接因为他人可轻松复制或更改这些文件。如果需要强有力的安全措施，请使用 SQL Server 或其他基于服务器的数据库，这样便无法从文件系统读取物理数据文件。