Exposing Broken Access Control in Salesforce: How Public Aura Endpoints Leaked Sensitive Data
How I Discovered a Broken Access Control Vulnerability that Leaked Sensitive Data

Hello Folks
While exploring Salesforce deployments during a focused research session, I uncovered a significant misconfiguration that allowed unauthenticated access to internal Salesforce data through publicly exposed Aura endpoints.
In this post, I’ll walk you through how I discovered the issue, what made it possible, and how teams can prevent these kinds of exposures. If you're a bug bounty hunter, security engineer, or developer working with Salesforce, this post is for you.
Understanding the Aura Framework
Salesforce Lightning apps are built using a client-side framework called Aura. It enables dynamic interfaces using backend data, fetched via structured requests sent to specific endpoints like:
/aura/sfsites/aura/s/sfsites/aura
These endpoints process requests that return Salesforce object data—like User records or Documents—for use in the frontend. Normally, these should only be accessible by authenticated users with the correct permissions.
But what happens when a Salesforce site is misconfigured?
The Vulnerability: Broken Access Control
While testing the public-facing instance at example.com (domain name changed for responsible disclosure), I found that all three Aura endpoints mentioned above were:
Accessible to guest (unauthenticated) users
Capable of processing backend data requests
Returning sensitive internal object data via POST requests
This was a textbook case of Broken Access Control: the Salesforce site was unintentionally exposing backend data to the public due to over-permissive guest user settings.
What I Could Access
Through this vulnerability, I was able to:
Query Salesforce objects such as
User,ContentDocument, and custom objectsRetrieve metadata and sensitive details like:
Internal Salesforce user IDs
Email addresses
Document titles
Creation and modification timestamps
In short, data that should be strictly private was being returned without any login requirement.
Technical Breakdown and Exploitation
I created a Python script (poc.py) that automates the entire attack chain. Here’s a step-by-step breakdown of how the script works:
Endpoint Discovery The script scans the base domain for known Aura endpoint paths. If it detects a valid Aura response (
aura:invalidSession,aura.context, etc.), it flags the endpoint as vulnerable.Aura Context Generation A GET request to the base path retrieves values like
fwuidandapp, which are necessary for crafting valid Aura POST requests.Payload Construction Using known controller/action pairs (e.g.
SelectableListDataProviderController), the script sends POST requests to target specific Salesforce objects likeUser.Data Extraction The response is returned in JSON format, revealing internal data about the object queried.
Sample PoC Output: User Object Access
This confirmed the vulnerability—internal user data was publicly accessible without authentication.
Accessing ContentDocument Metadata
By targeting the ContentDocument object instead, I retrieved metadata for internal documents stored in Salesforce:
Documents, email logs, internal assets—all revealed with zero authentication.
Root Cause: Over-Permissioned Guest User Profile
Salesforce allows communities and public sites to assign a special profile to guest users. If this profile is granted access to backend objects like User or ContentDocument, it becomes a major risk.
The Aura framework honored these permissions and served the data without requiring login. This is not a bug in Aura itself, but rather a misconfiguration in the Salesforce user permissions model.
Real-World Impact
This kind of exposure could lead to:
Sensitive Data Disclosure: Emails, internal user metadata, document titles
Reconnaissance & Enumeration: Mapping out Salesforce internal structures
Compliance Violations: Exposure of PII may breach GDPR, CCPA, and similar data protection laws
Files Included
The proof-of-concept script (poc.py) automates:
Endpoint discovery
Object querying
Data extraction and result formatting
It’s designed for responsible research and learning. Use it only on systems you are authorized to test.
Salesforce pwn Tools: https://github.com/iamunixtz/salesforce-pwn
Final Thoughts
What started as a simple endpoint scan led to a serious finding. It’s a reminder that platform security depends not only on the provider (like Salesforce) but also on how the tools are configured by end-users.
Even if you’re using secure frameworks, a single misconfigured user profile can create a data breach waiting to happen.
This finding is one of the many that keeps me motivated in the world of bug bounty hunting—and I hope it helps others sharpen their testing methods as well.
Thanks for reading. If you’ve had similar experiences with Salesforce or other third-party platforms, I’d love to hear your story.
Happy Hunting.
Last updated