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.

If portal-exposed Apex trusts user-controlled parameters to determine record access, external users can manipulate inputs to retrieve or modify unauthorized records. This may enable record enumeration, data exfiltration, or data corruption. IDOR vulnerabilities represent a critical authorization boundary failure.

• Enforce with sharing on portal-facing classes by default.
• Scope queries using the running user's context where possible.
• If record IDs are accepted as parameters, verify access using sharing or UserRecordAccess before returning or modifying data.
• Remove user-controlled query structure and whitelist allowable filter inputs.
• Enforce CRUD and FLS on all returned or modified records.

1. Identify all Apex classes exposing @AuraEnabled, @InvocableMethod, or @RestResource methods accessible to portal users.

2. Review method parameters of type Id, String, collections, or maps that could influence record access.

3. Verify that:

   • Classes run with sharing or implement equivalent authorization checks.
   • Record access is validated before query or DML.
   • CRUD and FLS are enforced.
   • Dynamic SOQL does not incorporate unsanitized user input.

4. Attempt to access unauthorized records by manipulating record IDs or filter inputs from a portal user session.

5. Flag any method that relies solely on user-supplied parameters to control 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.

Flows accepting user-controlled input variables for record access create IDOR vulnerabilities allowing external users to access any record in the org. Because Autolaunched Flows run in system context without sharing by default, a single flow accepting a record ID input parameter bypasses all permissions and sharing rules. This constitutes a Critical boundary violation: unauthorized users access data they should never see, with no compensating controls required to fail.

1. Refactor flows to eliminate input variables controlling record access.
2. Derive accessible records from authenticated user context (e.g., $User.Id, $User.ContactId, $User.AccountId).
3. Configure flows to run in user context ("With Sharing") where available.

1. Using the inventory from SBS-CPORTAL-003, identify all portal-exposed Autolaunched Flows.
2. For each flow, examine input variables for types that could contain record IDs (Text, Record, Text Collection).
3. Review flow logic to determine if input variables influence Get Records, Update Records, or Delete Records elements.
4. Flag any flow accepting user-supplied input variables that control record 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 a complete inventory of portal-exposed components, organizations cannot assess their external attack surface or enforce security reviews for externally accessible code. Security teams lose visibility into which business logic external users can invoke, preventing effective security testing, incident response, and access governance. This impairs the ability to detect unauthorized exposure of sensitive functionality or identify components requiring security hardening.

1. Enumerate all Apex classes containing @AuraEnabled methods.
2. Enumerate all Autolaunched Flows embedded in Experience Cloud sites.
3. For each component, document which portal user profiles and permission sets have access.
4. Store the inventory in the designated system of record.
5. Establish a process to update the inventory when new components are exposed to portals.

1. Request the organization's inventory of portal-exposed Apex classes and Flows from the designated system of record.
2. Query all Apex classes with @AuraEnabled methods accessible to portal user profiles.
3. Query all Autolaunched Flows invoked from Experience Cloud pages or components.
4. Verify each component appears in the inventory with documentation of which portal profiles can access it.
5. Flag any portal-exposed component missing from the inventory as noncompliant.

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.

Failure to continuously monitor and rapidly respond to suspicious login activity creates an immediate and severe risk of a full system compromise. This control's absence exposes the organization to three critical, cascading risks:

1. The primary risk is that a successful suspicious login is the initial foothold for a sophisticated attack. Without automated, anomaly-based alerting, the attacker's presence goes unnoticed, leading to a prolonged "dwell time" (the period between compromise and detection). A longer dwell time allows the attacker to extensively reconnoiter the environment, escalate privileges, and establish persistence. The longer the intruders have to prepare, the harder it is to evict them from the Org.
2. Compromised credentials grant attackers direct access to sensitive customer data, intellectual property, and internal records. The lack of timely detection enables the attacker to perform mass data exfiltration via API, reporting, or export functionality before the account can be disabled, leading to financial, regulatory, and reputational damage.
3. An attacker with elevated access can modify or delete critical configuration settings, business-critical data, or code, leading to system downtime, operational failures, and a loss of data integrity.

1. Take into use a dedicated Security Information and Event Management (SIEM) or a specialized login anomaly detection platform. If a platform is already in place, ensure all Salesforce authentication and event logs, particularly LoginHistory and relevant Event Monitoring logs, are being successfully exported, ingested, and correctly parsed.
2. Configure the monitoring solution to explicitly analyze login events from all sources, including:

• Human Users: Both Single Sign-On (SSO) and direct Salesforce credentials.
• Non-Human/Integration Accounts: Any connected systems, APIs, or automated processes.

3. Periodically review and test the effectiveness of the deployed detection rules, minimizing false positives and updating baselines as organizational travel patterns or integration accounts change.
4. Define clear, high-priority, and time-bound Standard Operating Procedures (SOPs) to investigate and respond to all generated suspicious login alerts.

