ISVforce Guide

ISVforce Guide: Build and Distribute AppExchange Solutions
Get Ready to Distribute on AppExchange
Use Managed Packages to Develop Your AppExchange Solution
Manage Orgs with Environment Hub
Architectural Considerations for Group and Professional Editions
Security Requirements for AppExchange Partners and Solutions
Security Policy Requirements
Prevent Secure Coding Violations
Secure Your B2C Commerce Solution
Secure Your Tableau Accelerator
Secure Your Agentforce Solution
Secure Your Connected Apps and External Client Apps
Secure Your Flow Connectors
Protect Credentials and Sensitive Data
Don't Run Untrusted Code or Make Untrusted Calls
Validate Input from Flow Builder
Filter Response Data
Handle Errors Without Leaking Information
Use Strong Cryptography
Bound Resource Use
Handle Specialized Data Formats Carefully
Other Considerations
Common Reasons for Returned Submissions
Where to Get Help
Pass the AppExchange Security Review
Manage Your AppExchange Listings
AgentExchange Go-To-Market App Guide
Sell on AgentExchange with Checkout
Report Orders to Salesforce with the Channel Order App
Provide Free Trials of Your AppExchange Solution
OEM User License Guide
PDF

Don't Run Untrusted Code or Make Untrusted Calls

Several DataWeave functions execute code or fetch remote content. When their parameters come from user input, an attacker can run arbitrary code in your connector or reach internal services.

Don't Evaluate Untrusted Code

DataWeave's eval(), run(), evalUrl(), and runUrl() functions execute DataWeave code from strings or URLs. If the script or URL parameter is user-controlled, an attacker can execute arbitrary DataWeave code from a remote location.

Do: Run scripts only from your own repository or trusted sources before you pass them into eval, run, evalUrl, or runUrl.

Don't: Pass user-provided URLs or script bodies directly into these functions.

Example

Vulnerable

1dw::Runtime::evalUrl(payload.scriptUrl, {}, {})

Secure

1dw::Runtime::evalUrl("classpath://scripts/trusted-transform.dwl", {}, {})

Don't Deserialize Untrusted Java Objects

read(..., "application/java") deserializes Java objects from raw bytes. Attacker-controlled serialized data can trigger gadget-chain attacks in vulnerable classpaths.

Do: Deserialize Java objects only from sources that you trust.

Don't: Call read(..., "application/java") on user input.

Example

Vulnerable

1read(payload.serializedObject, "application/java")

Secure

1read(payload.userJson, "application/json")

Validate URLs Before Fetching

readUrl() accepts http://, https://, and classpath:// URLs.

With a user-controlled URL, an attacker can target internal services, cloud instance-metadata endpoints, or private IPs.

Do: Maintain an allowlist of schemes and hosts before you pass a URL into readUrl().

Don't: Accept file://, classpath://, or internal IPs from request parameters.

Example

Vulnerable

1readUrl(payload.url, "application/json")

Secure

1var u = parseURI(payload.url default "")
2var allowedHosts = ["api.example.com"]
3---
4if ((u.isValid default false) and ((u.scheme default "") == "https") and ((u.host default "") in allowedHosts))
5  readUrl(payload.url, "application/json")
6else
7  fail("blocked-url")

Constrain Classpath URL Fetches

readUrl() with classpath:// resolves against the project classpath. With user-controlled path strings, an attacker can discover internal configuration files and property files inside your connector's resources.

Do: Validate every classpath path against an explicit allowlist before you fetch it.

Don't: Concatenate user input into a classpath:// URL.

Example

Vulnerable

1readUrl("classpath://" ++ payload.path, "text/plain")

Secure

1if ((payload.path as String) in ["configs/public.properties", "templates/help.txt"])
2  readUrl("classpath://" ++ payload.path, "text/plain")
3else
4  fail("blocked-path")