Salesforce Experience Cloud is incredibly powerful—but with that power comes complexity, especially when it comes to security.
When building an Experience Cloud site, what should security-conscious architects and admins be thinking about from day one? To explore this question, we consulted Tyler Ochsner, Director of the Experience Cloud practice at Slalom, for his expert insights.
Architecture vs Design
While newcomers might see architecture and design as interchangeable, in a security context, they serve very different purposes—and confusing the two can lead to critical blind spots.
Architecture is about the foundation: how systems are structured, how components communicate, and how data flows between them. It considers scalability, resilience, performance—and above all, security. Design, on the other hand, is about the user experience: the layout, look and feel, navigation, and interaction patterns.
“Design makes something feel intuitive and engaging,” says Ochsner. “Architecture makes sure it actually works—and that it’s secure.”
In Experience Cloud, it’s easy to focus on branding and layout early in the process. But if secure access models, data segmentation, and integration boundaries aren’t addressed first, the most beautifully designed site can quickly become a security liability.
“You can make something look great,” Ochsner adds, “but if it’s exposing internal records or allows guest users to bypass restrictions, that’s a huge problem.”
Security-first architecture means defining the data model, access layers, user roles, and system boundaries up front—before a single pixel is placed on the page. It’s not just good practice; it’s essential in a platform as configurable (and powerful) as Experience Cloud.
Breaking Down Your Requirements
Starting any Experience Cloud project means asking the right questions—early and often. This goes beyond defining functionality; it’s about identifying what needs to be protected, how users will interact with data, and where potential vulnerabilities might emerge.
“Start by figuring out what kind of information you’re exposing,” Ochsner explains. “Are you showing case data? Customer profiles? Order information? Each of those requires different levels of access control.”
It’s also essential to understand who your users are. Are they customers, partners, internal staff, or unauthenticated visitors? What should they be able to do and see—and just as importantly, what should be restricted?
“Many organizations jump into building before answering those questions,” says Ochsner. “But if you don’t have clear boundaries, it’s easy to overshare data or accidentally open up access to the wrong group.”
Third-party integrations add another layer of complexity. If the Experience Cloud site connects to external systems, those interactions need to be secure and scoped appropriately.
“Think about the APIs,” he advises. “If an integration fails, what should happen? If someone intercepts that traffic, what could they see? Security architecture needs to account not just for how systems talk to each other—but how they might break.”
Spending time on this discovery phase helps teams build a more secure, scalable solution—reducing the chances of rework, misconfigurations, or exposure down the road.
Conducting a Thorough Architectural Audit
One of the most overlooked—but critical—steps in any Experience Cloud implementation is the architectural audit. Before any components are configured or pages designed, teams should evaluate the broader Salesforce environment, existing data models, and current permission structures. This isn’t just about cleaning up—it’s about understanding your security baseline.
“It’s amazing how often teams build on top of legacy configurations without realizing what’s already exposed,” says Ochsner. “If you don’t know what’s in place—what sharing rules exist, what objects are public, what integrations are running—you’re building blind.”
A proper architectural audit should answer questions like:
- What data is currently exposed to internal and external users?
- Are Guest User profiles overly permissive?
- Do any custom objects or fields bypass standard security models?
- Are there outdated flows or components still active in the org?
- How are API endpoints managed and secured?
Ochsner emphasizes the need to approach this like a threat assessment. “You’re not just looking at what’s configured—you’re looking for weak spots. Things that may have been fine in a previous project might now be a liability, especially when external users are involved.”
This is also the time to audit system integrations. As noted earlier, external systems talking to Experience Cloud can create unintentional exposure if not properly scoped or secured.
“APIs can be a major attack surface,” Ochsner warns. “Teams need to think through not just the happy path—what happens when everything works—but the failure modes too. What happens if someone intercepts the call? What if the integration breaks?”
In short, a strong architectural audit sets the foundation for secure, scalable design. It ensures you’re not building on compromised ground and gives the implementation team clarity and confidence as they move forward.
Identifying and Understanding Threat Vectors in Experience Cloud
Once the architectural audit is complete and there’s a clear picture of who has access to what, how APIs are being used, and which parts of the org are active or dormant (such as Guest User access), it’s time to shift perspective—from internal design to external threats.
This is where threat modeling comes in: assessing how attackers could exploit different entry points in your Salesforce environment based on real-world incidents and known patterns.
“The Public API is one of the first places threat actors go looking,” says Ochsner. “It’s often either underused or completely open—and both scenarios can be dangerous.”
In many cases, teams rely on the Public API for convenience, unintentionally exposing far more CRM data than intended. Ochsner points to real-world examples where attackers used simple tools—like cURL scripts—to automate massive data extraction through improperly secured API endpoints.
But APIs aren’t the only threat vector.
Org-Wide Defaults, sharing rules, and object relationships also come into play—especially in master-detail scenarios. When a master object is shared, its detail records are included, which can lead to unintended exposure.
“Think about the data you don’t want shared across your entire partner ecosystem,” Ochsner explains. “You’ve built a thriving community, but you don’t want one partner seeing another’s customer list. That’s where these seemingly small sharing missteps can become major security liabilities.”
Another common area of risk comes from the very tools that make Salesforce so extensible: web-to-case, email-to-case, and Experience Cloud portals. These submission points are purpose-built for user interaction—but that also makes them attractive targets. All of them can accept file and URL inputs, which, if unfiltered, may introduce malware or phishing vectors into your system.
Removing file submission functionality altogether could diminish the value of Experience Cloud, but doing nothing isn’t an option either. As Ochsner puts it: “You’ve already secured your email and your endpoints. Now it’s time to apply that same mindset to Salesforce.”
Thankfully, solutions like WithSecure Cloud Protection for Salesforce (CPSF) can fill this gap—scanning files and links in real time to detect threats before they reach users. And with tools like CPSF deployable in minutes, there’s no reason to leave this part of your org unprotected.
Building Your Security 360: A Holistic View of Salesforce Risk
With a clearer understanding of Salesforce’s attack surface, the next step is to formalize that awareness into something actionable: a Security 360.
Just as Salesforce offers a Customer 360 to unify data for business teams, your organization needs a Security 360 to unify risk visibility for your cybersecurity stakeholders. This includes documentation of every external-facing component, integration, and access layer—along with the corresponding security controls and threat mitigations.
“Salesforce can be a bit of a black box to security teams,” says Ochsner. “It’s often managed by business units, and that creates a gap. If you’re not bringing your cybersecurity team into these conversations, you’re creating risk.”
A strong Security 360 helps bridge that gap. It ensures your security, DevOps, and Salesforce teams are aligned on what’s exposed, what’s protected, and what needs further scrutiny—whether you’re planning a new Experience site or modifying an existing workflow.
Most importantly, it creates a single source of truth your organization can reference when making architectural decisions, approving changes, or responding to incidents. In today’s complex threat environment, that kind of shared visibility isn’t optional—it’s essential.
Looking to get started with URL and file protection? Check out WithSecure Cloud Protection for Salesforce. Get started by filling out the Content Risk Assessment.