This audit assessed the org’s security configuration and scored it 77/100 (Grade F), a grade set by 7 CRITICAL (4 findings, 3 attack chains) (D allows none), across 53 active findings, with 3 inconclusive (no evidence gathered). The priorities below are the highest-impact items to address first; the remediation roadmap groups every fix by effort. See Scope & Liability for the basis and limits of this assessment.
Evidence coverage 98% (99 of 101 checks). The checks that gathered no evidence are listed as inconclusive in the findings appendix; their areas are unassessed, not clean. Each unassessed check has an inconclusive finding quoting what the org returned. Where the cause is access, `sf audit preflight` lists the permissions the audit user is missing, and PERMISSIONS.md (https://github.com/cclabsnz/sf-audit-plugin/blob/main/PERMISSIONS.md) has the read-only permission set to assign.
Focus areas, highest impact first.
Impact: Unauthenticated web users can execute Apex that bypasses sharing: bulk record exfiltration without login.
Part of an attack chain. See Attack Scenarios.
Fix: Add "with sharing" to every guest-reachable Apex class and to every helper it calls, enforce CRUD/FLS, and remove guest execution access from any class that does not strictly need it.
Impact: Shadow admins hold full org control outside the admin profile, so a single takeover bypasses admin-focused monitoring and owns everything.
Part of an attack chain. See Attack Scenarios.
Fix: Review each user's permission sets and profile. Remove "Modify All Data" / the Manage Users + Assign Permission Sets pairing unless the role genuinely requires org administration, and consolidate true admins onto a controlled admin profile.
Impact: without-sharing Apex bypasses record access, letting low-privilege or guest users reach data they can’t otherwise see.
Part of an attack chain. See Attack Scenarios.
Fix: Add "with sharing" to all @AuraEnabled, @RemoteAction and @RestResource classes. Validate user ownership or sharing on every record accessed inside these methods.
Impact: Grades guest-readable objects by ACTUAL UI-API reachability: objects the UI API models are bulk-readable unauthenticated via GraphQL (CRITICAL, incl. guest-owned records under a Private OWD, enabling mass PII exfiltration without login); objects readable only in the sharing model but not UI-API-modelled (Calendar, AuthSession, etc.) are separated as MEDIUM defense-in-depth, with UserRecordAccess as ground-truth read confirmation.
Part of an attack chain. See Attack Scenarios.
Fix: Set external OWD to Private for these objects, and remove Read from the guest profile/permission sets unless a specific public dataset is intended. Then verify no guest-accessible Apex returns the data.
Impact: Secrets embedded in Apex can be read by anyone with code access and reused to reach connected systems.
Part of an attack chain. See Attack Scenarios.
Fix: Replace hardcoded credentials with Named Credentials. Rotate any exposed credentials immediately.
How findings combine into real attack paths.
An unauthenticated guest foothold combines with guest-reachable code execution or public external sharing to read business data in bulk without any login. In practice this is reached over the site's Aura endpoint (/s/sfsites/aura) with aura.token=null: RecordUiController/ACTION$executeGraphQL returns record data the guest user can see, and aura.ApexAction.execute invokes @AuraEnabled Apex — which, in a class that runs without sharing, skips record-level access control entirely and will accept arbitrary record ids. No credentials are involved at any point, so login-based controls (MFA, IP ranges, SSO) never engage.
Breaks the chain: Remove guest object/sharing access, ensure no guest-invokable Apex runs without sharing, and set external OWD to Private. Grant portal access only via sharing sets. Because the requests never reach a login page, tightening authentication does not mitigate this — the object permissions, sharing model and Apex sharing declarations are the controls that apply.
A low-trust authenticated user combines with a privilege-escalation permission (assign permission sets, manage users, author apex, modify metadata) to reach full org control.
Breaks the chain: Remove escalation permissions from non-admin profiles/permission sets and review who holds them.
Exposed secrets (hardcoded credentials, credentials in custom labels, debug logs, or broad CORS) combine with an external egress path (named credential or remote site) to exfiltrate data to attacker infrastructure.
Breaks the chain: Rotate and remove exposed secrets, tighten CORS origins, and review external callout endpoints.
A live Experience Cloud site accepts self-registration, and the external sharing model or portal-reachable code gives whoever holds an account more than their own records. Every other chain that starts from "an authenticated external user" assumes the attacker already has an account; this is the one that says anyone may have one, for the cost of an email address. The account is legitimate, so it arrives through the front door with a real session: MFA, login IP ranges and SSO all behave exactly as configured and none of them object, because nothing here is a bypass. What the attacker gets is decided entirely by the external OWD, the portal profile and whether the Apex or Flow reachable from the site enforces sharing. Self-registration alone is a supported feature and not a finding; the sharing model alone assumes an account the attacker may never obtain. The pair is the path.
Breaks the chain: Decide which half to close, because either breaks the chain. Turning self-registration off, or putting an approval step in front of it, restores the assumption every other control depends on. Leaving it on means treating the self-registration profile as hostile input: set external OWD to Private and grant through sharing sets rather than org-wide defaults, and make sure Apex and Flows reachable from the site run with sharing. Check what the self-registration handler assigns as the default profile and licence — the exposure is whatever that profile can reach, and it is rarely reviewed after the site goes live.
Files hosted by the org are fetchable without authentication — public Documents or static resources, content distribution links that never expire or ask for a password, or a site that grants guests file access — and nothing in the org would establish what those files contained or who collected them. Files are the blind spot in a sharing model. Org-wide defaults, sharing rules and field-level security all govern records, and none of them apply to a static resource served from a URL. Static resources in particular tend to accumulate the things front-end code needs and nobody re-reads: configuration, endpoint lists, and occasionally an API key that was only ever meant to reach the browser. This chain deliberately claims less than the guest chains do. It does not assert a pivot into org data, because there is none — anonymous file access returns the file and stops. What it asserts is that content left the org outside every record control, and that the absence of classification or monitoring means the question "what was in it" has no answer available after the fact.
Breaks the chain: Retrieve and read the exposed files before deciding how urgent this is: the exposure is whatever they actually contain, and that is knowable now in a way it will not be later. Then remove external availability from Documents and static resources that do not need it, set expiry and passwords on content distribution links, and turn off guest file access on sites that do not depend on it. Treat any credential found in a static resource as disclosed and rotate it rather than removing the file, since the file has already been served and may be cached anywhere.
The org already presents a real attacker capability — an unauthenticated foothold, a privilege-escalation path, or org takeover — and simultaneously lacks the controls that would notice it being used. Two or more of threat detection, Event Monitoring, a Transaction Security policy and SIEM forwarding are absent. This chain does not add exposure; it means the exposure already present would go unobserved, and an incident could not be reconstructed.
Breaks the chain: Close the detection gap first: enable Event Monitoring with adequate retention, turn on threat detection event storage, add a Transaction Security policy, and forward events to a SIEM. Then remediate the underlying access findings.
The org presents a unauth foothold entry point and findings that grant credential theft. Review whether these can be combined into an exploit path.
Breaks the chain: Treat the contributing findings as a single risk: remediating any one of them breaks the path.
The org presents a low trust authenticated entry point and findings that grant credential theft. Review whether these can be combined into an exploit path.
Breaks the chain: Treat the contributing findings as a single risk: remediating any one of them breaks the path.
Findings mapped to framework controls. “No findings detected” is not an attestation of compliance. See Scope & Liability.
| Control | Requirement area | Status |
|---|---|---|
| OWASP-A01 | Broken Access Control | 25 findings |
| OWASP-A02 | Cryptographic Failures | 3 findings |
| OWASP-A03 | Injection | 1 finding |
| OWASP-A05 | Security Misconfiguration | 12 findings |
| OWASP-A06 | Vulnerable and Outdated Components | 2 findings |
| OWASP-A07 | Identification and Authentication Failures | 5 findings |
| OWASP-A08 | Software and Data Integrity Failures | 3 findings |
| OWASP-A09 | Security Logging and Monitoring Failures | 6 findings |
| OWASP-A10 | Server-Side Request Forgery (SSRF) | 3 findings |
| Control | Requirement area | Status |
|---|---|---|
| LLM01 | Prompt Injection | No findings detected |
| LLM02 | Sensitive Information Disclosure | No findings detected |
| LLM05 | Improper Output Handling | No findings detected |
| LLM06 | Excessive Agency | No findings detected |
| Control | Requirement area | Status |
|---|---|---|
| SOC2-CC6.1 | Logical access controls | 27 findings |
| SOC2-CC6.2 | Registration and de-provisioning of users | No findings detected |
| SOC2-CC6.3 | Role-based access and least privilege | 4 findings |
| SOC2-CC6.6 | Boundary protection against external threats | 5 findings |
| SOC2-CC6.7 | Restriction of information transmission and movement | 3 findings |
| SOC2-CC7.1 | Detection of configuration changes and vulnerabilities | 3 findings |
| SOC2-CC7.2 | Monitoring for anomalies and security events | 8 findings |
| SOC2-CC8.1 | Change management | 2 findings |
| SOC2-CC9.1 | Risk mitigation for business disruptions | No findings detected |
| SOC2-CC9.2 | Vendor and third-party risk management | 1 finding |
| Control | Requirement area | Status |
|---|---|---|
| ISO-A.5.12 | Classification of information | 2 findings |
| ISO-A.5.14 | Information transfer | 3 findings |
| ISO-A.5.18 | Access rights | 11 findings |
| ISO-A.8.3 | Information access restriction | 17 findings |
| ISO-A.8.8 | Management of technical vulnerabilities | 4 findings |
| ISO-A.8.15 | Logging | 6 findings |
| ISO-A.8.24 | Use of cryptography | 1 finding |
| ISO-A.8.25 | Secure development life cycle | 2 findings |
| ISO-A.8.26 | Application security requirements | 4 findings |
| ISO-A.8.32 | Change management | 3 findings |
The Salesforce Security Health Check scored 71/100. Scores below 85 indicate security configuration gaps that should be addressed.
Remediation: Review the Security Health Check in Setup → Security Center → Health Check.
One or more settings deviate from Salesforce security recommendations at the high-risk level.
Remediation: Address each highlighted setting in Setup → Security Center → Health Check.
One or more settings deviate from Salesforce security recommendations at the medium-risk level.
Remediation: Review and address medium-risk settings in Setup → Security Center → Health Check.
SBS-ACS-004 requires documented justification for any user holding all three of ViewAllData, ModifyAllData, and ManageUsers simultaneously. This combination is equivalent to unrestricted org control.
Remediation: Reduce to the minimum necessary permissions. Document justification for each user in the system of record. Consider breaking this into role-specific permission sets.
Modify All Data grants unrestricted write access across all objects. This is one of the most powerful permissions in Salesforce. 4 of them also hold the super-admin combination and are rated in that finding; this severity reflects the other 1.
Remediation: Limit Modify All Data to essential system administrators only. Review each user and remove the permission from any non-essential accounts.
View All Data grants unrestricted read access across all objects, bypassing sharing rules and record-level security.
Remediation: Limit View All Data to essential users. Consider using permission sets scoped to specific objects instead.
Author Apex allows users to write and deploy Apex code, which can execute server-side logic with elevated privileges.
Remediation: Author Apex allows code deployment. Limit to developers with a genuine need.
A large number of permission sets increases administrative complexity and makes it harder to audit access effectively.
Remediation: Review and consolidate permission sets. Excessive numbers increase administrative complexity and expand the attack surface.
API Enabled is not granted by any custom profile or permission set. Standard profiles may still grant it.
Remediation: Continue monitoring as new permission sets and profiles are created.
There were 4 failed login attempts out of 60 total logins in the last 30 days.
Remediation: Investigate accounts with repeated failures. Consider IP restrictions or additional MFA policies for high-failure accounts.
All 0 connected app(s) are configured to require admin pre-authorization.
Remediation: Continue monitoring as new connected apps are added.
An external OWD of Public Read exposes all records to any Experience Cloud portal user. Attackers who create or compromise a portal account can enumerate the entire dataset for reconnaissance and data theft. Even without write access, bulk record exposure violates data minimisation principles and enables targeted attacks.
Remediation: Set external OWD to Private and use sharing sets or sharing rules to grant portal users access only to their own records.
An internal OWD of Public Read/Write means every authenticated user can read and modify all records regardless of record ownership. A compromised internal account, malicious insider, or over-permissioned integration user gains full access to the entire dataset. This undermines record-level access controls and violates least-privilege principles.
Remediation: Set OWD to Private or Public Read Only for sensitive objects. Use sharing rules, role hierarchy, or Apex managed sharing to grant specific access where needed.
All monitored API and resource limits are below 50% utilization.
Remediation: Continue monitoring limits as org activity grows.
Frequent permission and security changes can indicate privilege escalation activity or risky configuration drift.
Remediation: Review each change in Setup → Audit Trail. Investigate unexpected changes, especially outside change-management windows.
This org has no PermissionSet.PermissionsManageEventLogFiles field, which is usual when Event Monitoring is not licensed. Who can delete event monitoring data is therefore unestablished from permissions, and SBS-MON-002 is unevaluated rather than satisfied.
Remediation: If the org licenses Event Monitoring, review who holds "Manage Event Log Files" or "Delete Event Monitoring Data" in Setup → Permission Sets.
All active standard users have logged in within the past 90 days.
Remediation: Continue to run periodic user access reviews to catch future stale accounts.
No password, session, or MFA-related deviations were detected in the Security Health Check results.
Remediation: Continue monitoring password policies and MFA enforcement as Salesforce releases new security recommendations.
Administrator accounts without IP login restrictions can be accessed from any network, increasing exposure to credential-stuffing attacks.
Remediation: Add IP login ranges to all admin profiles in Setup → Profiles → Login IP Ranges, or enable MFA as a compensating control.
Guest users are present in this org. While no write access or overly permissive sharing rules were found, guest access should be periodically reviewed.
Remediation: Regularly review guest user profile permissions and sharing configurations as they represent an unauthenticated attack surface.
Remote sites with "Disable Protocol Security" enabled allow Apex to make callouts over plain HTTP, exposing data in transit to interception.
Remediation: Enable HTTPS on each endpoint and remove the "Disable Protocol Security" flag. Plaintext HTTP callouts should never be used for any integration.
Remote Site Settings control which external URLs Apex code can call. Entries should be reviewed periodically to remove unused entries.
Remediation: Audit each remote site setting to confirm it is still actively used. Remove unused entries to reduce the attack surface.
No active CSP Trusted Sites are configured. Salesforce applies default Content Security Policy headers. Add trusted sites only when loading external resources in Lightning components.
Remediation: No action required. When adding external resources, use HTTPS endpoints only.
No named credentials are configured. If this org makes external callouts, consider using Named Credentials to avoid hardcoded endpoints.
Remediation: Configure Named Credentials for any external service integrations rather than hardcoding endpoints in Apex.
Hardcoded Bearer tokens, Basic auth, or API keys in Apex source code expose credentials to anyone with metadata read access.
Remediation: Replace hardcoded credentials with Named Credentials. Rotate any exposed credentials immediately.
Classes with @AuraEnabled, @RemoteAction or @RestResource methods that use "without sharing" or have no sharing declaration execute without record-level access control. Attackers can supply arbitrary record IDs to read or manipulate data they should not access (IDOR). SBS-CPORTAL-001 requires server-side authorization for every record accessed via portal Apex.
Remediation: Add "with sharing" to all @AuraEnabled, @RemoteAction and @RestResource classes. Validate user ownership or sharing on every record accessed inside these methods.
Classes declared "without sharing" ignore the running user's record access and can access all data in the org.
Remediation: Replace "without sharing" with "with sharing" or "inherited sharing" unless there is a documented business requirement.
Apex classes without a sharing declaration default to "without sharing" behavior when called from a context that doesn't enforce sharing.
Remediation: Add explicit sharing declarations to all Apex classes. Use "with sharing" as the default, or "inherited sharing" for utility classes.
Summary of sharing declarations across 3 custom Apex classes.
Remediation: Aim for all classes to use "with sharing" or "inherited sharing".
All 1 active flows either enforce user sharing context or are not autolaunched/screen flow types.
Remediation: Continue to review flow settings when new flows are activated.
No sharing rules were found targeting the "All Internal Users" group on key objects.
Remediation: Continue to avoid broad sharing rules. Periodically review sharing configuration as the org grows.
No sensitive custom fields with excessive permission set access were found.
Remediation: Continue to apply restrictive field-level security to any new sensitive fields.
This is an inventory of currently active scheduled and batch Apex jobs in the org.
Remediation: Periodically review scheduled jobs to ensure all active automation is expected and authorized.
Org-wide Apex test coverage is 81%. Salesforce requires 75% minimum to deploy but higher coverage indicates better code quality and security.
Remediation: Increase test coverage, particularly for security-sensitive Apex classes handling authentication, data access, and external integrations.
No custom objects with credential-related naming patterns were found.
Remediation: Continue to avoid storing secrets in custom objects or custom settings. Use Named Credentials for external authentication.
SBS-ACS-005 requires all active users be on custom profiles. No violations found.
Remediation: Continue monitoring as new users are onboarded.
SBS-AUTH-001 requires production orgs to disable Salesforce credential logins. No username-password logins were found in LoginHistory for the past 30 days, which is consistent with SSO being enforced.
Remediation: Verify in Setup → Single Sign-On Settings that "Prevent Login with Salesforce Credentials" is enabled to enforce SBS-AUTH-001 at the org level.
SBS-AUTH-004 applies to external users with substantial access to sensitive data. No active portal user types were found in this org.
Remediation: If Experience Cloud sites are added in future, ensure SBS-AUTH-004 MFA requirements are met for external users.
This org has no PermissionSet.PermissionsUseAnyApiClient field, which is usual when API Access Control is not available. Who can bypass API client restrictions is therefore unestablished, and SBS-ACS-006 is unevaluated rather than satisfied.
Remediation: If API Access Control is enabled, review who holds "Use Any API Client" in Setup → Permission Sets.
Winter '27 requires the "Use Any API Auth" permission to authenticate with SOAP API login(). No login in the last 90 days used a SOAP API type, so no account is exposed to that change on the evidence available. LoginHistory retains six months, so an integration that runs less frequently than this window would not appear.
Remediation: No action needed. If you operate an integration that runs less often than quarterly, confirm its authentication method directly rather than relying on this window.
SBS-ACS-007 requires all non-human identities to be inventoried and documented. No standard users matching common service account patterns (by username) or never-logged-in users were found. This run could not gather the following signal(s): connected-app-run-as. Accounts identifiable only by connected-app-run-as are not represented here.
Remediation: As integration accounts are created, ensure they are documented with a named owner, stated purpose, and review date.
No active account matched an integration signal (Salesforce Integration licence, scheduled-job owner, never logged in, API-only logins, or a service-account username pattern), so there is no non-human identity holding surplus permissions. One qualification: the following classification signal could not be gathered on this run — connected-app-run-as — so an account reachable only by it was not examined.
Remediation: As integration accounts are created, grant them a dedicated permission set scoped to the objects and operations they actually use, rather than a broad profile.
SBS-FILE-001/002/003 govern the lifecycle of public content sharing links. No active public links were found in this org.
Remediation: Continue monitoring as files are shared externally.
SBS-DATA-004 requires field history tracking on sensitive objects to capture who changed what data and when, enabling post-incident investigation and audit evidence. The following objects have no tracked fields: Account, Contact, Lead, Opportunity, Case, Contract, Quote, User.
Remediation: Enable field history tracking on each listed object in Setup → Object Manager → [Object] → Fields & Relationships → Set History Tracking. At minimum track key sensitive fields: email addresses, phone numbers, revenue fields, owner changes, and status changes.
SBS-DATA-001 requires all data to be classified by sensitivity and SBS-DATA-002 requires PII to be identified. 7 key object(s) have no fields with a Compliance Group set: Account, Contact, Lead, Opportunity, Case, Contract, User.
Remediation: Enable and configure the Salesforce Data Classification feature in Setup → Data Management → Data Classification. Assign compliance groups (PII, PCI, HIPAA, GDPR, etc.) to sensitive fields on all objects that store personal or regulated data. Prioritise email, phone, address, financial, and health-related fields.
SBS-DATA-003 requires data at rest to be encrypted in line with its assigned classification. No Shield Platform Encryption keys were found, indicating either Shield is not licensed or encryption has not been configured for this org.
Remediation: Evaluate Salesforce Shield Platform Encryption for fields classified as sensitive or PII. If Shield is not available in your edition, document the compensating control (e.g., Classic Encryption for specific fields, or infrastructure-level disk encryption), and assess whether it meets the intent of SBS-DATA-003.
Expired certificates break all integrations, SSO logins, and JWT-based authentication that depend on them. Certificates expiring within 30 days require immediate replacement to avoid service disruption.
Remediation: Renew or replace expiring certificates immediately. Update all integrations and connected apps that reference these certificates. Test authentication flows after replacement.
No InstalledSubscriberPackage records were found. This org does not have any AppExchange or custom packages installed.
Remediation: No action required. Monitor for new package installations as part of your change management process.
No NetworkAccess (trusted IP range) records are configured. All users are subject to MFA and login challenge enforcement regardless of their network location.
Remediation: Continue to avoid configuring trusted IP ranges unless there is a documented, justified business requirement with compensating controls.
No SetupAuditTrail entries matching anonymous Apex execution patterns were found in the last 90 days. This indicates the Developer Console and anonymous Apex execution have not been used recently in production.
Remediation: Continue monitoring. If anonymous Apex execution is ever required, ensure it is pre-approved, logged, and reviewed.
No active TraceFlag records were found. No users or classes are currently being traced, so no sensitive data is being captured in debug logs.
Remediation: Continue monitoring. Remove debug traces promptly after troubleshooting sessions complete.
The org has a custom My Domain (acme) configured, which is a prerequisite for SSO enforcement and Enhanced Domains.
Remediation: Verify the login policy in Setup → My Domain prevents login from login.salesforce.com.
The AuthConfig for this org allows users to log in with Salesforce username and password, meaning SSO via your identity provider is not the only authentication path. Users can bypass SSO (and its MFA, conditional access, and session controls) by using direct credentials. Affected authentication configuration(s): Acme_Login.
Remediation: In Setup → My Domain → Authentication Configuration, disable "Login Page" (Salesforce credentials) as an authentication option. Ensure SAML/SSO is the only allowed method. Also enable "Prevent Login from login.salesforce.com" in My Domain settings.
No connected apps are configured in this org.
Remediation: Continue monitoring as connected apps are added.
The Organization object query returned no results.
Remediation: Verify the audit user has read access to the Organization object.
No active, unfrozen standard users were found in this org. MFA enforcement verification is not applicable.
Remediation: No action required.
No pending release updates were found. The org is current with all platform changes Salesforce has made available.
Remediation: After each Salesforce release (3× per year), review Release Updates in Setup to enable new updates promptly.
No custom Apex classes with API versions older than the baseline threshold were found. Modern API versions ensure classes benefit from current platform security behaviors and FLS enforcement.
Remediation: When developing new Apex classes, target the current API version. Periodically update old classes and regression-test to stay current.
Salesforce does not expose inbound SOAP API call details in SOQL-queryable objects. They are captured only in EventLogFile with EventType = "API". The API_TYPE column in those log files distinguishes SOAP callers: "E" = Enterprise WSDL, "P" = Partner WSDL. LoginHistory cannot make this distinction; SOAP login() calls and UI logins both appear as LoginType = "Application". If external systems are calling this org via the Enterprise or Partner WSDL, those callers should be migrated to REST API or connected-app-governed OAuth flows.
Remediation: In Setup → Event Monitoring, download an API event log and filter on API_TYPE = "E" or "P" to identify active SOAP callers. For each SOAP caller, work with the integration owner to migrate to REST API using a connected app with appropriate OAuth scopes and IP restrictions.
No connected apps exist in this org.
Remediation: Continue monitoring as new connected apps are added.
Transaction Security Policies provide automated, real-time threat detection and response within Salesforce. With no policies enabled, the org has no automated defence against: credential stuffing and brute-force attacks, impossible-travel logins (e.g. login from two countries within minutes), bulk data downloads and mass API queries, concurrent session anomalies, and privilege escalation attempts. An attacker who compromises any credential can operate without triggering any automated response.
Remediation: Enable Transaction Security (Setup → Transaction Security Policies) and create policies for at minimum: (1) Login anomalies: impossible travel, concurrent sessions from different IPs; (2) Data export: block or notify on bulk Report/List View exports; (3) API anomalies: high-volume REST/SOAP queries. Recommended actions: Block + Notify for critical events; Notify for informational events.
37 failed login attempts recorded in the last 7 days, but no single account exceeded the brute-force threshold (20 failures). This volume appears consistent with normal user error.
Remediation: Continue monitoring. Configure Transaction Security Policies to alert on anomalous login activity as volumes change.
Self-registration allows anyone on the internet to create a portal account. Attackers exploit this to: (1) enumerate valid email addresses already registered; (2) create portal accounts to access any data exposed to authenticated portal users via OWD, sharing rules, or misconfigured permissions; (3) pivot from a portal user account to exploit object-level permission misconfigurations. If OWD for sensitive objects is set to Public Read or wider for external users, self-registration gives attackers direct data access without any approval step.
Remediation: Disable self-registration unless explicitly required (Setup → Digital Experiences → <site> → Administration → Registration). If required, implement email domain allow-listing, CAPTCHA, and manual approval workflows. Immediately audit external OWD settings and guest user permissions for sites with self-registration enabled.
Sites with an active Guest User allow unauthenticated visitors to access the site without creating an account. Any Salesforce objects or records accessible to the Guest User profile are exposed to the entire internet. Misconfigurations in guest user object permissions or OWD external settings result in public data exposure.
Remediation: Review guest user object permissions for each site (Setup → Profiles → <Guest Profile> → Object Settings). Ensure external OWD is Private for all sensitive objects. Run the Guest User Access check for detailed permission findings.
No custom labels were found in the org namespace.
Remediation: Continue using Named Credentials and Custom Metadata (protected) for secrets storage.
All Report folders are restricted to specific users, roles, or groups. No folder exposes reports to all authenticated users.
Remediation: Continue reviewing report folder permissions as new reports and folders are created. Ensure sensitive reports are in Private or Shared folders with explicit access grants.
These permissions let a user create accounts, reset passwords, assign permission sets, modify metadata, or register auth providers: the primitives an attacker uses for lateral movement and persistence after an initial foothold. 4 super-admin(s) also hold them and are rated in the super-admin finding instead.
Remediation: Remove these permissions from non-administrator profiles/permission sets and document who legitimately needs each one.
No cross-origin allowlist entries exist, so browser-based cross-origin token theft via CORS is not a concern.
Remediation: If CORS entries are added later, allow only exact, fully-qualified HTTPS origins.
No inbound email service is active, so no Apex runs on receipt of email.
Remediation: If one is added, require authentication and restrict accepted senders.
No outbound messages are defined, so there is no automated POST of org data to external endpoints to review.
Remediation: If outbound messages are added later, use HTTPS endpoints and avoid including the session ID.
No Document is marked "Externally Available Image", so none are retrievable without authentication.
Remediation: Continue to keep Documents private unless anonymous access is explicitly required.
All static resources use Private cache control or none exist.
Remediation: Continue to keep static resources Private unless public delivery is required.
These objects have an external org-wide default of Read or ReadWrite, are readable by the guest profile, and are modelled by the UI API, so every record is reachable by any unauthenticated visitor who can enumerate counts and page through records in bulk. Reachable unauthenticated via the Experience Cloud UI API (GraphQL) through aura://RecordUiController/ACTION$executeGraphQL on /s/sfsites/aura (aura.token=null).
Remediation: Set external OWD to Private for these objects, and remove Read from the guest profile/permission sets unless a specific public dataset is intended. Then verify no guest-accessible Apex returns the data.
Guest file access lets unauthenticated visitors read public files (ContentVersion/ContentDocument/Attachment). Combined with the UI API, file IDs can be enumerated and content downloaded via the file servlet (/sfc/servlet.shepherd/version/download).
Remediation: Disable guest file access (Network setting "Let guest users access public files") unless a specific public file library is intended.
Guest member visibility exposes other site members (User records, names, profile data) to unauthenticated visitors, leaking member identities and enabling enumeration.
Remediation: Disable "Let guest users see other members of this site" unless member directories must be public.
The "Secure guest user record access" Release Update is no longer exposed via the API (usually because it was auto-activated in an earlier Salesforce release). Enforcement is therefore assumed but not API-verifiable. The two settings that jointly close the guest-ownership-defeats-OWD vector cannot be read programmatically.
Remediation: In Setup → Sharing Settings, confirm "Secure guest user record access" is on and "Assign new records created by guest users to the default owner" is enabled. Then confirm no guest user OWNS records (see the guest-object-exposure finding) and that guest access is granted only via minimal guest user sharing rules.
The Threat Detection anomaly stores are queryable but hold no events in the last 180 days. Storage may have been enabled only recently, or detection is not generating events. Until events accumulate, "no anomalies" is not evidence of safe behaviour, and historical anomalous guest access cannot be reconstructed.
Remediation: Confirm storage is enabled for the anomaly events (Setup > Event Manager) and has been for the full retention window. Verify Transaction Security / Threat Detection policies are active and alerting.
No DelegateGroup records exist, so there is no delegated-admin escalation surface.
Remediation: If delegated administration is introduced, scope each group minimally and review assignable permission sets.
When "Administrators Can Log In as Any User" is enabled (Setup → Login Access Policies), any administrator can impersonate any user and access all of their data with no per-session consent. This run could not read SecuritySettings, so the policy must be confirmed manually.
Remediation: In Setup → Login Access Policies, disable "Administrators Can Log In as Any User" unless there is a documented support need, and require users to grant time-boxed login access instead.
No profiles/permission sets grant Weekly Data Export, nor API access combined with View/Modify All Data.
Remediation: Keep Weekly Data Export and View/Modify-All limited to trusted admins, and prefer scoped integration users for extracts.
No active Visualforce Force.com Sites were found, so there is no classic unauthenticated site surface.
Remediation: If a classic site is activated later, review its guest user profile before it goes live.
No AuthProvider or SamlSsoConfig records exist, so there is no external federation surface to review.
Remediation: If external identity is added later, restrict just-in-time provisioning to least-privilege profiles and validate the IdP certificate.
No active guest user has "API Enabled" or "Bulk API Hard Delete", so guests cannot drive the raw API.
Remediation: Keep API and Bulk permissions off guest profiles as sites change.
A guest permission set or profile grants Read on the User object. Object-level read is what makes User queryable at all for a guest; combined with any sharing path that exposes records — a public external OWD, a user sharing rule, or guest member visibility on an Experience site — it turns the User table into an enumerable directory reachable over the UI API.
Remediation: Remove Read on the User object from guest profiles and guest permission sets. Where site components must show a name, expose it through Apex that returns only the specific fields required.
No ExternalCredential records exist, so there is no external-credential authentication surface to grade.
Remediation: When adding External Credentials, prefer OAuth/JWT or AWS SigV4 over custom or no-authentication schemes.
LoginHistory returned no successful logins in the window, so no login-distribution anomaly could be computed.
Remediation: Re-run after normal activity; forward LoginHistory to a SIEM for continuous anomaly detection.
These browser-session hardening settings differ from Salesforce's recommended values. Weak framing, CSRF, session-lock, or XSS-protection settings enable clickjacking, cross-site request forgery, session hijacking, and reflected-XSS attacks against authenticated users.
Remediation: In Setup → Session Settings (and Session Security Levels), align each flagged setting to the recommended value: highest clickjack protection for all pages, CSRF protection on GET and POST, "Lock sessions to the IP address" and "to the domain", content-sniffing and XSS protection on, and warnings on redirects to external URLs.
No fields on Account, Contact, Lead, Opportunity, Case, Contract, User, Individual carry a ComplianceGroup (data classification), so encryption coverage cannot be assessed against a sensitivity baseline. Custom objects are not scanned. Classification is the prerequisite — see the data-classification check.
Remediation: Classify PII/PHI fields (Setup → Data Classification) first, then encrypt the sensitive ones with Shield Platform Encryption.
The per-site Content Security Policy level and Lightning Web Security toggle are not reliably exposed to the API, so they must be confirmed manually. A "Relaxed CSP" level or disabled Lightning Web Security lets inline/third-party scripts run on pages an unauthenticated guest can reach, widening the XSS and script-injection surface.
Remediation: For each site: Setup → Digital Experiences → (site) → Administration → Security & Privacy — set the CSP level to "Strict CSP" and enable Lightning Web Security. Review any Trusted Sites/URLs added to relax CSP.
This org is a production org, so sandbox data-masking does not apply here.
Remediation: Apply Data Mask to sandboxes seeded from this production org so PII/PHI is not copied in the clear.
These active users have accumulated effective permissions equivalent to a System Administrator (either "Modify All Data" directly, or "Manage Users" combined with "Assign Permission Sets", which lets them grant themselves anything) but sit on a different profile. Such "shadow admins" are easy to miss in profile-based reviews, yet a takeover of any one grants full org control. The access is reached via the user's profile, assigned permission sets, or permission set groups combined.
Remediation: Review each user's permission sets and profile. Remove "Modify All Data" / the Manage Users + Assign Permission Sets pairing unless the role genuinely requires org administration, and consolidate true admins onto a controlled admin profile.
Inventory of active users whose effective permissions include one or more catalogued high-risk permissions. Use this as the privileged-access baseline for least-privilege review.
Remediation: Periodically confirm each privileged user still requires their high-risk permissions; remove any that are no longer needed.
Zero GenAiPromptTemplate records were returned.
Remediation: Review grounding sources whenever new Prompt Templates are created.
Zero DataSpace records exist in this org.
Remediation: Define segmented Data Spaces if Data Cloud is activated in the future.
Zero active Apex triggers subscribe to custom Platform Event objects (__e).
Remediation: When subscribing to Platform Events, ensure publish permissions are strictly scoped to internal authorized actors.
External services and declarative flows were inspected; no hardcoded API keys or uncredentialed external service endpoints detected.
Remediation: Continue utilizing Named Credentials and External Credentials for all declarative HTTP integrations.
This run could not read the Device Flow and Username-Password Flow setting from OAuth and OpenID Connect Settings, so whether it is enabled is unknown. Both flows let a token be issued outside the browser sign-in, bypassing MFA and conditional access.
Remediation: In Setup → OAuth and OpenID Connect Settings, confirm "Allow OAuth Device Flow" and "Allow OAuth Username-Password Flows" are off unless a documented integration needs them.
This run could not read SecuritySettings, so whether Delegated Authentication is enabled is unknown. 0 administrator profile(s) hold "Is Single Sign-On Enabled", which routes their sign-in through the delegated gateway if it is on.
Remediation: In Setup → Single Sign-On Settings, check whether Delegated Authentication is enabled. If it is, the gateway must be HTTPS with mutual TLS, and administrator profiles should not hold "Is Single Sign-On Enabled".
Zero DelegateGroup records are configured in this org.
Remediation: Continue avoiding unmonitored delegated administration groups.
Zero AuthProvider records in this org configure an automated Registration Handler.
Remediation: When configuring Registration Handlers, avoid execution as System Administrator and verify email authenticity.
Zero active EmailServicesFunction records exist in the org.
Remediation: When creating inbound email services, enforce sender restrictions and SPF/DKIM verification.
Outbound emails sent from Salesforce without DKIM signatures are vulnerable to domain spoofing, recipient rejection, or landing in junk folders. Active DKIM keys ensure cryptographic origin authentication for all outbound Salesforce messages.
Remediation: Generate and activate DKIM keys in Setup → DKIM Keys for all corporate sending domains used by Salesforce.
External portal users are constrained to their own account boundaries without hierarchical over-sharing.
Remediation: Maintain standard Private external OWD and avoid unreviewed Super User grants.
Zero RestrictionRule records configured across standard and custom objects.
Remediation: When deploying Restriction Rules, ensure they remain active and avoid multiple conflicting rules on the same entity.
Zero InstalledSubscriberPackage records were identified.
Remediation: Continue inventorying new packages when installed.
Zero TenantSecret records were returned.
Remediation: Generate tenant encryption secrets if Shield Platform Encryption is enabled.
SBS-DEP-001 requires all deployments to be performed by a single designated deployment identity, not individual user accounts. 3 distinct users were found in deployment-related audit trail entries (Change Sets, Developer Tools, Packages, Metadata) over the past 90 days. Multiple deployers make it harder to audit changes and bypass change-management controls.
Remediation: Centralise deployments through a CI/CD pipeline that authenticates as a single named service account. Revoke direct deployment access from individual admin users.
SBS-DEP-003 requires monitoring for unauthorized deployment modifications. Deployments performed by administrator-profile users are harder to distinguish from emergency break-glass changes and are more likely to occur outside of a change-management window.
Remediation: Replace admin-user deployments with a CI/CD pipeline using a dedicated integration user with only deployment-required permissions. Reserve individual admin accounts for emergency use only, and document any emergency deployments in the system of record.
SBS-CODE-003 requires a persistent logging framework and SBS-CODE-004 prohibits sensitive data in logs. No violations were detected in the scanned Apex classes.
Remediation: Continue monitoring as new Apex classes are added to the org.
No connected apps were found in the org. No inactivity check is needed.
Remediation: Continue monitoring as new connected apps are added.
No rows were returned from OauthToken, so no app currently holds a standing OAuth authorisation in this org.
Remediation: Re-check after authorising any new integration.
Apex classes declared "without sharing" bypass record-level visibility AND have no field-level or object-level permission checks, meaning any user who triggers the code can read or write any record and field regardless of their assigned permissions. This is the most exploited Salesforce access control vulnerability. OWASP Salesforce Top 10 ranks CRUD/FLS bypass as the #1 risk.
Remediation: Refactor to use "with sharing" where possible. Add `Security.stripInaccessible()` before DML and `Schema.SObjectType.[Object].fields.[Field].isAccessible()` before displaying fields. Where "without sharing" is required for a technical reason, document the justification and tighten the scope.
These Apex classes can be invoked by unauthenticated guest users AND do not enforce record-level sharing, either themselves or in a helper class they call that is declared "without sharing". This is the classic Salesforce guest-user exploit chain: an attacker calls the class and reads or writes business data in bulk with no login. Object-level guest permissions do not mitigate this: the class runs in system context.
Remediation: Add "with sharing" to every guest-reachable Apex class and to every helper it calls, enforce CRUD/FLS, and remove guest execution access from any class that does not strictly need it.
No Apex classes with the @RestResource annotation were found in the org namespace.
Remediation: Continue monitoring as new Apex code is developed.
No Visualforce pages in the org namespace were found.
Remediation: Continue monitoring as new pages are added.
This org defines no Lightning Message Channels, so there is no cross-component message bus to expose.
Remediation: No action required.
SBS-MON-001 requires Event Monitoring storage to be enabled so that login, API access, and data export events are captured. No EventLogFile records exist for the past 35 days, indicating Event Monitoring is either not licensed or not configured.
Remediation: Enable Event Monitoring in Setup → Event Monitoring Settings. If the feature is not licensed, raise with your Salesforce account team. SBS-MON-001 compliance requires it.
Event Monitoring is enabled but produced no EventLogFile blobs in the retention window. Stream logs to a SIEM for durable coverage.
Remediation: Enable Event Monitoring and forward guest event logs to a SIEM so this analysis has a durable window.
All 0 active, unfrozen standard users have at least one MFA method registered in TwoFactorInfo. Users who have not registered a method cannot complete MFA challenges and may be locked out of the org if MFA is enforced.
Remediation: Continue monitoring MFA registration as new users are onboarded. Ensure new user onboarding includes an MFA registration step before their first login.
SBS-MON-003 requires suspicious login activity to be monitored and alerted on. SBS-MON-004 requires API activity anomalies to be detected. No signals of an external monitoring or SIEM integration were found across Named Credentials, Remote Sites, Connected Apps, or Scheduled Apex jobs. Without external log forwarding, Event Monitoring data remains unanalysed and no automated alerts can be generated.
Remediation: Integrate Salesforce Event Monitoring with a SIEM platform (Splunk, Datadog, Sumo Logic, Microsoft Sentinel, etc.) using the EventLogFile API or Salesforce Shield Event Streaming. Configure alerts for: repeated failed logins, off-hours API access, bulk data export events, and unusual login geolocations (SBS-MON-003). Enable API usage anomaly detection (SBS-MON-004).
No active internal user has a registered MFA method, so there is no method strength to assess. Missing registration itself is reported by the MFA registration check.
Remediation: None for method strength. Address MFA registration coverage first.
Only super-admins hold flagged combinations; they already have unrestricted control and are rated in the super-admin finding (users-super-admin-combo). No other active user holds a flagged combination.
Remediation: Continue to separate user administration, code authorship, identity, and data-access duties across roles.