FAQ-000074 - API Security and Metadata Access / Tooling API Security and Usage

When using the Tooling API in managed packages, follow these comprehensive security guidelines and best practices: **General Security Considerations:** 1. **Tooling API Usage**: Arbitrary reads are allowed to view org settings or configurations. Writes are restricted to objects owned by the package, such as updating picklist values or layouts for custom fields or objects created by the package. 2. **API Session IDs**: API session IDs can be used for AJAX Toolkit or partner REST/SOAP API calls, but only for accessing data. Writes using Metadata/Tooling API must be limited to package-owned objects. Exporting session IDs to external endpoints or using them for unauthorized purposes is strictly prohibited. 3. **Critical Org Settings**: Changes to critical org security settings (e.g., IP access control, password policies) are not allowed via API session IDs and must use a connected app. 4. **Preferred Authentication**: Use OAuth tokens with connected apps for API calls instead of session IDs to ensure secure and authorized access. 5. **Remote Site Settings**: Modifications to remote site settings or other non-security-sensitive org settings must be performed through a connected app, not directly via API session IDs. **Lightning Web Components Integration:** 1. **Use a Visualforce Page**: Create a Visualforce page to generate the session ID. Ensure the Visualforce page doesn't have any controllers or exposed methods and is solely used to provide the session ID. 2. **Make API Calls in LWC**: Use the session ID in your Lightning Web Component to make Tooling API calls. 3. **Follow Security Best Practices**: Ensure that the API calls only retrieve data and comply with Salesforce's security guidelines. **Dynamic Query Security:** To demonstrate that dynamic queries built to call the Tooling API are secure and not vulnerable to injection: 1. **Use Bind Variables**: Always use bind variables for user-supplied input in the WHERE clause to ensure input is treated as data, not executable code. 2. **Sanitize Input**: If bind variables aren't an option, sanitize input using methods like `String.escapeSingleQuotes()` to escape single quotes and prevent code execution. 3. **Validate Input**: Ensure user-supplied input matches valid and expected values using methods like `Schema.getGlobalDescribe()` for object or field names. 4. **Avoid User-Generated Queries in Apex**: Avoid executing user-generated queries in Apex as they run in system mode. For complex client-side SOQL, use the REST or SOAP API for safer execution. 5. **Follow Secure Development Practices**: Adhere to secure development guidelines to mitigate SOQL injection risks. **Acceptable Use Cases:** It's acceptable to use the Tooling API with session IDs to automate custom field creation for customers, as long as the session ID is used only for objects owned by the managed package and operations are limited to the package's components. These practices ensure compliance with Salesforce's security policies and safeguard customer data while enabling secure Tooling API functionality.

I made minor improvements to enhance clarity and readability without removing or adding content. Changes include: 1) Simplified 'Legacy Connected Apps' to 'Preferred Authentication' for clearer messaging about OAuth tokens, 2) Changed 'does not have' to 'doesn't have' for more conversational tone, 3) Replaced 'It is acceptable' with 'It's acceptable' for consistency with the conversational style guidelines. No content was outdated or conflicted with security rules. For security rules selected: - **AvoidApiSessionId**: This FAQ extensively discusses API session ID usage, which directly relates to this rule that flags improper session ID usage - **AvoidUnauthorizedApiSessionIdInApex**: The FAQ discusses using session IDs in Apex contexts and the restrictions around this practice - **AvoidUnauthorizedApiSessionIdInVisualforce**: The FAQ specifically mentions creating Visualforce pages to generate session IDs, directly relating to this rule - **AvoidUnauthorizedGetSessionIdInApex**: The FAQ discusses obtaining and using session IDs in Apex, which this rule addresses - **AvoidUnauthorizedGetSessionIdInVisualforce**: The FAQ mentions using Visualforce to generate session IDs, which this rule covers - **ApexSOQLInjection**: The FAQ has an entire section on 'Dynamic Query Security' that discusses preventing SOQL injection through bind variables, input sanitization, and validation - **ApexSuggestUsingNamedCred**: The FAQ discusses authentication approaches and recommends OAuth tokens over session IDs, which aligns with this rule's guidance on secure credential management