Insecure Use of Language/Framework API
This vulnerability category covers the following issues:
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
- Go through the issues that GuardRails identified in the PR.
- Locate the code with the above mentioned functions.
- Rewrite them to avoid using
disableTriggerCRUDSecurity()
, or ensure that the theSystem.debug()
is used without sensitive data. - Test it
- 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:
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.
- Go through the issues that GuardRails identified in the PR.
- Locate the code with the following pattern:
public class Foo {
// initializer
{
insert data;
}
// static initializer
static {
insert data;
}
// constructor
public Foo() {
insert data;
}
}
- And ensure that these operations are moved to a secure place with proper access control.
- Test it
- Ship it 🚢 and relax 🌴