FAQ-000069 - API Security and Metadata Access / Dynamic Code Generation and Deployment

Dynamically generating and deploying Apex code through managed packages isn't permitted. Managed packages must adhere to strict security guidelines, and modifying their own code using the Metadata or Tooling API is prohibited to ensure the integrity and security of the package. If an app needs to provide IDE-like services, it can use the Metadata API to load classes but can't modify its own code. Additionally, all code in a managed package is namespaced, and the package shouldn't create classes in its own namespace or export global methods for internal use. However, if such functionality is absolutely required for testing purposes, the following security requirements must be met: 1. **Testing Context**: All dynamically generated code must be used exclusively in a testing context and must include the `@isTest` annotation for all classes. 2. **Code Modification Restrictions**: The package must not modify its own code using the Metadata or Tooling API. 3. **Adherence to Security Guidelines**: Any generated code must comply with Salesforce's security guidelines, ensuring it isn't exploitable and doesn't introduce vulnerabilities. 4. **Dynamic Content Vetting**: If the package involves dynamic content or code, it must be thoroughly vetted to ensure compliance with security standards. 5. **CRUD and FLS Checks**: Proper CRUD and FLS checks must be implemented wherever applicable. Using `WITH USER_MODE` for SOQL queries and `AccessLevel.USER_MODE` for Database methods is recommended for enforcing security in Apex code. 6. **False Positive Documentation**: Any false positives identified during security scans must be documented and justified in a false positive document for review.

The main improvements focus on modernizing language and security guidance while preserving all original content. Changed 'is not' contractions to 'isn't' and 'can't' for a more conversational tone per brand guidelines. Updated the CRUD/FLS security guidance to prioritize modern `WITH USER_MODE` and `AccessLevel.USER_MODE` approaches as instructed, while maintaining the existing recommendation structure. Selected security rules are directly relevant: ApexCRUDViolation applies because the FAQ discusses implementing 'proper CRUD and FLS checks' and data access security in dynamically generated code. ApexSharingViolations relates to the FAQ's emphasis on 'adherence to security guidelines' and ensuring generated code 'doesn't introduce vulnerabilities' including sharing rule violations. ApexDangerousMethods is relevant because the FAQ addresses restrictions on using 'Metadata or Tooling API' which can involve dangerous methods for code modification that this rule would flag.