FAQ-000744 - Data Synchronization Security / Metadata Security for Sync

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are the security-compliant methods for retrieving field metadata for dynamic object synchronization?
Answer
To ensure security compliance when retrieving field metadata for dynamic object synchronization, follow these methods: 1. **Use `Schema.sObjectType`**: Access metadata for objects and fields using `Schema.sObjectType`. This ensures validated object and field names, reducing the risk of SOQL injection. 2. **Perform CRUD and FLS Checks**: Explicitly check Create, Read, Update, Delete (CRUD) and Field-Level Security (FLS) permissions. For example, use `Schema.sObjectType.<ObjectName>.getDescribe().isAccessible()` to verify field accessibility before operations. 3. **Avoid Dynamic SOQL/SOSL with Strings**: Instead of constructing queries with strings, use `sObjectType` or `sObjectFields` to build secure and permission-enforced queries. 4. **Manually Validate Fields in Queries**: For dynamic queries, validate fields used in WHERE or ORDER BY clauses, as the `WITH SECURITY_ENFORCED` clause does not cover these. 5. **Use `StripInaccessible`**: Filter out fields that the current user cannot access to ensure compliance with security policies. 6. **Secure Metadata Operations**: Perform metadata-related operations in a secure context to avoid exposing sensitive information. These practices help maintain security compliance while synchronizing dynamic object metadata.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexSOQLInjectionApexCRUDViolation
Question
What are the security-compliant methods for retrieving field metadata for dynamic object synchronization?
Recommended Answer Update
To ensure security compliance when retrieving field metadata for dynamic object synchronization, follow these methods: 1. **Use `Schema.sObjectType`**: Access metadata for objects and fields using `Schema.sObjectType`. This ensures validated object and field names, reducing the risk of SOQL injection. 2. **Perform CRUD and FLS Checks**: Use modern approaches like `WITH USER_MODE` for SOQL queries and `AccessLevel.USER_MODE` for Database methods to automatically enforce permissions. You can also explicitly check Create, Read, Update, Delete (CRUD) and Field-Level Security (FLS) permissions using methods like `Schema.sObjectType.<ObjectName>.getDescribe().isAccessible()` to verify field accessibility before operations. 3. **Avoid Dynamic SOQL/SOSL with Strings**: Instead of constructing queries with strings, use `sObjectType` or `sObjectFields` to build secure and permission-enforced queries. 4. **Manually Validate Fields in Queries**: For dynamic queries, validate fields used in WHERE or ORDER BY clauses, as the `WITH SECURITY_ENFORCED` clause does not cover these. 5. **Use `StripInaccessible`**: Filter out fields that the current user cannot access to ensure compliance with security policies. 6. **Secure Metadata Operations**: Perform metadata-related operations in a secure context to avoid exposing sensitive information. These practices help maintain security compliance while synchronizing dynamic object metadata.
Reasoning
The FAQ content is technically accurate but needs to be updated to prioritize modern security approaches. The main change is in point 2, where I enhanced the existing CRUD and FLS guidance to lead with modern approaches (`WITH USER_MODE` and `AccessLevel.USER_MODE`) while preserving the existing manual permission check example. This follows the security approaches guideline to prioritize modern features over legacy approaches while maintaining that older approaches remain valid. The ApexSOQLInjection rule is relevant because the FAQ discusses avoiding SOQL injection through proper use of Schema.sObjectType and avoiding dynamic string construction in queries - specifically mentioned in points 1 and 3. The ApexCRUDViolation rule applies because the FAQ extensively covers CRUD and FLS permission checking in points 2, 4, and 5, which directly relates to this rule's purpose of detecting missing CRUD/FLS checks.
Reasoning References
Recommended Related Articles