How to Test Authorization Across Salesforce APIs and Apex

· Original article ↗

Summary

The article outlines a method for comparing Salesforce authorization across UI API, GraphQL, and custom Apex. It highlights that Apex database access defaults differ by class API version and recommends testing restricted and guest users.

Key points

  • Keep the user identity, target record, field, and operation constant while comparing results across UI API, GraphQL, and custom Apex.
  • UI API and GraphQL enforce the caller’s object, field, and record access; custom Apex may apply different rules.
  • With sharing enforces record-level sharing but does not by itself enforce object permissions or field-level security for system-mode database operations.
  • Apex database operations in classes at API v66 or earlier default to system mode; classes at API v67 or later default to user mode.
  • Test Experience Cloud guest access to native APIs separately from guest access to reachable Apex classes and methods.
  • Use explicit user-mode operations when caller permissions should apply; Security.stripInaccessible() can remove inaccessible fields from results.
  • Repeat authorization checks after API-version upgrades, permission changes, and Experience Cloud migrations.

Article Details

Defense Focus
Identify authorization differences when the same user, record, field, and operation are tested through Salesforce native APIs and custom Apex paths.
Detection Methods
  • Replay the same operation for the same identity, record, and field through UI API, GraphQL, and relevant custom Apex paths; compare what each response allows the caller to read or change.
  • Use a privileged user as a positive control and restricted identities, including the site guest where relevant, to test accessible and inaccessible records and fields.
  • For differing Apex results, inspect the executing class and method, class API version, sharing declaration, query or DML access mode, and permission checks.
  • Repeat authorization comparisons after permission changes, Apex API-version upgrades, or Experience Cloud migrations.
Data Sources
  • Responses from UI API, GraphQL, and custom Apex requests
  • Effective user identity and execution context
  • Apex class and method metadata, including API version and sharing declaration
  • Query and DML access modes and permission checks
  • Object permissions, field-level security, record-sharing configuration, and guest access settings
  • Fields and records returned to the client
Rule Types
  • SOQL queries
  • Database DML operations
Defensive Actions
  • Review object and field permissions, record-sharing rules, permission sets, and guest Apex class access for the affected feature.
  • Review guest public API settings separately from custom Apex class access, and remove access that is no longer needed.
  • Select database access modes explicitly; use user mode when operations must respect caller permissions.
  • Use Security.stripInaccessible() when inaccessible fields should be omitted, and enforce appropriate record sharing.
  • Document and restrict required system-mode operations.
  • Add restricted-user and guest authorization checks to regression tests, including read and write operations where supported.

Vendors

Products

Related Articles