Insecure Use of Language/Framework API

This vulnerability category covers the following issues:

• Dangerous Apex Methods
• Cross-Site Request Forgery

Dangerous Apex Methods

APEX has a few dangerous methods that should be avoided. At the moment, the use of the following methods are flagged:

Configuration.disableTriggerCRUDSecurity() Disabling CRUD security opens the door to several attacks and requires manual validation, which is unreliable.

System.debug If sensitive data is passed as a parameter it could lead to exposure of private data.

Fixing Dangerous Apex Methods

Option A: Avoid the the use of dangerous methods

1. Go through the issues that GuardRails identified in the PR.
2. Locate the code with the above mentioned functions.
3. Rewrite them to avoid using disableTriggerCRUDSecurity(), or ensure that the the System.debug() is used without sensitive data.
4. Test it
5. Ship it 🚢 and relax 🌴

Cross-Site Request Forgery

In a Cross-Site Request Forgery (CSRF) attack, an untrusted application can cause a user's browser to submit requests or perform actions on the user's behalf.

References:

• CSRF Description

Fixing Cross-Site Request Forgery

Option A: Avoid DML operations in initializers

Having DML operations in Apex class constructor or initializers can have unexpected side effects: By just accessing a page, the DML statements would be executed and the database would be modified. Just querying the database is permitted.

Salesforce Apex already protects against this scenario and raises a runtime exception.

1. Go through the issues that GuardRails identified in the PR.
2. Locate the code with the following pattern:

public class Foo {
  // initializer
  {
    insert data;
  }

  // static initializer
  static {
    insert data;
  }

  // constructor
  public Foo() {
    insert data;
  }
}

3. And ensure that these operations are moved to a secure place with proper access control.
4. Test it
5. Ship it 🚢 and relax 🌴