FAQ-001220 - Marketing Cloud Security / Integration and Component Security

The security requirements for Marketing Cloud app components include: 1. **Access to Environments**: Provide access to all environments, packages, and external components your solution uses, including external web applications, services, and client or mobile applications (required or optional). 2. **Secret Storage**: Don't write secrets to property files, XML files, or obfuscate them. Secrets must be stored in the OS vendor-supplied keystore (e.g., keychain for Mac, DP-API for Windows, or gnome-keyring for Unix). Pure Java client apps can't pass the security review if they store secrets permanently on the client. 3. **Server App Credentials**: Protect credentials against SQL injection and encrypt them with a key accessible to the application layer but not the database layer. Use vendor-supplied encryption functionality whenever possible. 4. **Testing and Documentation**: Perform end-to-end testing, configure test environments, and create supporting documentation before submitting the solution for review. 5. **Security Scan Reports**: Include security scan reports and explanations for any false positives flagged during testing. 6. **User Documentation and Policies**: Provide detailed solution user documentation and your company's information security policies. The extent of documentation may vary based on company size and maturity. 7. **OAuth 2.0 Guidelines**: Follow the OAuth 2.0 Web and Public App integration guidelines for Marketing Cloud, ensuring secure handling of authorization code requests and redirect URLs. 8. **Password Storage**: Test for password storage and ensure compliance with secure storage practices. These requirements ensure secure handling of customer data and compliance with enterprise security standards.

The FAQ content was updated to adopt a more conversational tone per the brand guidelines, changing formal phrases like 'Avoid writing' to 'Don't write' and 'cannot pass' to 'can't pass' to make it more approachable and less enterprise-documentation-like. The technical content remains accurate and no outdated information was detected. For security rule associations: - **ApexBadCrypto**: The FAQ discusses encryption requirements and using vendor-supplied encryption functionality, which directly relates to proper cryptographic practices that this rule enforces. - **ApexSOQLInjection**: The FAQ mentions protecting credentials against SQL injection, which is exactly what this rule detects and prevents. - **ApexSuggestUsingNamedCred**: The FAQ discusses secure credential storage and management, which aligns with this rule's recommendation to use Named Credentials. - **AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInHttpHeader, AvoidHardcodedCredentialsInSetPassword, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInVarDecls**: The FAQ's point about not writing secrets to property files or XML files and proper secret storage directly relates to these rules that prevent hardcoded credentials in various code contexts. - **AvoidInsecureHttpRemoteSiteSetting**: The FAQ mentions external web applications and services security, which relates to secure remote site configurations. - **AvoidDisableProtocolSecurityRemoteSiteSetting**: Similar to above, ensures protocol security isn't disabled for remote connections. - **UseHttpsCallbackUrlConnectedApp**: The FAQ discusses OAuth 2.0 guidelines and redirect URLs, which directly relates to ensuring HTTPS is used for callback URLs. - **ApexOpenRedirect**: The FAQ mentions secure handling of redirect URLs in OAuth flows, which this rule helps prevent through open redirect detection.