Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Salesforce permits customers to penetration test their own orgs, but only after you have accepted its penetration testing agreement, and the terms rule out anything that stresses shared infrastructure. The findings that matter are almost never platform bugs. They are your configuration and your custom code, and a test that spends its time probing login.salesforce.com has wasted the budget.

Get the permission right first

Salesforce publishes a penetration testing agreement that must be accepted before testing begins. Read the current version on Salesforce’s security pages rather than relying on what a blog post said two years ago, because the process and the scope language have changed more than once.

The constraints are consistent in spirit even as the wording moves:

  • Test only orgs your organisation controls. Testing another customer’s org or a shared endpoint is out of bounds.
  • No denial of service, no load or stress testing, no attempts to degrade the service for other tenants.
  • Do not test Salesforce’s own corporate systems or infrastructure you do not license.
  • Report anything that looks like a genuine platform vulnerability to Salesforce rather than exploiting it further.
  • Check whether your specific products or tester arrangements require notification, and keep the correspondence with your audit evidence.

Brief your tester on all of this before they start. External testers accustomed to ordinary web applications frequently open with scanning behaviour that is prohibited here.

Where to test

A full copy sandbox is the usual answer: same configuration, same code, same data volume shape, no risk to live records. The gap to watch is configuration drift. Sandboxes often have different connected apps, different integration users and different guest user setups, so confirm the delta before concluding that a finding does or does not apply to production.

Some things genuinely only exist in production: real OAuth grants, real named credentials, the live Experience Cloud site. Handle those with a narrow, agreed, read-mostly scope rather than skipping them.

What is actually worth testing

This is the part that separates a useful engagement from an expensive one.

  • Guest and unauthenticated access. Any public Experience Cloud site or Site.com page. What records can an unauthenticated visitor reach, what objects are exposed, and what does the guest user profile permit.
  • Apex controllers exposed to the client. Every @AuraEnabled method invoked directly with arbitrary parameters, particularly record Ids belonging to other users. This is where real vulnerabilities live.
  • Apex REST and custom web services, tested as a low-privilege user rather than an administrator.
  • Object and field permissions via the API. Log in as an ordinary user and query the objects they should not reach. The UI hides plenty that the API returns.
  • SOQL injection in any dynamic query built from user input.
  • Sharing model bypass. Classes running without sharing, flows in system context, and anything that returns records the caller could not query themselves.
  • Files. ContentDocument access is a separate model and it surprises people regularly.
  • Connected apps and OAuth scopes, checking whether a token grants more than the integration needs.

Give the tester a low-privilege user account, a session, and the documentation. A black-box test against a Salesforce org mostly rediscovers that Salesforce requires authentication.

Combine it with static analysis

Salesforce Code Analyzer will find a proportion of the code-level issues far more cheaply than a human testing by hand: missing CRUD and field-level checks, unescaped output, dynamic SOQL built by concatenation, classes without a sharing declaration. Run it first, fix what it finds, then let the tester spend their time on logic flaws that no scanner catches.

Reading the report

Expect some noise. Findings about Salesforce-owned headers, TLS configuration on Salesforce domains, or the behaviour of the standard login page are not yours to fix and should be filtered before the report reaches a steering committee.

What deserves attention: anything where a user reached data outside their permissions, anything reachable without authentication, and anything involving an integration credential. Those three categories are the reason for the exercise.

Frequently asked

Can I run automated scanners against my org? Only within the agreement’s terms, and not in ways that generate load. Confirm the current position before pointing any tool at the platform.

Do I need to test every release? No. Test after significant custom development, particularly anything guest-facing. Static analysis in the pipeline covers the rest.

Will Salesforce provide a pen test report for the platform? Salesforce publishes its own certifications and reports through its compliance portal. Those cover the platform, not your configuration.

What is the most common real finding? An @AuraEnabled method in a class with no sharing declaration that accepts a record Id from the client. It shows up again and again.