Salesforce security is a configuration problem, not a platform one. Salesforce secures the infrastructure and application; you own the org's profiles, permission sets, object/field security, sharing rules, guest/community access, custom Apex and integrations - and that's where nearly every incident lives. A specialist assessment targets the Salesforce permission and sharing model: over-permissive profiles, exposed fields, sharing-rule leaks, guest/community users seeing internal data, insecure Apex (sharing bypass, injection), and over-scoped connected apps. Testing is mostly configuration review + authenticated testing within Salesforce's testing policy (sandbox for intrusive tests). A generic web tester misses it because these constructs are Salesforce-specific. Details below - related to our SaaS and SAP work.
// 01 Why Salesforce is different
Salesforce isn't a website you point a scanner at - it's a platform with its own security model: profiles, permission sets, object- and field-level security, sharing rules, roles, and the Apex programming language for custom logic. Its security depends overwhelmingly on how your org is configured, and it holds some of your most sensitive data: customer records, sales pipeline, contracts, and often personal or financial information under the PDPL or GDPR. The result is that a generic web tester pointing standard tools at your Salesforce login finds almost nothing that matters, because the real risks - a sharing rule that exposes every account, a community user who can query internal objects - live in Salesforce-specific constructs the tool has no concept of. Salesforce needs testing that understands its model.
// 02 The shared-responsibility line
The single most important idea in Salesforce security is shared responsibility. Salesforce secures the platform - infrastructure, uptime, the core application and its code. You secure your org's configuration: the users, profiles and permission sets, sharing rules, field-level security, guest and community/Experience Cloud access, and any custom Apex, Lightning components and integrations you build. The overwhelming majority of Salesforce data-exposure incidents fall on the customer side of that line - a misconfiguration exposing data, not a breach of Salesforce itself. So a security assessment concentrates on your responsibilities, because that's the risk you actually control - the same principle as cloud shared responsibility.
// 03 The misconfigurations we find
Over-permissive access
Profiles and permission sets granting far more than users need - the root of most exposure.
Sharing & field leaks
Sharing rules and field-level security exposing records and sensitive fields to the wrong users.
Guest / community access
Guest and Experience Cloud users configured to reach internal data - a classic public-exposure route.
Insecure Apex & apps
Apex that bypasses sharing (without sharing) or has injection flaws; connected apps with excessive scopes.
Notice the pattern: these are access-control failures in Salesforce's own model - the platform equivalent of the broken object-level authorisation that leads web findings. One over-shared object can expose your entire customer base.
// 04 The guest & community exposure trap
The finding that most often turns into a public breach is guest and community/Experience Cloud misconfiguration. Salesforce lets you build public-facing sites and community portals on top of your org - and if the guest user profile or a community user is granted access to objects and fields it shouldn't have, unauthenticated or low-privilege external users can query internal data. There have been well-publicised cases of organisations inadvertently exposing sensitive records through misconfigured Experience Cloud sites. Because these sites are internet-facing and the access is granted quietly through configuration, the exposure persists until someone specifically tests what a guest or community user can actually reach. That test - enumerating accessible objects and fields as an external user - is a core part of any Salesforce assessment, and it's exactly the kind of logic-and-config check a scanner can't perform.
// 05 How the engagement runs
A Salesforce assessment blends configuration review with authenticated testing, within Salesforce's rules. Salesforce permits security testing of your own org, but it must follow their testing policy - typically intrusive testing in a sandbox, and no denial-of-service against the shared platform. The work: review the permission and sharing model (profiles, permission sets, sharing rules, field security); test what each role, guest and community user can actually access by authenticating at each level and attempting to reach data they shouldn't; review custom Apex for sharing bypass and injection; and assess connected apps and integrations for excessive scopes. Most of it is your configuration and code, not attacks on Salesforce's infrastructure - which stays their responsibility. The output maps findings to the data they expose and to your compliance obligations, per our methodology.
// 06 Frequently asked questions
Why does Salesforce need a specialist assessment?
It runs highly sensitive data and its security depends heavily on how you configure it, not just Salesforce's platform. Most Salesforce breaches come from misconfiguration - over-permissive object/field access, sharing rules exposing records, guest/community users seeing too much, insecure Apex. These are specific to the Salesforce permission and sharing model, which a generic web tester doesn't know.
Whose responsibility is Salesforce security?
Shared. Salesforce secures the platform, infrastructure and application code; you're responsible for your org's configuration - users, profiles, permission sets, sharing rules, field security, guest/community access, and custom code and integrations. Most incidents stem from the customer side of that line, so an assessment focuses on your responsibilities.
What are the most common misconfigurations?
Over-permissive profiles and permission sets; object and field-level security exposing sensitive fields; sharing rules letting users see records they shouldn't; guest and community users accessing internal data; insecure Apex that bypasses sharing or has injection flaws; and over-scoped connected apps. These persist quietly until someone tests the permission and sharing model.
Can you pentest Salesforce, and are there rules?
Yes - Salesforce permits testing your own org, but you must follow their testing policy: typically intrusive testing in a sandbox, and no denial-of-service against the shared platform. A competent assessment focuses on your org's configuration, permission and sharing model, guest/community access and custom code within those rules - mostly configuration review and authenticated testing, not attacks on Salesforce's infrastructure.
// 07 Related reading
- Penetration testing for SaaS and SAP security assessment — adjacent platform work.
- Broken object-level authorisation — the web equivalent of Salesforce sharing leaks.
- Requirements by framework and our methodology.