Apex Security Best Practices

This article is based on the PMD documentation article. See the original article on the PMD site: PMD: security best practices.

Best practices that flag potential security flaws. 

ApexBadCrypto #

The rule makes sure you are using randomly generated IVs and keys for Crypto calls. Hard-wiring these values greatly compromises the security of encrypted data.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexBadCryptoRule

Example #

public without sharing class Foo { Blob hardCodedIV = Blob.valueOf(‘Hardcoded IV 123’); Blob hardCodedKey = Blob.valueOf(‘0000000000000000’); Blob data = Blob.valueOf(‘Data to be encrypted’); Blob encrypted = Crypto.encrypt(‘AES128’, hardCodedKey, hardCodedIV, data); }

Properties #

ApexCRUDViolation #

The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation. Since Apex runs in system mode not having proper permissions checks results in escalation of privilege and may produce runtime errors. This check forces you to handle such scenarios.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexCRUDViolationRule

Example #

public class Foo { public Contact foo(String status, String ID) { Contact c = [SELECT Status__c FROM Contact WHERE Id=:ID]; // Make sure we can update the database before even trying if (!Schema.sObjectType.Contact.fields.Name.isUpdateable()) { return null; } c.Status__c = status; update c; return c; } }

Properties #

ApexCSRF #

Check to avoid making DML operations in Apex class constructor/init method. This prevents modification of the database just by accessing a page.

This rule is defined by the following Java class:

net.sourceforge.pmd.lang.apex.rule.security.ApexCSRFRule

Example #

public class Foo { public init() { insert data; } public Foo() { insert data; } }

Properties #

ApexDangerousMethods #

Checks against calling dangerous methods.

For the time being, it reports:

• Against FinancialForce’s Configuration.disableTriggerCRUDSecurity(). Disabling CRUD security opens the door to several attacks and requires manual validation, which is unreliable.
• Calling System.debug passing sensitive data as parameter, which could lead to exposure of private data.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexDangerousMethodsRule

Example #

public class Foo { public Foo() { Configuration.disableTriggerCRUDSecurity(); } }

Properties #

ApexInsecureEndpoint #

Checks against accessing endpoints under plain http. You should always use https for security.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexInsecureEndpointRule

Example #

public without sharing class Foo { void foo() { HttpRequest req = new HttpRequest(); req.setEndpoint(‘http://localhost:com’); } }

Properties #

ApexOpenRedirect #

Checks against redirects to user-controlled locations. This prevents attackers from redirecting users to phishing sites.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexOpenRedirectRule

Example #

public without sharing class Foo { String unsafeLocation = ApexPage.getCurrentPage().getParameters.get(‘url_param’); PageReference page() { return new PageReference(unsafeLocation); } }

Properties #

ApexSharingViolations #

Detect classes declared without explicit sharing mode if DML methods are used. This forces the developer to take access restrictions into account before modifying objects.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexSharingViolationsRule

Example #

public without sharing class Foo { // DML operation here }

Properties #

ApexSOQLInjection #

Detects the usage of not trusted / unescaped variables in DML queries.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexSOQLInjectionRule

Example #

public class Foo { public void test1(String t1) { Database.query(‘SELECT Id FROM Account’ + t1); } }

Properties #

ApexSuggestUsingNamedCred #

Detects hardcoded credentials used in requests to an endpoint.

You should refrain from hardcoding credentials:

• They are hard to mantain by being mixed in application code
• Particularly hard to update them when used from different classes
• Granting a developer access to the codebase means granting knowledge of credentials, keeping a two-level access is not possible.
• Using different credentials for different environments is troublesome and error-prone.

Instead, you should use Named Credentials and a callout endpoint.

This rule is defined by the following Java class:

net.sourceforge.pmd.lang.apex.rule.security.ApexSuggestUsingNamedCredRule

Example #

public class Foo { public void foo(String username, String password) { Blob headerValue = Blob.valueOf(username + ‘:’ + password); String authorizationHeader = ‘BASIC ‘ + EncodingUtil.base64Encode(headerValue); req.setHeader(‘Authorization’, authorizationHeader); } }

Properties #

ApexXSSFromEscapeFalse #

Reports on calls to addError with disabled escaping. The message passed to addError will be displayed directly to the user in the UI, making it prime ground for XSS attacks if unescaped.

This rule is defined by the following Java class:

net.sourceforge.pmd.lang.apex.rule.security.ApexXSSFromEscapeFalseRule

Example #

public without sharing class Foo { Trigger.new[0].addError(vulnerableHTMLGoesHere, false); }

Properties #

ApexXSSFromURLParam #

Makes sure that all values obtained from URL parameters are properly escaped / sanitized to avoid XSS attacks.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.security.ApexXSSFromURLParamRule

Example #

public without sharing class Foo { String unescapedstring = ApexPage.getCurrentPage().getParameters.get(‘url_param’); String usedLater = unescapedstring; }

Properties #