If you're a medium-sized or large company, you're likely using Salesforce to help you maintain relationships with customers, track orders and invoices, or build marketing campaigns. You may also have it running customer-facing services on your website or tracking shipments and third-party suppliers. Or you may be using Salesforce for much more.
"People are using [Salesforce] in the healthcare sector for patient data," says Justin Hazard, Principal Security Architect at AutoRABIT. "People are using it in the legal sector for contracts, M&As, all of those types of things. Fintech uses it pretty heavily to manage customers and where their balances and trades are at."
Salesforce's enormous power and flexibility have turned it into a ubiquitous corporate tool that's far outgrown its origins in customer relationship management (CRM). But in many companies, the Salesforce instance is still managed by sales and marketing, not the IT team. And that's a mistake.
"Traditional
AppSec [tools] do not monitor Salesforce," explains Prasanth Samudrala, VP of Products at AutoRABIT. "They don't understand the Salesforce lineage or hierarchy or the terms that they use, and so the traditional tools don't capture it."
Not just an application
Like an organization's regular tech stack, Salesforce can run its own applications, has a suite of low-code/no-code development tools, and may hold an enormous amount of sensitive and personal data. It's no longer an application to be administered — it's an
attack surface that needs to be governed.
"It's company-management software," says Samudrala. "Enterprises still treat Salesforce as an app or just a CRM, [but] in reality, it is a programmable platform which has its own permissions, which has its own data model, which has automation that works every day."
Many security managers and leaders may not be fully aware of the
risk exposure that a poorly configured or loosely managed Salesforce instance can create. As a result, Salesforce administration and development often isn't governed by the same security policies and best practices that apply to the rest of a company's software.
"Salesforce secures their boundaries. Nobody can breach into the Salesforce data boundary," says Samudrala. "But you, Mr. CISO, you, Mr. CIO, are responsible for your org's governance configuration code and data lifecycle because Salesforce offers a prepackaged solution, and then you add customizations, configurations on top of it to suit your business needs."
It's those customizations and configurations that cause Salesforce instances to
"drift" away from their baseline security postures and increase the clients' risk exposure.
Almost every Salesforce client customizes their own instance, but what clients often don't understand is that due to the shared-responsibility model, Salesforce security doesn't cover anything that changes the original package.
"Salesforce is really a platform at the end of the day, and they're responsible for securing that platform layer, but you have everything else above it," explains Lindsay Duran, Chief Marketing Officer at AutoRABIT. "As soon as you make a change to it, you own that change."
A tangled web
Because Salesforce administration, software coding and data management are often out of reach of an organization's regular IT, security and development teams, standard practices may not be enforced.
Data may be unlabeled, uncategorized and ungoverned, with no metatags to distinguish sensitive information from regular data.
Excessive permissions may be applied to new users because it's easier to clone existing identities than create new ones.
"I think you would be shocked at the amount of PII and PHI data that is stored in Salesforce," says Duran. "Salesforce is in fact one of the largest repositories of confidential information of any solution."
Third-party Salesforce applications may be installed with overly privileged OAuth tokens — a situation that was exploited in the summer of 2025 by the Shiny Hunters and Scattered Spider threat-actor groups to
steal proprietary data from dozens of companies.
Most significantly, the ease of developing Salesforce applications and extensions means that almost anyone can create software, especially now that Salesforce offers voice-controlled
AI-assisted coding. That's great if you're trying to add functionality quickly, but it's often done without
security awareness or secure-development processes.
"It's super quick to build stuff on Salesforce and to bring it to production," says Samudrala. "You're skipping your traditional checks and balances you have during the software development lifecycle."
As a result, many Salesforce developers will need to take a crash course in
DevSecOps and build up relationships with standard software developers and security teams.
"There are the Salesforce devs and admins that know Salesforce really well, and then you have the traditional security folks that know security really well and understand application security," says Hazard. "We're trying to bridge that gap between the two."
How to lock down your Salesforce
Salesforce instances need the same security precautions that the rest of an organization's IT estate has: a governance structure, strictly enforced policies, minimized user permissions and, ideally, a
zero-trust model. Here are steps you can take to get there.
Understand the shared responsibility model.
Review your documentation to fully grasp where the line is between what Salesforce is responsible for securing and what your company must take responsibility for.
"The moment that you start adding configuration, you are creating a drift from the prepackaged application," says Samudrala. "You are manufacturing misconfigurations and just putting yourself at risk."
Baseline everything so that you can spot drift early.
Create models of your Salesforce instance without any added customizations or configurations and compare them to your actual instance. Investigate the differences to see if any vulnerabilities have been created.
Use secure templates for tools & profiles.
Many Salesforce admins will just clone existing profiles rather than create new ones from scratch. Instead, create bare-bones profile templates with the minimum number of permissions, then clone those and add permissions as needed.
Classify and add metadata tags to data.
Use automated tools like AutoRABIT's Guard to scan, classify, categorize and tag all data contained in your Salesforce instance. Add extra protections to sensitive information.
Implement CI/CD tools and code-scanning processes.
Especially those designed for Salesforce like AutoRABIT's CodeScan and ARM.
"We scan all of the five proprietary Salesforce languages, as well as APIs," says Duran. "We have [rules] that are specific to Salesforce and that account for the unique metadata structures within Salesforce."
Review permissions of users and of third-party apps and tools.
Ask the obvious questions: What can a given user or tool access? Is the user or tool over-permissioned? Can access be easily revoked? AutoRABIT's Guard can review these automatically.
"We're trying to make it so that you can have the visibility of what is over-permissioned," says Hazard. "I tell people Bloodhound is to [Active Directory] as Guard is to Salesforce."
Implement lifecycle controls for access tokens.
Like passwords, you don't want access tokens to be valid forever. Implement lifespans and make sure the tokens can't access too much.
Enforce company security policies.
This seems obvious, but Salesforce apps and user profiles often escape security restrictions that apply to regular users and applications.
Implement least privilege and zero trust if possible.
If your company already adheres to these principles, then extend them to the Salesforce environment.
Use tools like AutoRABIT that will govern Salesforce data and processes automatically.
Many of the above recommendations can be deployed automatically using tools designed for that purpose.
"We're trying to call out to the CIOs and CSOs of the world that [Salesforce] is an attack surface," says Samudrala. "You need to have security around this attack surface, so you need to understand what's your baseline configuration when somebody is making, the last mile user is making changes."
