11 posts tagged with "Salesforce"

Open a public Experience Cloud page, a help centre or an application form, and watch the network tab. The page talks to Salesforce through one endpoint, /s/sfsites/aura, as the site's guest user. Nothing about that endpoint knows whether the request came from the site's own components or from a script. Whatever the guest user is allowed to read, anyone on the internet can read.

That is not a theory. In 2023 an independent researcher found hundreds of public Salesforce sites exposing records such as Social Security and bank account numbers to anonymous visitors. In March 2026 Salesforce warned customers that threat actors were mass-scanning public sites through that endpoint and extracting data, and said the cause was customer guest user configuration, not a platform flaw. This post walks the path a leak takes, hop by hop, and where each hop can be closed.

A failed AgentExchange (formerly AppExchange) Security Review rarely fails on something exotic. It fails on a query that skipped a field-level check, a class that forgot its sharing keyword, or a Visualforce page that printed a URL parameter as raw HTML. The fixes are usually small. The cost of finding them in the review instead of before it is not.

Three facts about that cost, stated carefully. Salesforce publishes no first-pass failure rate; about half is the figure partners cite most often for first submissions, and it is an industry estimate, not an official one. On a paid solution, Salesforce charges a $999 fee for the initial submission and for every later attempt, and a solution typically takes four to five weeks to get through review (Salesforce). Salesforce has since renamed it the AgentExchange Security Review. The weeks are spent in the queue; the way to save them is to find the issues while you develop.

A security scan of a mature Salesforce org rarely comes back short. Hundreds of findings is normal: permissions that are broader than they need to be, Apex that runs without sharing, a session setting nobody has looked at since the org was created. Every one of them is technically true. Almost none of them tells you what to do on Monday morning.

The question a security team actually has is narrower: which of these lets someone reach data they should not?

The most damaging bug in web software is also the least interesting to describe. A request asks for record 1041. The server checks that you are logged in, loads record 1041 and returns it. It never asks whether record 1041 is yours. Change the number and you get your neighbour's.

That is broken object-level authorization, also called an insecure direct object reference or IDOR. The OWASP Top 10:2025 keeps broken access control at number one, and says that "100% of the applications tested were found to have some form of broken access control." Among the weaknesses it maps there is CWE-639, authorization bypass through a user-controlled key: the changed number.

Most Salesforce security reviews start with people: who is an administrator, who has MFA, who logged in from where. The data thefts of 2025 and 2026 mostly did not go through people's logins. They went through OAuth tokens, held by connected apps, acting as users who were never asked again.

The FBI's September 2025 alert explains why that matters: "Authorizing a malicious connected app bypasses many traditional defenses such as MFA, password resets and login monitoring, and because OAuth tokens are issued by Salesforce itself, activity coming from the malicious app can look like it's from a trusted integration." This post is about that surface: what a connected app is allowed to do, which settings decide how far a stolen token reaches, and how to review them.

Between late 2024 and the summer of 2026, attackers took customer records out of a long list of Salesforce orgs. The coverage made it sound like one breach of one platform. It was not. Salesforce said, case after case, that no vulnerability in its platform was involved, and the FBI's alert on the two main groups describes social engineering and stolen tokens, not an exploit.

What the attackers used instead was trust the orgs had already granted: to an employee, to an integration, or to the anonymous visitor of a public site. Read as a findings list, each org involved probably looked unremarkable. Read as attack paths, the same three shapes repeat. The FBI's September 2025 alert describes both 2025 campaigns in those terms: voice phishing that got a malicious connected app authorised, and OAuth tokens stolen from a third-party integration.

A Salesforce org is not a codebase you scan once before a release. It changes every week: a permission set edited in Setup, a connected app approved for a new integration, a sharing rule widened to unblock a deadline. None of that goes through a pull request, and most of it never reaches a repository.

Vulkro Cloud for Salesforce is a hosted workspace for keeping every org you run under continuous review. It is available by invitation today.

A supervisor reviewing a bank, an insurer or a large utility will eventually ask four questions about the systems that hold its customer data. Who can export every customer record? Which third parties hold a token into it? What changed in it last quarter, and who approved the change? When was it last tested, and what did the test find?

For a growing share of European companies, the honest answer starts with "it is in Salesforce". That does not move the question to Salesforce. The provider runs the platform; the profiles, permission sets, connected apps, installed packages and Apex inside your org are yours. NIS2 and DORA both make that explicit, and both expect you to show your work.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

Most Salesforce security feedback reaches a developer at the worst possible moment. It arrives in a review comment two days after the pull request was opened, in a scan report nobody owns, or in a rejection letter from the AgentExchange (formerly AppExchange) Security Review weeks after the class was written. By then the developer is three tickets further on, the context is gone, and a one-line fix has become a small project.

The cheapest moment to fix a missing field-level check is the moment the query is on the screen. That is an argument for putting security analysis in the editor. It is also a list of things the editor version has to get right, or developers will turn it off within a week.

Most of the attacks that made the news in 2025 did not need anything clever. A package version that should not have been installed. An install script that read a token and sent it somewhere. An API that returned whichever record you asked for. A prompt template that read a field anyone on the internet could write. Each one ended in a headline, and each one started as a line of code or configuration that a check could have pointed at.

This post goes through twelve of them, from late 2024 to early 2026. For each: what happened, as the public source describes it, the weakness underneath, and the Vulkro check that flags that weakness. Every check id below is in the shipped catalogue, and the core of each mapping was run against a small reproduction of the weakness before it was written down.

The org your last security review described no longer exists. Since then an administrator granted a permission set "for the migration" and never took it back. A connected app was approved so a vendor could run a trial. A session timeout was relaxed because an integration kept dropping. The guest profile was edited the week a new Experience Cloud page launched. Each change was reasonable on the day. None of it is in your repository, and none of it was reviewed.

That is configuration drift, and in Salesforce it is the normal state of things. The platform is designed to be changed in Setup, by people who are not developers, without a deploy.