AuraInspector: How Mandiant’s New Open-Source Tool Audits Salesforce Aura for Data Exposure (and Why Defenders Should Care)

AI generated image for AuraInspector: How Mandiant’s New Open-Source Tool Audits Salesforce Aura for Data Exposure (and Why Defenders Should Care)

Salesforce is the enterprise software equivalent of a busy airport: everyone is in a hurry, there are lots of doors, and if a single “Staff Only” sign falls off, it’s amazing how quickly strangers wander into the wrong hallway.

On January 12, 2026, Mandiant published a Google Cloud Threat Intelligence post introducing AuraInspector, a new open-source command-line tool designed to help defenders audit Salesforce Experience Cloud applications for access control misconfigurations and resulting data exposure. The original post—AuraInspector: Auditing Salesforce Aura for Data Exposure—was written by Amine Ismail and Anirudha Kanodia. citeturn2view0

This article is my deep-dive expansion of their announcement and the security ideas behind it: how the Salesforce Aura endpoint actually becomes a “data exposure multiplier,” why Mandiant is highlighting an undocumented GraphQL technique, what AuraInspector does (and importantly, what it doesn’t do), and how administrators and security teams can build a practical audit program around it.

And yes: there will be mild jokes. If we can’t laugh while reviewing permissions matrices at 2 a.m., the attackers win twice.

Why this matters: Salesforce misconfigurations are still the quietest “breach” headline

Security teams often obsess over exotic zero-days, but many real-world incidents start with something less glamorous: a legitimate platform feature + a configuration mistake + an attacker who can read documentation.

Mandiant’s post is blunt about what they keep finding during Offensive Security Services engagements: Experience Cloud deployments where unauthorized users can access sensitive data such as credit card numbers, identity documents, and health information. citeturn2view0

That’s not a “Salesforce is insecure” claim; it’s a “complex systems produce complexity debt” claim. Salesforce can be configured very securely—but Experience Cloud sites, guest access, sharing rules, object permissions, and custom Aura-enabled Apex methods create a large surface area where a single mistake can turn a marketing portal into a data sprinkler.

Experience Cloud is a special kind of risky: it faces outward by design

Experience Cloud (formerly Communities) is commonly used for customer portals, partner portals, self-service knowledge bases, and semi-public experiences that intentionally reach outside the employee perimeter. In other words: it is often the place where unauthenticated users and low-privilege users interact with the system.

If your internal CRM is a vault, Experience Cloud is the lobby. Nobody is surprised that the lobby has more doors. The surprise is when one of those doors leads to the vault.

Quick refresher: what is Salesforce Aura, and why does “/aura” show up everywhere?

Aura is Salesforce’s component framework behind much of Lightning Experience. It enables single-page application behavior and modular UI components. citeturn2view0

From a security perspective, the key point isn’t “Aura is old/new/pretty/ugly.” The key point is that Aura relies on a backend endpoint—commonly identifiable as an /aura POST endpoint—that the frontend uses to retrieve data and invoke server-side functionality. citeturn2view0

Mandiant notes that the Aura endpoint is commonly targeted in Experience Cloud applications. citeturn2view0 The reason is simple: if you can talk to the same backend API that the UI talks to, you can often skip the UI and ask direct questions. If the underlying access controls are weak, the API happily answers.

Aura’s “message” parameter: legitimate plumbing with sharp edges

Mandiant highlights the ability to invoke Aura-enabled methods through the Aura endpoint, using the message parameter—depending on what the authenticated (or guest) context is allowed to do. citeturn2view0

One example they call out is getConfigData, which returns a list of objects used in the backend database. citeturn2view0 In a red-team context, that’s valuable enumeration. In a defender context, it’s a helpful “what’s even in this org?” visibility trick that doesn’t require internal admin console access.

The real root cause: access control misconfiguration (not an Aura “bug”)

Mandiant’s post repeatedly emphasizes that the exposures they’re demonstrating stem from misconfigurations, specifically around objects and fields. citeturn3view3

This is a crucial framing. If you read the blog as “Aura is vulnerable,” you’ll fix the wrong thing. The Aura endpoint is more like a microscope: it makes your existing permission decisions easier to observe—and, unfortunately, easier to exploit.

Salesforce’s own Lightning security architecture (Lightning Web Security or Lightning Locker) exists to isolate components and reduce cross-namespace shenanigans, but it doesn’t automatically correct your data permissions. Salesforce documentation describes these client-side security layers and their goals, including sandboxing behaviors and CSP. citeturn0search5turn0search9

