ISVforce Guide
jBound Resource Use
Use Linear-Time Regular Expressions
If your connector uses regex for parsing or validation, avoid patterns vulnerable to catastrophic backtracking. An attacker-controlled string against a vulnerable pattern can exhaust CPU.
Do: Use simple linear-time patterns with explicit length limits.
Don't: Use nested-quantifier patterns such as ^(a+)+$, ^(.+)+$, or unbounded repetition.
Example
Vulnerable
1payload.text matches /^(a+)+$/Secure
1payload.text matches /^[a-zA-Z0-9 _-]{1,128}$/Bound Operations on Large Data
If your connector handles large datasets, groupBy, orderBy, distinctBy, and nested map operations load entire payloads into memory. An attacker-controlled large payload can exhaust memory or CPU.
Do: Cap input size before non-streaming operations.
Don't: Run groupBy or nested map over unbounded input arrays.
Example
Vulnerable
1payload.largeArray groupBy $.categorySecure
1payload.largeArray[0 to 9999] groupBy $.categoryAvoid Unbounded Nested Loops
Nested map and flatMap operations over the same array produce Cartesian-style work. With attacker-controlled input size, a quadratic transformation can exhaust CPU before the script returns.
Do: Restructure to single-pass mappings where possible. Cap input size when nesting is unavoidable.
Don't: Use nested map, flatMap, or deep loops on unbounded input.
Example
Vulnerable
1payload.items flatMap ((a) -> payload.items map ((b) -> { a: a.id, b: b.id }))Secure
1payload.items map ((i) -> { id: i.id, value: i.value })Bound Recursion Depth
Recursive DataWeave functions have no automatic depth limit. Attacker-controlled recursion depth can overflow the stack or exhaust CPU.
Do: Tie every recursive stop condition to input size. Cap depth explicitly.
Don't: Call recursive functions without an explicit depth bound.
Example
Vulnerable
1fun recurse(n) = recurse(n - 1)
2---
3recurse(payload.depth as Number)Secure
1fun recurse(n) = if (n <= 0 or n > 64) 0 else recurse(n - 1)
2---
3recurse(payload.depth as Number)