Try Graph Engine

Salesforce Graph Engine (Graph Engine) works a bit differently from other analyzers.

To get started with Graph Engine:

Next, run a command to view Graph Engine rules, then install our sample project to try out Graph Engine for yourself.

To see Graph Engine’s rules, run:

All our examples use our sample app.

  1. Clone the repo.

    git clone https://github.com/forcedotcom/sfdx-scanner.git

  2. Open the sample app directory.

    cd sfdx-scanner/test/code-fixtures/projects/sfge-working-app/

The sample app contains these key classes.

  • AuraEnabledFls.cls contains @AuraEnabled-annotated methods.
  • PageReferenceFls.cls includes methods that return PageReference objects.
  • VfControllerFls.cls is a Visualforce Controller for the VfComponentWithController component.
  • FlsHelperClass.cls performs CRUD/FLS checks against objects and fields.

To run Graph Engine, start with a basic evaluation of all files.

  1. From the sample app root folder run:

  2. Review the results. Notice that each violation has a source and a sink vertex.

  • The source vertex is the start of the path in question.

  • The sink vertex is the point where the DML operation occurs.

  • If there’s insufficient CRUD/FLS validation between those two points, a violation is thrown.

    For example, look at some AuraEnabledFls.cls methods that threw violations.

    • flsHelperGivenIncorrectObjectType(). This method has no branches. Instead, it’s just a single path all the way through. CRUD/FLS was performed on the wrong object type, resulting in the violation. The source vertex is the line where the method is declared, and the sink vertex is the line where the account is inserted.
    • flsInIfBranchOnly(). This method has an if statement, so it has two paths: one that goes through the if and one that doesn’t. Because CRUD/FLS only occurs in one of those paths, a violation is thrown.

    Two AuraEnabledFls.cls methods didn’t throw violations.

    • flsDoneCorrectly(). All the fields inserted are checked with the FlsHelperClass first. The method is secure, and no violation was thrown.
    • flsInNonAuraMethod(). This method isn’t a recognized entry-point or source, and it isn’t in the call-stack of any entry points. Graph Engine skipped this method even though it’s technically insecure.

After you fix violations that Graph Engine identified in a specific file, run Graph Engine against that specific file to double-check your work.

To run Graph Engine against a single file, run:

Keep in mind that:

  • The target file contains the source vertices that you want to scan.
  • The projectdir is the entire project that Graph Engine builds all paths against.

Graph Engine runs faster against one file than a whole project because it analyzes a smaller number of paths. It also returns results only for source vertices that are in the targeted file.

Choose one of the violations in the sample file to fix. For example, to fix flsInIfBranchOnly(), you can:

  • Move the CRUD/FLS check out of the if branch so it always runs.
  • Move the DML operation into the if branch so it only runs in the path that performed the CRUD/FLS check.
  • Add an else branch that performs the same CRUD/FLS checks as the if branch.

Try one or several of these options, then run the provided command again. If you do it right, then the number of violations in the file is smaller.

If you want more experience with Graph Engine, experiment with the remaining violations in the sample app.

After you fix the violations in a given method, sometimes you want to analyze that method individually. For example, suppose you only want to analyze the flsHelperGivenIncorrectObjectType() and flsHelperMultipleInstances() methods in AuraEnabledFls.cls.

To analyze these two methods only, run:

Running Graph Engine against specific methods has these limitations:

  • The syntax is only supported for file paths. You can’t use it with globs or directories.
  • If multiple methods in the target file share the specified name, then all such methods are included. Overloads and inner classes are some examples.
  • Methods specified through method-level targeting are considered path entrypoints even when they otherwise aren't. This misidentification can cause methods that are ordinarily skipped to be analyzed.

Sometimes false positives can occur. Other times, you can identify a reason why a Create, Read, Update, Delete and Field-Level Security (CRUD/FLS) check is unnecessary, such as your code is only executed from an admin-only page. If you want to skip a violation due to a false positive or other reason, use engine directives.

To skip a violation using an engine directive:

  1. Add /* sfge-disable-next-line ApexFlsViolationRule */ before the DML operation in flsNoEnforcementAttempted().
  2. Rerun the command.
  3. The violations in the identified method are suppressed.

You can also suppress all violations in a method by adding /* sfge-disable-stack ApexFlsViolationRule */ immediately above the method, or in the entire file by adding /* sfge-disable ApexFlsViolationRule */ at the top of the class.