1. Verify the organization utilizes a continuous analytics solution that looks for anomalies in Salesforce login data
2. Confirm that the analytics solution's monitoring scope includes all user logins and all non-human integration or application user logins, regardless of whether the authentication method is Single Sign-On (SSO) or direct Salesforce login.
3. Confirm that there is a documented, mandatory procedure to periodically (e.g. quarterly) review, test, and update the login anomaly detection rules and baselines to ensure they remain effective and minimize false positives. Review should also include an analysis of investigated suspicious login alerts during the review period – no investigations can mean the rules are not firing.
4. Review the process and history of investigating and responding to suspicious login alerts.

Failure to monitor API activity creates a critical blind spot for post-authentication attacks, leading to severe and cascading consequences:

1. The primary risk is that a compromised application, integration account, or stolen session token can be used to perform mass, high-speed data exfiltration.
2. Attackers can leverage API access to perform unauthorized and undetectable manipulation of the Salesforce Org.

1. Deploy or build a dedicated analytics solution for granular API log analysis. Ensure all relevant Salesforce Event Monitoring logs for API activity are being successfully exported, ingested, and correctly parsed into the monitoring platform.
2. Configure the analytics solution to first establish a baseline of normal API behavior for every user and integration account. Following the baseline period, configure and tune high-severity anomaly detection rules to detect deviations, specifically rules that:

• Alert on an anomalous spike in data retrieval (read/query) volume.
• Monitor for CRUD (Create, Read, Update, Delete) operations on objects or security settings outside of an entity's established historical interaction baseline.
• Flag a change from read-heavy activity to an unusual volume of write or delete operations.
• Alert on API calls originating from a suspicious or atypical geolocation/IP address for the accessing entity.

3. Define clear, high-priority, and time-bound Standard Operating Procedures (SOPs) to investigate and respond to all generated API anomaly alerts. The procedure must include immediate steps to lock or deactivate the compromised user or application account and revoke stolen access tokens to prevent further data loss or system manipulation.
4. Establish a mandatory, recurring (e.g. quarterly) review process to:

• Periodically test the effectiveness of the deployed detection rules using simulated incidents (e.g. table-top exercises).
• Review and update the established baselines as new integrations are deployed or organizational usage patterns change.

1. Verify the organization utilizes a continuous analytics solution (e.g. SIEM, log aggregation platform) that is verifiably integrated with and ingesting all required API activity data, specifically the detailed Event Monitoring logs from Salesforce.
2. Confirm that the monitoring scope includes all API access, including user-initiated, non-human/integration accounts, and all API methods (e.g. REST, SOAP, Bulk). Verify the logs ingested are granular enough to track specific API calls (CRUD operations) against specific objects.
3. Request evidence (e.g. SIEM rule configurations, simulated alert outputs) to verify that the following specific, high-severity anomaly detection rules are active and tuned:

• Mass Data Exfiltration: Alerts on an anomalous spike in data retrieval volume for a specific user or application, especially for sensitive objects.
• Unauthorized Object Access: Alerts on a user or integration account attempting CRUD operations on objects they have no historical precedent for interacting with (e.g. Sales user accessing Security Settings).
• Suspicious Action Shift: Alerts on a shift from a baseline of read-only operations to a high volume of write or delete operations by a user or application.
• Suspicious Network Origins: Alerts on API calls originating from a suspicious or high-risk geolocation/IP address that is unusual for the accessing entity.

4. Process Review - Triage & Response: Examine the documented procedures for triage, investigation, and response to API anomaly alerts. Review a sample of anomaly findings and the actions taken on them for e.g. the past 6 months, to confirm that alerts are being acted upon within the defined parameter.

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 periodic review, Public Content links accumulate over time—including legacy links created before security policies were established, links that have outlived their business purpose, and links created through accidental or unauthorized sharing. These forgotten links represent persistent exposure that may go undetected indefinitely. While this control does not prevent initial link creation issues, it provides a governance mechanism to identify and remediate accumulated risk, supporting defense-in-depth and reducing the organization's overall exposure footprint.

1. Establish a documented process for periodic review of all ContentDistribution records.
2. Define a review cadence appropriate to organizational risk tolerance (quarterly recommended as a baseline).
3. Create a scanning mechanism (script, report, or tool) to enumerate all active Public Content links.
4. Define review criteria to identify links requiring remediation: missing expiry dates, missing passwords on sensitive content, links older than a defined threshold, or links to content no longer requiring external sharing.
5. Assign ownership for the review process and remediation actions.
6. Maintain records of each review cycle for audit purposes.

1. Verify the organization has a documented process for periodic Public Content link review.
2. Confirm the review cadence is defined (e.g., quarterly, monthly) and appropriate for the organization's risk profile.
3. Obtain evidence of recent review execution (e.g., scan results, remediation records, review meeting notes).
4. Verify that reviews include all active ContentDistribution records.
5. Confirm that identified issues are tracked through remediation or deletion.
6. Flag organizations without a documented review process or evidence of recent execution.

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.