How data gets exposed through Aura in practice

Mandiant walks through several practical techniques that matter because they mirror how attackers behave: they enumerate, they test access quickly, and they turn “I can see one record” into “I can see the whole table.”

1) Record retrieval via standard Aura controllers

Some Experience Cloud components will implicitly call Aura methods to retrieve records and populate UI elements. Mandiant uses the example of an Aura method called getItems used by a selectable list data provider controller. The method itself is legitimate; the risk appears when permissions are misconfigured. citeturn2view0

In a controlled test, Mandiant intentionally misconfigured access controls to give a guest user access to all records of the Account object, then demonstrated retrieval via Aura. citeturn2view0

At this stage, the takeaway isn’t the exact controller name; it’s the pattern: if a guest profile has object/field access it shouldn’t have, an attacker can often retrieve the data through the same plumbing the UI uses.

2) The 2,000-record limit is not a safety net (especially with sorting)

Salesforce limits retrieval to at most 2,000 records at a time through that typical Aura approach, which might sound like a partial mitigation. Mandiant points out the practical problem: some objects have far more records, and defenders may need to demonstrate full impact. citeturn2view0

They describe testing that revealed a sortBy parameter, where changing sort order can allow retrieval of additional records that were initially inaccessible due to the limit. They also note that adding a “-” prefix can invert sort order. citeturn2view0

Translation: limits that were intended for UI performance can become “pagination hacks” in adversarial hands.

3) “Boxcar’ing”: bulk actions make auditing faster (and attackers faster too)

The Aura framework supports bundling multiple actions into a single request (boxcar’ing) to reduce network traffic. Salesforce allows up to 250 actions in one request, although Mandiant recommends limiting to around 100 to avoid Content-Length issues. citeturn2view0

Operationally, boxcar’ing is a performance optimization. From a security testing perspective, it’s a scale multiplier: you can check many objects quickly, which is ideal for defenders—but also for attackers who are enumerating what your guest user can see.

4) Record Lists and “direct URLs” you didn’t know existed

Mandiant also highlights Salesforce Record Lists. By using a controller action to fetch initial list views, it’s possible to determine whether an object is associated with a record list component. If a record list is present and permissions allow it, navigating to a direct path such as /s/recordlist/<object>/Default can expose the UI list of records. citeturn2view0

This is one of those “security through obscurity meets URL predictability” moments. You can remove menu links, hide buttons, and make the UI look clean—but if the backend authorizes the request, the UI cosmetics are irrelevant.

5) Home URLs: when a portal reveals admin surfaces (sometimes for third-party apps)

The blog describes a method to retrieve “Home URLs” that can be browsed directly, and notes that on multiple occasions, following these URLs led researchers to administration/config panels for third-party modules installed on the Salesforce instance. citeturn2view0

They even cite a previous engagement where an administration dashboard for a Spark instance was accessible to unauthenticated users via this technique. citeturn3view0

From a defender standpoint, this is a big deal: third-party packages and integrations often add pages and endpoints you didn’t personally build. “We secured our custom portal pages” is not the same as “we secured every page created by marketplace apps and setup tooling.”

6) Self-registration: removing the link isn’t the same as disabling the feature

Mandiant notes that Salesforce has increased default security on Guest accounts over the last few years, which makes authenticated access more valuable to attackers. citeturn3view0

They describe cases where the self-registration link was removed from the login page, but self-registration was still enabled; Salesforce confirmed the issue has been resolved. citeturn3view0

The blog provides Aura methods that can reveal whether self-registration is enabled and what the self-registration URL is—without brute forcing. citeturn3view0

Defender interpretation: treat self-registration like an identity boundary feature. If you don’t need it, disable it. If you do need it, treat it as code: review, test, monitor.

The headline-grabber: an undocumented GraphQL technique that helps bypass the 2,000-record limit

The most interesting section (and the one that will get copy-pasted into a lot of internal security slides) is Mandiant’s discussion of using GraphQL via an Aura controller to go beyond the 2,000-record limit. citeturn3view2

Mandiant explains that, despite lack of documentation on the specific controller technique, they constructed a valid request based on Salesforce GraphQL API documentation and found the GraphQL Aura controller available to unauthenticated users by default. citeturn3view2

They list several advantages of using GraphQL in this context, including standardized retrieval, better pagination, introspection (field discovery), and mutation support (useful for testing write privileges). citeturn3view2

