精通 Salesforce 字段级安全性：Apex 与 SOQL 开发人员指南
背景与应用场景
作为一名 Salesforce 开发人员，我们工作的核心不仅仅是构建功能强大的应用程序，更重要的是确保这些应用程序的安全性。在 Salesforce 平台提供的多层安全模型中，Field-Level Security (FLS)，即字段级安全性，是最为精细和常用的一道防线。它决定了用户在特定对象记录中能看到和编辑哪些字段。
想象一个常见的业务场景：在一家公司的销售部门，Opportunity（业务机会）对象上有一个自定义字段叫做 Discount_Percentage__c（折扣百分比）。销售经理有权查看并修改这个字段，而普通的销售代表只能查看，不能修改。同时，市场部门的用户在查看业务机会时，根本不应该看到这个与财务相关的敏感字段。这就是 FLS 的用武之地。通过为不同用户的 Profile（简档）或 Permission Set（权限集）配置不同的字段权限（可见、只读），管理员可以轻松实现这种精细化的数据访问控制。
然而，对于我们开发人员来说，事情并没有那么简单。一个关键且常常被忽视的事实是：Apex 默认在“系统模式” (System Mode) 下运行。这意味着，除非我们显式地进行处理，否则我们的 Apex 代码会无视 FLS 设置，拥有对所有字段的读写权限。这可能导致严重的数据泄露或数据篡改风险。例如，一个为销售代表设计的自定义页面，如果其后端的 Apex 控制器没有正确执行 FLS 检查，就可能允许该销售代表通过代码逻辑修改他本无权编辑的 Discount_Percentage__c 字段。
因此，在 Apex 和 SOQL 中以编程方式强制执行 FLS，是我们作为开发人员必须掌握的核心技能。这不仅是为了构建健壮、可靠的应用程序，更是通过 Salesforce 安全审查、保护客户数据安全的必要条件。
原理说明
要在代码中正确地处理 FLS，我们首先需要理解其背后的工作原理以及 Salesforce 平台为我们提供的工具。核心思想是，在执行任何数据操作（查询或 DML）之前，代码需要主动检查当前运行用户的权限。
1. Apex 的执行上下文：系统模式 (System Mode)
默认情况下，Apex 代码（无论是 Controller、Service Class 还是 Trigger）都在系统模式下运行。这意味着代码执行时，平台不会自动检查当前用户对对象和字段的访问权限。这样设计的初衷是为了让核心业务逻辑能够顺利执行，而不会因为某个用户的权限不足而中断。但这也将实施安全控制的责任交到了开发人员手中。
2. SOQL 中的 `WITH SECURITY_ENFORCED` 子句
这是 Salesforce 近年来推出的一个强大功能，也是目前在 SOQL 查询中强制执行 FLS 的首选方法。当你在 SOQL 查询语句中加入 WITH SECURITY_ENFORCED 子句时，该查询会在“用户模式” (User Mode) 的上下文中检查字段权限。如果查询的任何字段是当前用户无权访问的，查询将不会返回数据，而是直接抛出一个 System.QueryException 异常，提示权限不足。这种“快速失败”的机制非常安全，因为它从源头上阻止了未授权的数据读取。
3. Schema Describe 方法
这是检查 FLS 的经典且灵活的方式。通过 Apex 的 Schema 类，我们可以动态地获取任何 SObject 及其字段的元数据描述信息，其中包括权限设置。这组方法为我们提供了极大的控制力，尤其是在处理动态 SOQL 或在执行 DML 操作前进行检查时非常有用。
Schema.DescribeFieldResult.isAccessible(): 检查当前用户是否对该字段有读取权限。Schema.DescribeFieldResult.isCreatable(): 检查当前用户是否可以在创建新记录时为该字段赋值。Schema.DescribeFieldResult.isUpdatable(): 检查当前用户是否可以更新一个已有记录的该字段值。
使用这些方法，我们可以在执行操作前进行精细的逻辑判断，例如，只查询用户可访问的字段，或是在更新前验证用户是否有权修改。
4. `Security.stripInaccessible()` 方法
这是一个非常实用的工具，专门用于 DML 操作前的“数据清理”。当你准备插入或更新一批记录（List）时，可以直接调用 Security.stripInaccessible 方法。该方法会检查当前用户的 FLS，并自动从 SObject 列表中移除用户无权创建或更新的字段。这样处理后的记录列表再执行 DML 操作，就能确保不会因为权限问题而抛出异常，同时也保证了安全性。它比手动逐个字段检查 isCreatable() 或 isUpdatable() 要简洁和高效得多。
示例代码
以下代码示例均来自 Salesforce 官方文档，展示了如何在不同场景下正确实施 FLS 检查。
示例 1: 在 SOQL 中使用 `WITH SECURITY_ENFORCED`
这是最直接的读取数据时强制 FLS 的方法。下面的例子尝试查询联系人的姓名和电话，如果运行该代码的用户对 `Phone` 字段没有读取权限，代码会捕获到异常。
// An example of using WITH SECURITY_ENFORCED in a SOQL query
try {
// The query is performed as the current user.
// If the user doesn't have FLS visibility for the fields, a QueryException is thrown.
List<Contact> cons = [SELECT Id, Name, Phone
FROM Contact
WITH SECURITY_ENFORCED];
// If the query is successful, process the results
for(Contact c : cons){
System.debug('Contact Name: ' + c.Name);
}
} catch (System.QueryException e) {
// Handle the exception, which indicates a field-level security violation
System.debug('FLS check failed. User does not have access to all fields in the query.');
System.debug('Exception details: ' + e.getMessage());
}
示例 2: 使用 Schema Describe 方法检查读取权限
在动态构建 SOQL 查询字符串时，我们无法使用 `WITH SECURITY_ENFORCED`。此时，需要手动检查字段的 `isAccessible()` 状态。
// Dynamically check FLS for a list of fields before building a SOQL query
String objectName = 'Account';
List<String> fieldNames = new List<String>{'Name', 'AnnualRevenue', 'OwnerId'};
List<String> accessibleFields = new List<String>();
// Get the field map for the Account object
Map<String, Schema.SObjectField> fieldMap = Schema.getGlobalDescribe().get(objectName).getDescribe().fields.getMap();
// Iterate through the desired fields and check for accessibility
for (String fieldName : fieldNames) {
if (fieldMap.get(fieldName).getDescribe().isAccessible()) {
accessibleFields.add(fieldName);
}
}
// Only query the fields the user has access to
if (!accessibleFields.isEmpty()) {
String query = 'SELECT ' + String.join(accessibleFields, ',') + ' FROM ' + objectName + ' LIMIT 10';
List<sObject> records = Database.query(query);
System.debug(records);
} else {
System.debug('The user does not have access to any of the requested fields.');
}
示例 3: 使用 `Security.stripInaccessible()` 清理 DML 数据
这是在执行 DML 操作前确保 FLS 合规性的最佳实践。该方法优雅地处理了权限问题，避免了 DML 异常。
// Prepare a list of records for an update operation
List<Account> accounts = [SELECT Id, Name, AnnualRevenue, TickerSymbol FROM Account LIMIT 2];
for (Account acc : accounts) {
// Attempt to modify fields. The running user may not have permission to update all of them.
acc.AnnualRevenue = 500000;
acc.TickerSymbol = 'CRM';
}
// Use stripInaccessible to remove fields that the user cannot update
// The SObjectAccessDecision object contains information about which fields were removed.
SObjectAccessDecision decision = Security.stripInaccessible(
AccessType.UPDATABLE,
accounts);
// Now, perform the DML operation on the sanitized list of records.
// This update will not fail due to FLS violations.
try {
update decision.getRecords();
} catch (DmlException e) {
// Handle other potential DML errors
System.debug('An error occurred during DML operation: ' + e.getMessage());
}
// You can also inspect which fields were removed for logging or debugging
System.debug('Fields removed by stripInaccessible: ' + decision.getRemovedFields());
注意事项
- 权限和 API 限制:
Schema Describe 调用会消耗系统资源，并计入 Apex CPU 时间限制。在循环中反复调用 `getDescribe()` 是一个常见的性能瓶颈。最佳实践是在事务开始时，一次性获取所有需要的对象和字段描述信息，并将其缓存在 Map 中以供后续使用。
- 错误处理:
当使用
WITH SECURITY_ENFORCED时，必须使用try-catch块来捕获System.QueryException。向用户显示一个友好的错误消息（例如，“您没有查看所有必需数据的权限”），而不是让他们看到一个未处理的异常页面，这是至关重要的用户体验。 - `WITH USER_MODE` vs `WITH SECURITY_ENFORCED`:
需要注意的是，还有一个类似的子句
WITH USER_MODE。WITH SECURITY_ENFORCED仅检查字段级和对象级安全性。而WITH USER_MODE则更为全面，它同时检查字段级、对象级以及记录级共享规则 (Sharing Rules)。在需要同时考虑共享规则的场景下，应使用WITH USER_MODE。 - 复合字段 (Compound Fields):
对于地址（如
BillingAddress）或地理位置（如Location__c）等复合字段，其访问权限由其所有组件字段的权限共同决定。例如，用户必须同时对BillingStreet、BillingCity、BillingState等所有地址组件字段拥有读取权限，才能在 SOQL 中查询BillingAddress。 - 安全审查 (Security Review):
如果你正在为 AppExchange 开发应用程序，那么在代码中强制执行 FLS 是 Salesforce 安全审查的强制要求。任何没有正确实施 FLS 检查的 DML 操作或数据显示都将导致你的应用无法通过审查。
总结与最佳实践
作为 Salesforce 开发人员，我们必须将安全性作为编码的第一原则，而正确处理 Field-Level Security 是其中的基石。忽略 FLS 不仅会带来安全风险，还会导致糟糕的用户体验和无法通过 AppExchange 的安全审查。
以下是总结的最佳实践：- 优先使用 `WITH SECURITY_ENFORCED`: 对于所有静态 SOQL 查询，这应该是你强制执行 FLS 的首选。它代码简洁、意图明确，并且能安全地“快速失败”。
- DML 操作前使用 `Security.stripInaccessible()`: 在执行 `insert`、`update` 或 `upsert` 之前，使用此方法来清理 sObject 列表。这是确保 DML 操作符合用户 FLS 权限的最可靠、最高效的方法。
- 谨慎使用 Schema Describe: 当你需要动态构建查询、在用户界面上根据权限动态显示/隐藏字段，或者需要对权限检查进行非常复杂的逻辑控制时，Schema Describe 方法是你的强大后盾。但务必注意其性能开销。
- 始终包含错误处理: 任何执行安全检查的代码都可能因为权限不足而失败。通过健壮的 `try-catch` 逻辑来优雅地处理这些异常，为用户提供清晰的反馈。
- 使用 `SObjectField` 令牌: 在进行 Schema Describe 检查时，使用 `Account.AnnualRevenue` 这样的 `SObjectField` 令牌，而不是硬编码的字符串 `'AnnualRevenue'`。这能让编译器在编译时就发现字段拼写错误，提高代码的健壮性。
- 全面测试: 编写的代码一定要使用不同权限的测试用户进行测试。创建一个没有字段访问权限的简档，并以该用户身份运行你的代码，以确保安全控制按预期工作。
通过遵循这些原则和实践，我们可以编写出既功能强大又安全可靠的 Apex 代码，充分利用 Salesforce 平台的分层安全模型，为客户构建值得信赖的应用程序。
评论
发表评论