Salesforce Security Review

The Approve Uninstalled Connected Apps permission allows users to bypass Connected App usage restrictions and self-authorize any OAuth application without administrator approval. This establishes an uncontrolled security boundary: users with this permission can grant external applications access to Salesforce data without oversight, enabling data exfiltration, unauthorized integrations, and potential account compromise. Unlike other permissions that require additional failures to exploit, this permission directly enables unauthorized third-party access the moment it is misassigned—making it a primary security boundary that must be tightly controlled.

1. Remove the Approve Uninstalled Connected Apps permission from any profile, permission set, or permission set group that lacks a documented justification or is assigned to end-users.
2. For any authorization that legitimately requires this permission (e.g., administrators or developers testing connected apps), add or update the rationale in the system of record to clearly justify the need and identify the specific role or use case.
3. Ensure that connected apps required for business operations are properly installed and allowlisted rather than relying on this permission for end-user access.
4. Reconcile and update the system of record to ensure complete and accurate inventory of all assignments of this permission.

1. Enumerate all profiles, permission sets, and permission set groups that include the Approve Uninstalled Connected Apps permission using Salesforce Setup, Metadata API, Tooling API, or an automated scanner.
2. Compare the enumerated list against the organization's designated system of record for this permission.
3. Verify that every profile, permission set, and permission set group granting "Approve Uninstalled Connected Apps" has a corresponding entry in the system of record.
4. Confirm that each entry includes:
   • A clear business or technical justification for requiring this permission,
   • Identification of the user role or persona (e.g., administrator, developer, integration manager),
   • Any applicable exception or approval documentation, and
   • Confirmation that the use case is limited to testing or managing connected app integrations.
5. Verify that the permission is not assigned to end-user profiles or permission sets intended for general business users.
6. Flag as noncompliant any authorizations lacking documentation, justification, or assigned to unauthorized user populations.

When portal-exposed methods accept user-controlled parameters to determine record access, external users can manipulate these inputs to bypass intended access controls and exfiltrate unauthorized data. By iterating record IDs, modifying query filters, or injecting field names, attackers gain direct access to records beyond their sharing-based permissions—even when proper sharing keywords are declared. This vulnerability is especially severe in customer portal contexts where thousands of external users with adversarial intent can systematically enumerate organizational data. A single method accepting a record ID parameter from the frontend creates a SQL injection-equivalent vulnerability in the Salesforce trust model—allowing attackers to read, modify, or delete data without authentication or authorization checks, independent of any other security control failures. This constitutes a Critical boundary violation: unauthorized users access data they should never see, with no compensating controls required to fail.

1. Refactor portal-exposed methods to eliminate all parameters that control record access, query scope, or field selection.
2. Implement server-side logic that determines accessible records based on the running user's context:

   @AuraEnabled
   public static Account getMyAccount() {
       Id userId = UserInfo.getUserId();
       User currentUser = [SELECT ContactId FROM User WHERE Id = :userId];
       Contact portalContact = [SELECT AccountId FROM Contact WHERE Id = :currentUser.ContactId];
       return [SELECT Id, Name FROM Account WHERE Id = :portalContact.AccountId];
   }
   

3. For methods that must operate on specific records, validate ownership using UserRecordAccess before returning data:

   List<UserRecordAccess> access = [SELECT RecordId, HasReadAccess 
                                     FROM UserRecordAccess 
                                     WHERE UserId = :UserInfo.getUserId() 
                                     AND RecordId = :recordId];
   if (access.isEmpty() || !access[0].HasReadAccess) {
       throw new AuraHandledException('Access denied');
   }
   

4. Establish code review requirements that specifically check for parameter-based access control in portal-exposed methods.

1. Identify all Apex classes containing @AuraEnabled methods or other methods exposed to customer portal sites.
2. For each method, examine the parameter list to identify parameters of type Id, String, List<Id>, List<String>, Set<Id>, or Map<String, Object> that could control record access.
3. Review the method implementation to determine if parameters influence SOQL query construction (WHERE clauses, record IDs, field selection, relationship traversal).
4. Verify that methods derive record access from UserInfo.getUserId() or related user context rather than accepting frontend-supplied identifiers.
5. Conduct penetration testing by attempting to pass unauthorized record IDs or manipulated parameters from portal user sessions.
6. Flag any method that accepts user-supplied parameters controlling record access as noncompliant.

