FAQ-000740 - Data Storage and Encryption Security / Vulnerability Identification and Remediation

The difference between these two vulnerabilities lies in how and where sensitive information is mishandled: ### Insecure Storage of Sensitive Data - **Focus**: This vulnerability occurs when sensitive data (like API keys, passwords, or cryptographic keys) is stored in an insecure manner. - **Examples**: Storing sensitive data in publicly accessible fields or unprotected custom objects, failing to encrypt sensitive data before storage, hardcoding credentials in source code, or logging sensitive data in debug logs. - **Risk**: Unauthorized access to sensitive data due to improper storage practices. ### Sensitive Information in URL - **Focus**: This vulnerability arises when sensitive information is passed in the URL, which can be exposed in browser history, server logs, or shared links. - **Examples**: Including API keys, session tokens, or other sensitive data in query parameters of a URL. - **Risk**: Sensitive data can be intercepted or accessed by unauthorized parties through URL exposure. Both vulnerabilities involve mishandling sensitive data but differ in the context—storage versus transmission. Addressing them requires secure storage practices and avoiding sensitive data in URLs.

The original FAQ content is accurate and well-structured. I made minimal improvements to enhance clarity and readability: 1. Changed 'e.g.' to 'like' in the first example for more conversational tone per brand guidelines 2. Added 'hardcoding credentials in source code' as an additional example under insecure storage, which better aligns with the security rules available 3. These changes maintain all original information while making the content slightly more accessible Regarding security rules selection: - ApexBadCrypto: Relates to the FAQ's discussion of cryptographic keys and encryption practices mentioned in the insecure storage examples - ApexSuggestUsingNamedCred: Directly applies to the FAQ's mention of API keys storage - this rule suggests using Named Credentials instead of hardcoded credentials - AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInHttpHeader: All relate to the FAQ's examples of storing sensitive data like 'API keys, passwords, cryptographic keys' in insecure ways - ProtectSensitiveData: Directly matches the FAQ's core topic of protecting sensitive information from mishandling - ApexXSSFromURLParam: Relates to the 'Sensitive Information in URL' section, as this rule detects when URL parameters might contain sensitive data that could lead to XSS vulnerabilities