Penetration testing a Salesforce implementation means testing what your team configured and built on top of the platform, not Salesforce's underlying infrastructure. That distinction defines the entire engagement: scope, methodology, findings, and what a report can and cannot tell a CISO or auditor about your org's actual risk.
TL;DR
Why This Matters
Salesforce is a low-code platform, which means business teams change permission sets, sharing rules, and Flows without going through the same review process as application code. Every one of those changes can widen or narrow data access, and most orgs have no process to catch a misconfiguration before it ships.
The compliance exposure compounds the technical risk. Organizations running SOC 2, PCI DSS, or HIPAA programs that store cardholder data, PHI, or customer PII inside Salesforce objects need evidence that access controls actually hold under adversarial testing, not just a passing configuration scan. Auditors increasingly ask for penetration test evidence that covers custom objects and Apex logic specifically, not a generic infrastructure report that says nothing about your org.
A misconfigured sharing rule or an Apex class running "without sharing" can expose an entire object's records to users who should never see them. That failure mode does not show up in a vulnerability scanner. It shows up when a tester logs in with a low-privilege profile and pulls data that profile was never supposed to reach.
How to Penetration Test a Salesforce Implementation
A Salesforce penetration test follows a defined methodology, built around the parts of the platform your team actually controls: configuration, custom code, integrations, and identity.
For a deeper walkthrough of scope decisions specific to this platform, the Salesforce implementation penetration testing guide covers engagement structure in more depth.
Configuration and Permission Model Review
This is the highest-yield area of a Salesforce penetration test because most real-world data exposure comes from configuration, not code. Testers examine:
A profile that looks restrictive on paper can still expose records through a sharing rule nobody remembers configuring two years ago. Manual testing catches that; a configuration export review often does not.
Custom Apex Code and Lightning Web Components
Apex runs with system-level privileges by default. Any class declared without the with sharing keyword bypasses the org's sharing rules entirely, and a class that skips CRUD/FLS checks can return or modify fields the calling user's profile should never touch.
Common findings in this category:
Methodology and tooling for this layer overlaps significantly with standard API penetration testing methodology, since Apex REST and SOAP endpoints behave like any other API surface once exposed externally.
Integration, API, and Connected App Security
Every connected app, Named Credential, and integration user is a potential path into the org from outside Salesforce. Testers evaluate:
Salesforce API Security Checklist
Identity, SSO, and Authentication Controls
Most enterprise Salesforce orgs federate authentication through SAML or OAuth-based SSO. Testers validate assertion signature checks, audience restriction enforcement, session timeout configuration, and whether MFA is enforced at the identity provider or bypassable through a direct Salesforce login page. Weaknesses here mirror issues found across single sign-on penetration testing engagements on other platforms — a misconfigured SAML assertion is a SAML problem whether it federates into Salesforce or any other application.
Experience Cloud and External-Facing Sites
Experience Cloud sites authenticate anonymous visitors through a Guest User profile, and that profile's permissions are the single most common source of external Salesforce data exposure. Testers check whether the Guest User profile can query, insert, or export records on objects it should never touch, and whether object sharing settings for community users leak internal record data to external portal visitors.
Data Sharing Rules and Field-Level Security
Sharing rules and field-level security work together to control who sees what. Testing this layer means attempting cross-object and cross-profile record access with every distinct user type in the org, not just admin and standard user profiles.
Salesforce Penetration Test vs Health Check vs Continuous Testing
Salesforce Health Check
Penetration Test
Continuous Security Testing
Why Salesforce Pentest Scope Varies
Scope and effort on a Salesforce engagement depend on a handful of measurable factors:
Does Salesforce Allow Penetration Testing of Your Org?
Salesforce does not require customers to request pre-authorization before penetration testing their own org, as long as testing follows Salesforce's published testing policy. That policy prohibits testing shared multi-tenant infrastructure, denial-of-service techniques, and testing outside your own licensed org — the restriction is on Salesforce's shared platform, not on the configuration and code your team owns.
How Often Should You Penetration Test a Salesforce Implementation?
Test frequency should track configuration change velocity, not a fixed annual calendar. Orgs that ship new Flows, permission set changes, or custom Apex regularly carry more drift risk between scheduled annual tests, and compliance frameworks like SOC 2 typically expect testing evidence tied to material changes in the environment, not just a once-a-year checkbox.
How Do You Choose a Provider to Pentest Salesforce?
Salesforce testing requires platform-specific knowledge that generic infrastructure pentest teams often lack — understanding of Apex sharing semantics, permission set group interactions, and Experience Cloud guest user risk is not interchangeable with general web application testing experience.
CISO / Security Lead
Compliance / Audit Team
Engineering Team
Executive Sponsor
Selection criteria worth applying:
AppSecure Security runs hacker-led, manual penetration tests for SaaS, fintech, and healthcare teams running production workloads on Salesforce and adjacent platforms, with methodology built around the platform-specific risks covered above rather than generic scan output. Teams evaluating providers more broadly can compare approaches in the guide to penetration testing services for SaaS companies, and teams that need a wider view of exposed assets before scoping the engagement can start with an attack surface management assessment.
Scope a Salesforce penetration test
Talk to AppSecure's offensive security team about testing your Salesforce configuration and custom code.
FAQ
1. How do you penetration test a Salesforce implementation?
You test the configuration and code your team built on the platform: permission sets, sharing rules, custom Apex, connected apps, and Experience Cloud sites. Salesforce's own infrastructure is out of scope for customer-run tests.
2. Does Salesforce require permission before you penetration test your org?
No pre-authorization is required for testing your own org as long as testing follows Salesforce's published policy, which prohibits testing shared multi-tenant infrastructure or running denial-of-service techniques.
3. What is the difference between a Salesforce Health Check and a penetration test?
Salesforce Health Check is an automated scan of baseline configuration settings. A penetration test is manual, hacker-led testing of custom Apex, permission logic, and integrations under adversarial conditions.
4. Can a vulnerability scanner find Salesforce sharing rule misconfigurations?
No. Broken sharing rules and business logic flaws require a tester to authenticate as different profiles and attempt cross-record access; automated scanners do not simulate authenticated, role-based access abuse.
5. What Apex code issues show up most often in Salesforce penetration tests?
SOQL injection, missing with sharing declarations, unauthenticated Apex REST endpoints, and Lightning Web Components calling Apex without proper authorization checks are the most common findings.
6. Do Experience Cloud sites need separate penetration testing?
Yes. Experience Cloud sites authenticate visitors through a Guest User profile, and testing that profile's object and field access is a distinct testing activity from internal org testing.
7. How does Salesforce penetration testing support SOC 2 or PCI DSS compliance?
Auditors under SOC 2 and PCI DSS increasingly expect evidence that custom objects and Apex logic were tested directly, not just a generic infrastructure report unrelated to the Salesforce environment.
8. How often should a Salesforce org be penetration tested?
Testing frequency should track configuration and code change velocity rather than a fixed annual schedule, since permission sets and Apex can change faster than a yearly test cycle catches.
9. Should integrations and connected apps be included in a Salesforce pentest?
Yes. Every connected app and integration user is a separate trust boundary, and OAuth scope or IP restriction misconfigurations on these integrations are common findings.
10. What should a Salesforce penetration test report include?
A usable report ties findings to specific Apex classes, permission sets, or Flows, maps results to the relevant compliance framework, and includes retest validation once fixes are deployed.
One Last Thing
The highest-severity Salesforce findings rarely come from a zero-day in Apex — they come from a sharing rule or permission set group that quietly widened access months before anyone tested it. Configuration drift, not code vulnerabilities, is the primary driver of Salesforce data exposure in 2026, which is exactly why testing needs to track change velocity rather than a fixed annual date on the calendar.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.svg)
.webp)