Guest users represent the highest-risk trust boundary in Salesforce portals—they are unauthenticated, have zero accountability, generate minimal audit trail, and operate with potential adversarial intent. When guest users are granted object permissions or can invoke custom Apex methods, attackers can systematically enumerate organizational data without even creating an account. Historical Salesforce security updates have repeatedly addressed guest user permission defaults because vendors consistently misconfigure this boundary. A single guest-accessible method that queries user records, cases, accounts, or custom objects creates a public API for data exfiltration accessible to anyone on the internet. This constitutes a Critical boundary violation: unauthenticated attackers access organizational data with no authentication required.

1. Remove all object-level permissions from guest user profiles except those explicitly required for authentication flows.
2. Audit and remove guest user access to any custom Apex methods that query or return organizational data.
3. For public data requirements (knowledge articles, case submission), implement service layer pattern:

   @AuraEnabled
   public static List<Knowledge__kav> getPublicArticles() {
       if (UserInfo.getUserType() == 'Guest') {
           // Allowlist-based, no parameters accepted
           return [SELECT Id, Title, Summary FROM Knowledge__kav 
                   WHERE PublicationStatus = 'Online' 
                   AND IsVisibleInPkb = true 
                   LIMIT 10];
       }
       throw new AuraHandledException('Access denied');
   }
   

4. Implement network-level rate limiting and CAPTCHA for guest-accessible endpoints.
5. Review Salesforce security updates and apply guest user permission restrictions from recent releases.

1. Identify all guest user profiles used by customer portal sites (typically named "Site Guest User" or similar).
2. Review object-level permissions for guest user profiles and verify that all business-related standard and custom objects have Read, Create, Edit, Delete permissions set to disabled.
3. Enumerate all custom Apex classes containing @AuraEnabled methods and verify that none are accessible to guest users (either by checking profile permissions or testing invocation from guest context).
4. For any guest-accessible functionality beyond authentication flows, verify implementation of service layer architecture with explicit access controls.
5. Test by accessing the portal without authentication and attempting to invoke Apex methods or query objects via built-in Lightning controllers.
6. Flag any guest user object permissions or method access as noncompliant.

Without documented justification for Super Admin–equivalent users, organizations lose visibility into who possesses unrestricted access to the entire Salesforce environment. These users can read and modify all data, manage user accounts, and alter the security posture of the org without oversight. Undocumented Super Admin access prevents security teams from assessing breach impact, investigating administrative actions, or maintaining accountability for the most sensitive operations. The inability to identify and justify these users also prevents effective access reviews and creates persistent exposure from forgotten or orphaned administrative accounts.

1. Remove one or more of the Super Admin–equivalent permissions from any user who does not have a documented business or technical justification.
2. For users who legitimately require this level of access, add or update rationale within the system of record.
3. Reassess user access to ensure alignment with least privilege, reducing broad permissions where narrower privileges are sufficient.

1. Enumerate all users who simultaneously possess the following permissions through any profile, permission set, or permission set group:
   • View All Data
   • Modify All Data
   • Manage Users
2. Compile a list of all users meeting the criteria for Super Admin–equivalent access.
3. Compare the list against the organization’s system of record.
4. Verify that each Super Admin–equivalent user has corresponding documentation that includes:
   • A clear business or technical justification for requiring this level of access, and
   • Any relevant exception or approval records.
5. Flag as noncompliant any users with Super Admin–equivalent access lacking documentation or justification.

Without retained API Total Usage logs, organizations lose visibility into REST, SOAP, and Bulk API activity—including user identity, connected app, client IP, resource accessed, and status codes. This materially degrades the ability to detect anomalous API behavior, investigate security incidents, attribute unauthorized access, and determine the scope of potential breaches. The absence of this visibility creates a significant gap in incident detection and response capabilities.

1. If the organization has only 1-day ApiTotalUsage EventLogFile availability in Salesforce, implement an automated daily export that downloads newly available ApiTotalUsage log files and stores them externally for at least 30 days.
2. If the organization uses Salesforce-native retention, ensure the configured retention period for Event Log Files is not less than 30 days.
3. Restrict access to the retained logs (Salesforce-native or external) to authorized personnel and designated service identities.

1. Determine whether the organization relies on Salesforce-native retention (Event Monitoring/Shield/Event Monitoring add-on) or an external log store as the system of record for ApiTotalUsage EventLogFile data.
2. If the organization relies on Salesforce-native retention, verify that EventLogFile data is retained for at least 30 days (for example, confirm the org is entitled to and configured for Event Log File retention that is at least 30 days and can retrieve ApiTotalUsage EventLogFile data within the preceding 30-day window).
3. If the organization relies on an external log store (including all orgs with only 1-day ApiTotalUsage availability in Salesforce):

