Authorization Differential Testing in Salesforce

Testing GraphQL record and field access

During testing, I do not treat GraphQL relationship traversal as a bypass on its own. Salesforce’s GraphQL API is built on UI API, so the schema and returned data are shaped by the context user’s object, field, and record access.

I check whether both standard and aggregate GraphQL queries returned only the records available to the test user and continued to respect field-level restrictions. When they do, the native GraphQL path is enforcing the expected boundary for the identities and data in the test matrix.

That does not clear the rest of the feature. A Lightning Web Runtime (LWR) component can use GraphQL for one operation and an @AuraEnabled method for another. The person using the page sees one feature, while Salesforce may process the requests under different authorization rules.

When GraphQL withholds a field and Apex returns it, I focus on the Apex path. I check which method executed, the class API version, the sharing declaration, and the access mode used by its queries or DML.

public with sharing class AccountSummaryController {
    @AuraEnabled(cacheable=true)
    public static Account loadAccount(Id accountId) {
        return [
            SELECT Id, Name, AnnualRevenue
            FROM Account
            WHERE Id = :accountId
            LIMIT 1
        ];
    }
}

For example, with sharing can limit an Account query to records the user owns or has been granted access to. It does not grant access to the Apex class or determine which fields on those records the user may read; those are separate checks.

The user may therefore pass the record-sharing check and still receive a field that their profile or permission sets do not allow them to read. No Apex class-access control or sharing rule needs to be bypassed. The query simply omitted a separate part of the authorization model.

This is why with sharing can give a reviewer false confidence. The class may be legitimately exposed to the application, and the Account may be correctly shared with the user. Neither fact shows that the query checked field access.

public with sharing class AccountSummaryController {
    @AuraEnabled(cacheable=true)
    public static Account loadAccount(Id accountId) {
        return [
            SELECT Id, Name, AnnualRevenue
            FROM Account
            WHERE Id = :accountId
            WITH USER_MODE
            LIMIT 1
        ];
    }
}

That minimum is a starting point. Depending on the feature, I also include internal users with different roles or permission sets, customer and partner users, integration accounts, and each site’s guest user. Record ownership and sharing can create differences even between users with similar profiles. For automation, I record the effective user and execution context. I repeat the comparison for each identity and note any paths its license or API settings do not permit.

I replay the same operation through UI API, GraphQL, and every relevant custom path, including @AuraEnabled Apex, automation and integration endpoints used by the feature. For each Apex result, I capture the class and method, API version, sharing declaration, query or DML access mode, permission checks, and the data returned to the client.

Consistent denials are still evidence. If all tested paths withhold AnnualRevenue, the implementation behaved consistently for that user and record. If Apex returns the field while the native services withhold it, the review has a specific class and operation to investigate. I repeat the comparison after changes to a class API version, sharing declaration, database access mode, guest class access, guest API settings, or the site’s frontend framework. Each of those changes can alter the path without producing an obvious visual change in the application.

When responses differ, the most useful question is: which path enforced a different rule, and why?
The answer is usually in the Apex execution context rather than the URL the browser called.

Recommendations for administrators and developers

Ready to review your Salesforce Apex & Experience Cloud?

NetSPI offers Salesforce Security Assessments covering configuration, data storage, integrations, and authentication. Start scoping your Salesforce security testing needs today:

SaaS Security Testing

Security Assessments