11 posts tagged with "Attack paths"

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.

A multi-tenant SaaS application keeps every customer's data in the same database and promises each of them they will only ever see their own. That promise is usually kept by one line repeated in hundreds of places: WHERE tenant_id = ?. Every query that remembers it is correct. The one that forgets shows a customer another company's records.

Cross-tenant leaks are the business-to-business version of the IDOR bugs we wrote about earlier. The difference is the blast radius. An IDOR exposes one user's record to another user. A cross-tenant leak exposes one customer's company to another customer's staff, and tends to end with an incident notice sent to every affected account.

Here are two SQL injections in the same Express application. One is on a public search endpoint that anyone on the internet can call. The other is on a reporting screen that only administrators can open, behind single sign-on. The vulnerable line is almost identical in both.

Many scanners rate them the same, because severity is attached to the rule: "SQL injection" is Critical wherever it appears. The result is a list where everything at the top looks equally urgent, and the team has to redo the risk assessment by hand for every row.

They are not the same risk. Both should be fixed, but one can be exploited by anyone right now and the other needs an attacker who already holds an administrator account. Severity that cannot tell them apart is not telling you much.

IDOR prevention comes down to one question asked on every request: is this record yours? An insecure direct object reference (IDOR) is what happens when the server asks only whether you are logged in. You request invoice 8812, the server checks your session, loads invoice 8812 and returns it. Whose invoice it was never came up.

OWASP ranks this first in the API Security Top 10 (2023) as broken object level authorization (BOLA), and its prevention advice is blunt: check that the logged-in user may act on the record every time client input picks the record. We covered the breaches in broken access control is still number one. This post is about the code: how to make that check structural in Express and NestJS with Prisma, and how to test that it stays there.

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 Salesforce org rarely stands alone. Around it there is usually a small fleet of services nobody thinks of as "the Salesforce project": a Node service that receives webhooks and writes them into the org, a Python job that copies records into a warehouse, a Go API behind the customer portal, a Java service that holds the integration credentials. They are written by different teams, deployed by different pipelines and reviewed, if at all, by different tools.

An attacker does not see that boundary. If the first hop of the path is a route in the Node service and the last hop is a field in the org, a review that looks at only one side sees half a path and calls it two unrelated medium findings.

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.

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.

Experience Cloud guest user security comes down to one fact: whatever the guest user can read, anyone on the internet can read. Every public site runs unauthenticated visitors as a single guest user, and that user's profile, sharing rules, Apex classes and Flows decide what an anonymous request can reach. No password stands in the way.

In March 2026 Salesforce warned customers about a threat actor mass-scanning public Experience Cloud sites through the /s/sfsites/aura endpoint, using a modified version of the Aura Inspector auditing tool that extracted data instead of only reporting it. Salesforce said the issue "is not due to any vulnerability inherent to our platform": the exposure came from guest access that customers had configured too widely.

This is a concrete checklist for closing that gap, built on Salesforce's own recommended actions, followed by how Vulkro for Salesforce shows what a guest can actually reach.