Crucially, Mandiant reports that Salesforce confirmed this is not a vulnerability because GraphQL respects underlying object permissions and does not provide extra access—as long as permissions are properly configured. citeturn3view2

But here’s the uncomfortable reality: in misconfigured environments, GraphQL pagination means you can exfiltrate “any amount of records” from the objects that are misconfigured. citeturn3view2

Why defenders should pay attention even if it’s “not a vuln”

Security programs are often vulnerability-centric: find CVEs, patch CVEs, report CVEs. Misconfiguration risk doesn’t fit nicely into that workflow because there’s no patch and no vendor fix. Instead, your org has to decide what “correct” access looks like—and keep it correct as the business changes.

The GraphQL technique matters because it changes the impact calculus of a mistake. If you thought “at worst a guest can see 2,000 records,” that assumption may be wrong in practice. With GraphQL pagination, a single overbroad permission can become a full dataset leak.

UI API supported objects: broad, but not everything

Mandiant also notes a limitation: the GraphQL controller can only retrieve records for objects supported by Salesforce’s User Interface API (UIAPI). citeturn3view2

In many Experience Cloud scenarios, that’s plenty. You don’t need access to every object in the org to cause serious harm; access to “Accounts, Contacts, Cases, Orders, Tickets, Attachments, Identity documents” is more than enough to ruin a week (or a quarter).

So what is AuraInspector, exactly?

AuraInspector is an open-source command-line tool released by Mandiant to help administrators and defenders identify and audit access control misconfigurations and potential data exposure from an external perspective within the Salesforce Aura framework. citeturn2view0

The code is published as google/aura-inspector on GitHub, under an Apache-2.0 license, and the repository explicitly states it is not an officially supported Google product. citeturn4view0

The README calls it a “Swiss Army knife of Salesforce Experience Cloud testing,” and lists capabilities such as discovering accessible records for guest and authenticated contexts, getting total record counts using an undocumented GraphQL Aura method, checking self-registration, discovering record list components, and enumerating “Home URLs.” citeturn4view0

Important safety note: the public tool is read-only by design

Mandiant notes they have an internal version capable of extracting records, but the public release does not implement data extraction to avoid misuse. citeturn3view3

This is a meaningful design decision. It positions AuraInspector as a defensive audit tool rather than a turnkey exfiltration utility.

How you should (and shouldn’t) use AuraInspector

Because AuraInspector can be pointed at externally reachable Experience Cloud sites, organizations need to treat its use like any other security testing activity: authorized scope, clear logging, and careful handling of output data.

Who should run it?

  • Salesforce administrators who own Experience Cloud deployments and need an external validation view (what can the internet see?).
  • Security engineers building continuous configuration monitoring programs.
  • Internal red teams performing controlled adversary simulation—ideally after blue team alignment.
  • Third-party penetration testers with explicit written permission and a defined test window.

Who should not run it?

  • Anyone testing orgs they don’t own or don’t have written authorization to test.
  • Anyone planning to “just see what happens” on public community portals. That’s not curiosity; that’s unauthorized access.

Operational best practices for defenders

Some practical guidance if you’re adding AuraInspector to your playbook:

  • Run from a controlled environment with a known egress IP and documented purpose.
  • Store outputs securely. Even “metadata” like object names and counts can be sensitive.
  • Test both contexts: guest (unauthenticated) and a least-privilege portal user account.
  • Coordinate with Salesforce admins so they can correlate logs/events and validate remediation.
  • Don’t treat “no findings” as proof of security. Treat it as one signal among many.

Remediation checklist: what Mandiant recommends (and how to turn it into an action plan)

Mandiant’s remediation section is concise and focused on configuration hygiene. They recommend: auditing guest user permissions, securing private data for authenticated users via sharing rules and org-wide defaults, disabling self-registration if not needed, and following Salesforce best practices such as Security Health Check. citeturn3view3

That’s the “what.” Here’s the “how to operationalize it” version for real teams.

1) Guest user permissions: treat them like an internet-facing API key

Guest profiles should have the minimum object and field permissions necessary for public functionality. The biggest mental shift is to stop thinking of “guest user” as a kind of anonymous website visitor and start thinking of it as a shared machine identity used by all unauthenticated visitors.

If that shared identity can read sensitive objects, then the internet can read sensitive objects.

2) Sharing rules and org-wide defaults: simplify wherever possible

