Insecure direct object references (DOR)
Why is this an issue?
Insecure direct object references (IDOR) occur when an application provides direct access to objects based on user-supplied input without proper authorization checks. Attackers can manipulate these references to access records they should not be able to view or modify.
In Salesforce, this commonly occurs when code accepts a record ID from user input (URL parameters, form fields) and queries or modifies that record without verifying the user has permission to access it.
Examples
Example of incorrect code:
@AuraEnabled
public static Account getAccount(Id accountId) {
// Directly uses user-supplied ID without authorization check
return [SELECT Id, Name, Revenue__c FROM Account WHERE Id = :accountId];
}
Example of correct code:
@AuraEnabled
public static Account getAccount(Id accountId) {
// Query with sharing rules enforced
List<Account> accounts = [SELECT Id, Name, Revenue__c FROM Account WHERE Id = :accountId WITH USER_MODE];
if (accounts.isEmpty()) {
throw new AuraHandledException('Record not found or access denied');
}
return accounts[0];
}
How can I fix violations?
Use
WITH USER_MODE: AddWITH USER_MODEto SOQL queries to enforce sharing rules and field-level security.Use
with sharing: Ensure your Apex class uses thewith sharingkeyword to enforce record-level sharing rules. Note thatwith sharingalone does not enforce field-level security or object-level permissions, and will not resolve this violation on its own.Validate access explicitly: As an additional security measure, use
Schema.SObjectType.Account.isAccessible()and similar methods to check permissions before accessing records. Note that this practice alone will not resolve the violation; combine it withWITH USER_MODEorWITH SECURITY_ENFORCED.Avoid exposing internal IDs: Where possible, use external IDs or other non-guessable identifiers.
When should I disable this rule?
You may dismiss specific violations when the code is intentionally running in system context for legitimate administrative purposes, and access is controlled through other means (e.g., custom permissions, profile checks).
Resources