Flow Scanner Rules Reference

The Flow Scanner rules help you identify security issues in your flows. To select these rules, use --rule-selector flow. For example, to run all the Flow Scanner rules:

Description: This rule finds CRUD (Create, Read, Update, Delete) operations in which user controlled data either determines which Salesforce records are selected for the CRUD operation, or in which user controlled data can modify the data of the selected records. This happens in flows that run in System Context Without Sharing.

If your flow violates this rule, the user running the flow can gain higher privileges and perform actions on records that they shouldn't have access to. This is a security risk known as a privilege escalation vulnerability.

Default Severity: High (2)

Default Tags: Recommended, Security, Xml

How to Fix: The best fix is to change the run context of your flow from System Context Without Sharing to User Context. See Change the Flow Run Context for details.

If you can't change the run context of your flow, you must implement your own procedural access control checks using decision elements and custom Apex actions; see the next section for helpful resources.

False Positive Guidance: A flow sometimes causes a violation of this rule, but the violation might be a false positive. This section provides guidance on what causes a false positive, and when you can safely ignore it.

In the following two use cases, the flow is required to run in System Context (either with or without sharing) for its secure operation:

  • The flow is public-facing and used by external guests or community users, and you intend that these users perform limited operations on records that they don't have access to.
  • The flow code modifies or accesses only custom fields that are owned by your app and you're intentionally ignoring the platform access control policies.

To safely ignore these two use cases as false positives, you must provide an alternative access control policy in the flow itself or in an Apex action called from the flow. You can't ignore the platform access control policy without building your own procedural replacement, because bypassing platform access checks places the burden on the flow developer of ensuring appropriate custom access checks are performed.

Additional resources:

Description: This rule finds CRUD (Create, Read, Update, Delete) operations in which user controlled data either determines which Salesforce records are selected for the CRUD operation, or in which user controlled data can modify the data of the selected records. This happens in flows that run in System Context With Sharing.

If your flow violates this rule, the user running the flow can gain higher privileges and perform actions on records that they shouldn't have access to. This is a security risk known as a privilege escalation vulnerability.

Default Severity: Low (4)

Default Tags: Recommended, Security, Xml

How to Fix: The best fix is to change the run context of your flow from System Context With Sharing to User Context. See Change the Flow Run Context for details.

If you can't change the run context of your flow, you must implement your own procedural access control checks using decision elements and custom Apex actions; see the next section for helpful resources.

False Positive Guidance: A flow sometimes causes a violation of this rule, but the violation might be a false positive. This section provides guidance on what causes a false positive, and when you can safely ignore it.

In the following two use cases, the flow is required to run in System Context (either with or without sharing) for its secure operation:

  • The flow is public-facing and used by external guests or community users, and you intend that these users perform limited operations on records that they don't have access to.
  • The flow code modifies or accesses only custom fields that are owned by your app and you're intentionally ignoring the platform access control policies.

To safely ignore these two use cases as false positives, you must provide an alternative access control policy in the flow itself or in an Apex action called from the flow. You can't ignore the platform access control policy without building your own procedural replacement, because bypassing platform access checks places the burden on the flow developer of ensuring appropriate custom access checks are performed.

Additional resources: