> ## Content Index > Fetch the complete content index at: https://notes.hiddenbay.tech/llms.txt > Use this file to discover other available public pages before exploring further. # How Your Sandbox Sites Can Be a Lab for Hackers - URL: https://notes.hiddenbay.tech/how-your-sandbox-sites-can-be-a-lab-for-hackers/ - Published: 2026-10-21T13:20:44.000Z - Updated: 2026-10-21T14:51:58.000Z - Author: Daniel Harfleet - Tags: Experience Cloud Security Most people within the Salesforce ecosystem know that Experience Cloud sites can be created in sandboxes. It is however often overlooked that a public-facing site on a sandbox is reachable from anywhere on the Internet. So what can an attacker do with a sandbox site? 1. They can use it to understand implementation details. 2. They can dry-run attacks. 3. They can access real data if it is not adequately protected; it's important to note privacy laws still apply. Of course this will all depend on the rigour of the organisation's governance and the discipline of the team. Let's look at this in more detail. ## Reconnaissance & Enumeration ### Discovering Sandboxes #### Search Engines A well-crafted search query can find sandbox sites. Using 'Google Dorks' (query filters) can optimise this. Here is an example for those who like to see real-world proof: Google search query: `site:sandbox.my.site.com` I would strongly recommend against interacting with any of the sites in the returned results. Clearly, they are not intended for public consumption. Although the site admin may not have switched on the Experience Cloud SEO capabilities explicitly, the site still hosts a robots.txt file, which after closer inspection, does not dissuade crawling. Salesforce's own documentation ([Salesforce Experience Site is Returned in Search Engine Results](https://help.salesforce.com/s/articleView?id=005131269&language=en%5FUS&type=1&ref=notes.hiddenbay.tech)) states that a sandbox site may appear in Google searches. Also see [how to create a custom robots.txt file](https://help.salesforce.com/s/articleView?id=experience.networks%5Fseo%5Fconfigure.htm&type=5&ref=notes.hiddenbay.tech) if you want to configure your own. But it's important to realise this is a marker, not a security control. #### Inadvertent distribution In a small tight project team, there should be no issue sharing sandbox URLs. However, we all know in reality, these URLs and the URLs of the Experience Cloud sites get passed around, often the bigger the project, the more chance of this happening. Examples: 1. Pre-launch teaser demos 2. Training material 3. Sales team demos 4. Marketing videos Occasionally if a public git repo is being used (typically this will not be a commercial project), sandbox URLs end up in pull request comments, etc. #### Sandbox hopping Sandbox naming is quite predictable, especially if you are following common SDLC naming such as dev, dev2, sit, uat, qa, training, staging, preprod or Salesforce sandbox type naming such as full, partial, fcopy, pcopy, etc. I've not found a technical way to get these subdomains (maybe it can be done using network tools), but guessing is not impossible. ### Exploitation #### Implementation Details During development phases of a site when custom code is being used, it is common for developers to add in useful debugging information to results from controllers and so on. I know, I have done this. Whereas a stack trace (a kind of textual sequence diagram) is useful to a developer, it is also useful for attackers to understand the software architecture (layers), potential frameworks being used and consistency around error handling and logging, including security-related error paths. Often a developer will focus on the 'happy path', the user journey that is supposed to happen (the one the UX team are all over 😏), but while they are making this happy path work, they are quite often deferring the less glamorous features, scalability, reliability and security. This can allow an attacker to get a quick path to sensitive data (copied over from production, or just useful indicative data). It's not uncommon for some of the security aspects to never get done; a project that rewards quick 'happy path' usability will not always make time for secure robustness. Potentially this weakness could end up in production \[see footnote\]. Any of the robustness deviations mentioned above could just exist in the sandbox, not in production, but it's a subtle signal to an attacker that production may have weaknesses too. #### Dry Runs I have no statistics to back this up, but I am going to make the assertion that a large proportion of sandboxes are carrying out next to no *pro-active* security processes, log inspection, behaviour analysis, formal administration, etc. So a sandbox could be a safe (ish) place for an attacker to try attacks before they execute them in production. They can probe the site, they can try parameter ranges on custom controller methods, etc. As an aside, although as ever the focus tends to be on guest users, it's worth remembering that self-registration offers an attack vector on a sandbox site too, for the same reasons it does in production, as outlined in [How Self-Registration Can Become a Fast Track for Attackers](https://notes.hiddenbay.tech/how-self-registration-can-become-a-fast-track-for-attackers/). #### Data Full and Partial sandboxes can carry real data if it has not been masked. Dev & Dev Pro are less likely to have real data in them, but this is not a given and depends on your data hygiene and any scripts which load test data. Regardless of how the data got there, if it is real data, from a compliance perspective, it is still governed by the various privacy laws, e.g. GDPR, HIPAA and SOX. ## What can be done? 1. Follow Salesforce published guidance on Sandbox Org Security \[1\]\[2\]. 2. Check out [Securing Sandbox Environments: How to Prevent Production Data Exposure in Salesforce](https://www.flosum.com/blog/salesforce-sandbox-security-prevent-production-data-exposure?ref=notes.hiddenbay.tech) 3. Restrict access to the site (see below). 4. Consider governance/SDLC/SecOps in sandbox environments (see below). ### Restrict access to the site The first restriction to have in place is the same restrictions that would be in place for your production implementation, in other words, secure configuration of security settings such as permissions/sharing and secure code. If you do not have this, then think hard about what can be accessed by who. It is possible for network restrictions to be applied to sandbox sites if custom domains are being used in combination with 3rd party (i.e. not Salesforce provisioned) CDNs. However, this is quite complex and of course requires a capable network operations team. The easiest route for most teams is Login IP Ranges on the profile: Setup > Profiles > \[any external user profile in use\] > Login IP Ranges > Add IP Ranges. Note accessing the guest user profile is a different config path, see \[3\]. Anything outside the ranges listed gets refused. For individual IP addresses, add a range for each IP address, where the start and end values are the same. It's an admin headache, but it's a secure-by-default approach. See References: \[3\]\[4\] ### Consider governance/SDLC/SecOps in sandbox environments. Sandbox environments rarely get the same SDLC and SecOps discipline as production. This is sometimes because an organisation is not aware of the risk and sometimes because ownership falls between the cracks. Oftentimes the process for managing the sandbox falls to the person or people who are operating in the sandbox, and they are more than likely to be focussed on other priorities. Regarding leakage of sandbox URLs through content and demos, I recommend instilling caution in your wider business teams. With the rise of agentic offensive security, a sandbox could just be one more target on a long list handed to an AI agent. So having this governance in place from day zero is better than leaving it to chance. I would recommend explicitly including sandbox security in your deployment and refresh governance \[5\]. ## Summary ### Key Points: - Real data on a sandbox is still governed by privacy laws. - Experience Cloud sites on sandboxes can be reached by anyone who knows the URL. - Sandbox URLs can be discovered by a number of means. - Attackers can use sandboxes to find attack vectors. - Attackers can dry-run attacks with less risk of detection. - Attackers can steal real data from a sandbox if it exists and it is not adequately protected. ### Key Recommendations: - Build sandbox security explicitly into your deployment and refresh governance. - Follow referenced best practices for protecting sandbox data. - Restrict access to the site with Login IP Ranges (or a network-level control where one's in place). - Make referenced changes to the site configuration to reduce search engine discovery. Ensure any configuration is carried over or reapplied on each refresh. **\[footnote\]** I've seen a situation for a client I worked with whose team had to demo the latest sprint, they had a bug in their security configuration, so for the benefit of the demo, they added in a guest user sharing rule that shared all data to guests for a given object. This meant they could go ahead with the demo. What happened next? The admin promoted the project into the deployment pipeline, the tests were not sufficient to highlight oversharing and the security gap made it into production. Having led implementation teams back in my enterprise Java days and in the Salesforce ecosystem, I know that individual contributors would go to the utmost to implement the best DevOps process and the perfect solution. The reality is, external business constraints, lack of awareness and lack of communication often lead to this. That's a collective responsibility at all levels. I've never seen anyone get a pat on the back for delaying a release for security hardening (but they should do). **References** \[1\] Data Masking and Non-Production Environments - [Salesforce Well-Architected](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html?ref=notes.hiddenbay.tech#data-masking-and-non-production-environments) \[2\] Salesforce Data Mask - [Trailhead](https://trailhead.salesforce.com/content/learn/modules/salesforce-data-mask?ref=notes.hiddenbay.tech) \[3\] Accessing the Guest User Profile - [Salesforce Help](https://help.salesforce.com/s/articleView?id=platform.rss%5Fconfig%5Fguest%5Fuser%5Fprofile.htm&type=5&ref=notes.hiddenbay.tech) \[4\] Restrict IP Ranges - [Salesforce Help](https://help.salesforce.com/s/articleView?id=xcloud.login%5Fip%5Franges.htm&type=5&ref=notes.hiddenbay.tech) \[5\] Governance - [Sandrine Ged](https://lnkd.in/p/eC-G2AvD?ref=notes.hiddenbay.tech)