• Verify an automated process exists that retrieves EventLogFile entries where EventType='ApiTotalUsage' and downloads the associated log files at least once every 24 hours.
• Inspect job schedules/run history and confirm successful executions covering at least the last 30 days (no missed days).
• From the external log store, retrieve ApiTotalUsage logs for (a) the oldest day in the preceding 30-day window and (b) the most recent day, and confirm both are accessible and attributable to the organization.
• Verify access to the external log store is restricted to authorized roles and service identities responsible for monitoring and investigations.

Overly broad login IP ranges effectively disable network-based access controls, allowing authentication from any location on the internet. However, exploitation requires credentials to be compromised first—this control provides defense-in-depth rather than establishing a primary security boundary. When authentication controls (SBS-AUTH-001) are enforced, IP restrictions serve as an additional layer that limits the blast radius of credential compromise.

1. Remove any profile login IP ranges that effectively grant unrestricted global access.
2. Replace them with IP ranges that correspond to approved corporate networks, office locations, VPN ingress points, or other authorized infrastructure.
3. Validate that updated network restrictions do not block legitimate access paths and that users can authenticate through sanctioned networks.
4. Establish an internal governance process to review and approve all future additions of profile login IP ranges.

1. Retrieve all profile login IP ranges via Setup → Profiles → Login IP Ranges or by querying the Profile metadata (loginIpRanges field) using the Metadata API.
2. For each profile, enumerate all configured login IP ranges.
3. Identify any ranges that:
   • Cover the entire IPv4 space, or
   • Represent effectively unrestricted access (e.g., 0.0.0.0–255.255.255.255, 1.1.1.1–255.255.255.255, or similar patterns).
4. Confirm that all IP ranges align with organizational security policy and defined network boundaries.
5. Flag any profile with an impermissible or overly broad range.
6. Download API Total Usage logs (EventLogFile - ApiTotalUsage, available in free tier of Event Monitoring) to validate IP restrictions are effective:
   • Extract unique CLIENT_IP values from recent API activity.
   • Compare against documented approved organizational network ranges.
   • Identify any new or unexpected IP addresses making API calls.
   • Cross-reference unusual IPs with profile assignments to identify potential policy gaps.

Without a current inventory of fields containing regulated data, organizations cannot systematically apply appropriate protection, retention, or access controls to sensitive data locations—and may be unable to fulfill privacy obligations such as GDPR's Right to Erasure or CCPA deletion requests that require knowing all locations where personal data is stored. During audits or breach investigations, the absence of a maintained inventory delays response times and may result in incomplete remediation or missed data locations.

1. Generate an inventory using scan results, administrative review, and metadata analysis.
2. Document all LTA fields containing regulated data and classify the associated data types.
3. Establish a recurring review cycle to update the inventory.
4. Integrate the inventory into governance functions such as retention, DLP, access reviews, and breach response planning.

1. Obtain the organization's documented inventory of Long Text Area fields containing regulated data.
2. Compare the inventory against Salesforce metadata to confirm all relevant fields are included.
3. Review scan results or administrative evidence demonstrating how fields were identified.
4. Verify that the inventory includes object name, field API name, data classification, and last review date.
5. Determine whether the inventory is maintained and current; missing, outdated, or incomplete inventories indicate noncompliance.

Without a documented inventory and justification for Named Credentials, undocumented or unjustified configurations may expose the organization to data leakage, unauthorized integrations, or reliance on insecure or untrusted endpoints. However, this control provides governance documentation rather than detection or prevention capability: it supports audit readiness and informed decision-making about authenticated external connections, but other controls are required to detect or prevent actual misuse of approved credentials.

1. Add any undocumented Named Credentials to the system of record.
2. Document a valid business justification for each Named Credential.
3. Remove, disable, or reconfigure any Named Credentials that cannot be justified or that reference untrusted endpoints.
4. Establish a recurring reconciliation process to ensure Named Credentials remain fully inventoried and justified.

1. Enumerate all Named Credentials using Salesforce Setup, Metadata API, Tooling API, or Connect REST API.
2. Retrieve the organization’s system of record for approved external endpoints and integration credentials.
3. Compare the Salesforce list to the system of record to confirm all Named Credentials are documented.
4. Verify that each documented Named Credential includes:
   • The external endpoint URL
   • The authentication type (named principal or per-user)
   • The business justification for the integration
5. Flag any Named Credentials missing from the inventory or lacking justification as noncompliant.