FAQ-000773 - Error Handling and Logging Security / Error Message Security

Best practices for handling error messages to avoid leaking system information include: 1. **Use Generic Messages**: Provide user-friendly and non-technical error messages like "An unexpected error occurred. Please try again later." Avoid exposing internal details such as stack traces, database structures, or system paths. 2. **Secure Logging**: Log detailed error information internally for troubleshooting purposes. Ensure that sensitive data is redacted or omitted from these logs. 3. **Avoid Specific Error Codes**: Don't display specific error codes or system paths to users, as these can provide clues to attackers. 4. **Minimal Information Disclosure**: Only include information in the error message that's necessary for the user to understand the issue and take corrective action. 5. **Regular Reviews**: Periodically review and update error messages to ensure they comply with security best practices. This approach helps maintain system security while providing a clear, professional, and user-friendly experience.

The FAQ content is accurate and well-structured, covering important security principles for error message handling. However, minor improvements were made to enhance readability and conversational tone: changed 'Do not display' to the more conversational 'Don't display' and replaced 'that is necessary' with the more natural contraction 'that's necessary'. These changes align with the brand guidelines to use contractions and maintain a conversational tone while preserving all the original technical content and security advice. Regarding security rules, none of the available rules directly apply to this FAQ's content. The rules in the list focus on specific code vulnerabilities (like SOQL injection, XSS, CRUD violations, hardcoded credentials, etc.) or configuration issues, while this FAQ addresses general error message handling principles and secure logging practices. Error message security is a broader security concept that spans across multiple potential vulnerabilities rather than being tied to a specific scanner rule.