Mandiant points out that sharing rules can be configured at multiple levels, making it difficult to identify misconfigurations. citeturn2view0

A practical strategy is to reduce complexity debt:

  • Prefer restrictive organization-wide defaults and explicitly grant access where needed.
  • Document why each sharing rule exists (owner, business reason, last reviewed date).
  • Establish a review cadence (quarterly at minimum; monthly for high-risk portals).

3) Self-registration: decide if you want growth or risk—and implement accordingly

Self-registration is a valid business feature (customer onboarding, partner onboarding), and Salesforce provides extensive admin tooling around it. For example, Trailhead includes a full trail on streamlining self-registration for Experience Cloud. citeturn7view0

But from an attacker’s perspective, self-registration can be a privilege escalator: it turns “guest” into “authenticated” without human approval. If authenticated users have broader object access (often true), that matters.

Concrete steps:

  • Disable self-registration unless you truly need it. citeturn3view3
  • If you need it, rate-limit and monitor registration attempts and suspicious patterns.
  • Review the post-registration permissions assigned to new users (profiles, permission sets).

4) Monitor for /aura POST activity and odd patterns

Mandiant includes a representative UDM query idea for identifying POST requests to the Aura endpoint in Google SecOps (Chronicle). citeturn3view4

Even if you’re not a Google SecOps customer, the detection concept generalizes:

  • Watch for spikes in POST traffic to /aura.
  • Watch for repeated requests with many bundled actions (boxcar’ing behavior).
  • Watch for unauthenticated access patterns that enumerate objects and list views.
  • Correlate with unusual registration events (if self-registration is enabled).

A broader industry context: why Salesforce security is getting more attention right now

Salesforce sits at a crossroads of identity, customer data, and workflow automation. That makes it both valuable and attractive. Over the last few years, the ecosystem has also shifted toward more integrations and token-based access, which increases the blast radius of credential compromise.

For example, in August 2025, Google Threat Intelligence Group published an advisory about a widespread data theft campaign targeting Salesforce customer instances through compromised OAuth tokens associated with a third-party application integration (Salesloft Drift). citeturn0search0

That incident is not “about Aura,” but it reinforces the bigger point: Salesforce environments are a high-value target, and attackers are happy to exploit whatever path is easiest—tokens, misconfigurations, exposed endpoints, or all of the above.

Misconfigurations are attractive because they are “legitimate” access

If an attacker steals data via an API call that the system authorizes, the event can look like normal usage. That’s why external auditing matters: you want to identify what’s exposed before it becomes an incident with a press release and a crisis budget.

What defenders should do next: a practical AuraInspector rollout plan

If you’re considering adopting AuraInspector, here’s a realistic plan that doesn’t require heroic effort:

Phase 1: Inventory and scope (1–2 weeks)

  • List all Experience Cloud sites and custom apps (including paths like /<custom-app>/s).
  • Identify business owners and data owners per portal.
  • Define “guest expected functionality” and “portal user expected functionality.”

Phase 2: Baseline audit (1–2 weeks)

  • Run AuraInspector against each portal as a guest user.
  • Run AuraInspector as a least-privilege authenticated portal user (if applicable).
  • Review findings with admins and classify them: expected vs. risky vs. unknown.

Phase 3: Remediate and re-test (ongoing)

  • Fix overbroad guest permissions first.
  • Fix object/field exposure for authenticated portal users.
  • Re-run AuraInspector to validate externally.
  • Document changes and add them to your change management process.

Phase 4: Continuous monitoring (quarterly or monthly)

  • Schedule repeat audits (especially after major releases or new packages).
  • Track metrics: number of accessible objects, record counts, self-registration status, home URL exposure.
  • Integrate findings into risk management and compliance reporting.

Final thoughts: AuraInspector is less about Aura and more about reality

AuraInspector is a useful reminder that modern SaaS security isn’t just “patch the servers.” It’s configuration, governance, and continuous verification.

Mandiant’s contribution here is twofold: they’re providing a concrete tool (aura-inspector) and also teaching defenders how attackers think about Salesforce Experience Cloud—enumerate, scale via boxcar’ing, find direct URLs, and use GraphQL pagination when available. citeturn4view0turn2view0turn3view2

If you run Experience Cloud, the safest assumption is not “nobody would find this.” The safest assumption is “someone already scripted this.” Now you can script it too—defensively, with authorization, and with the goal of fixing the underlying access controls.

Sources

— Bas Dorland, Technology Journalist & Founder of dorland.org