ISVforce Guide
jUse Strong Cryptography
Use SHA-256 or Stronger for Hashing
MD5, SHA-1, hashWith (which defaults to SHA-1), and HMACWith (which defaults to HmacSHA1) are cryptographically broken for collision resistance.
Do: Specify "SHA-256" or stronger explicitly for hashing, and "HmacSHA256" or stronger for HMAC.
Don't: Use MD5 or SHA-1, or rely on default algorithm selection.
Example
Vulnerable
1dw::Crypto::MD5(payload.data as Binary)Secure
1dw::Crypto::hashWith(payload.data as Binary, "SHA-256")Don't Treat Base64 as Encryption
Base64 is an encoding, not encryption. Anyone with the encoded value can decode it.
Do: Use real encryption or tokenization for sensitive data at rest or in transit.
Don't: Use toBase64() on sensitive data and treat it as protected.
Example
Vulnerable
1{ protectedSsn: toBase64(payload.ssn as Binary) }Secure
1{ ssnToken: java!com::example::Tokenization::tokenize(payload.ssn as String) }Don't Compare Secrets with Plain Equality
DataWeave's == operator on strings is not constant-time. When you compare a secret, such as a token or password, with ==, you can leak it one character at a time through timing differences. If you hash both sides and compare the hashes with ==, the operation still isn't constant-time. The timing leak shifts to the hash comparison.
Do: Move secret comparisons to a constant-time primitive, typically a Java helper that wraps java.security.MessageDigest.isEqual.
Don't: Compare tokens, passwords, or any secret value with == in DataWeave.
Example
Vulnerable
1payload.token == vars.expectedTokenSecure
1java!com::example::SecurityUtils::constantTimeEquals(payload.token, vars.expectedToken)