21 posts tagged with "Salesforce"

Apex looks enough like Java that it is easy to read it as Java. Security tooling does the same, and the places where Apex is not Java are where findings go missing. A scanner that matches Database.query( will not see DataBase.Query(. A reviewer who sees an access check at the top of a method tends to assume everything below it is covered.

This post walks through three such details. Each one hid real findings in our own engine until vulkro-sf 0.27.0, and each one is just as easy to miss in a manual review. For every case there is vulnerable code, the reason it is vulnerable, and a fixed version.

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.

Salesforce DevSecOps has a problem that application teams do not: half of what decides your security never passes through the pipeline. Apex, Lightning components and Flows live in a repository and can be scanned like any other code. But a profile edited in Setup, a connected app approved for a vendor, or a guest user given one more object never becomes a commit. A pipeline that only scans pull requests sees the code and misses the org.

So a working Salesforce security pipeline has two halves. One runs on every change, from the developer's laptop to the merge. The other runs on a schedule against the live org, because the org changes whether or not anyone deploys.

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.

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 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?

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 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 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.

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 is a hosted, read-only, scan-based security platform for your Salesforce orgs. It scans every org you run on a schedule and shows what changed between scans. You can start it yourself today, with a 14-day trial.

Salesforce data theft did not stop when 2025 ended. In the first half of 2026 there was a mass scan of public Experience Cloud sites in March, a run of extortion claims through the spring, and in June another third-party integration whose OAuth tokens were used against customer orgs.

The pattern from last year held. In each case where Salesforce made a statement, it said its platform had not been breached. What attackers used was configuration that customers own: what an anonymous site visitor may read, what an employee account can reach, and what an integration's token is allowed to do.

This post sticks to what has been confirmed by Salesforce, by the affected companies or by a regulator, and says so when a claim comes only from the attackers. Then it lists what to check in your own org.