Don’t Let Sensitive Data Hide in Your URLs

Don't Let Sensitive Data Hide in Your URLs

Protect your org and users by keeping sensitive info out of sight.

Share article

When it comes to protecting sensitive data, most people think about encryption, access controls, and login security. But one of the simplest ways sensitive information can be unintentionally exposed, or leaked, is also one of the most overlooked: putting sensitive data in a URL.

In Salesforce, that could mean exposing user details, session info, or other private data any time someone clicks a link, loads a resource, or shares a page. The risk is easy to miss-but also easy to fix, once you understand how it works.

What counts as sensitive data in Salesforce?

Sensitive data is anything that could harm your users or your business if it were exposed. In Salesforce, common examples include:

• Usernames, passwords, or auth(entication) tokens - could allow someone to impersonate a user.
• Email addresses or personal contact info - could be misused for phishing or spam.
• Salesforce Org IDs or object IDs - could reveal how your system is structured.
• Custom data unique to your business - if it's not meant to be public, it shouldn't be in a URL.

If you're unsure, ask yourself: Would I be comfortable seeing this data in a public browser history, or shared with an external website?

How information within URLs creates risk

When a user clicks a link or when their webpage loads an image or script, their browser may automatically send part of the current page's URL as the referrer to the next website.

If a URL contains sensitive information-whether in a query string (after the ?) or, less commonly, embedded directly in the URL itself (for example, ftp://user:pass@host)-that data can be exposed to:

• Third-party services like image hosts or analytics platforms.
• External sites the user clicks to from your Salesforce page.
• Logs captured by intermediary systems or browser plugins.

Most users (and even some developers) don't realize this sharing happens by default with some customizations or integrations.

How does this happen in Salesforce?

By default, Salesforce keeps sensitive data out of URLs. But issues can arise when customizations or integrations pass data through query strings or route parameters. Examples of scenarios where this might happen are:

• A Visualforce page appends a user's email to the URL for filtering results.
• A Lightning component includes an Org ID in the page path.
• An integration sends credentials as part of a GET request, instead of using a more secure POST.

These shortcuts might seem harmless during development but if left unchecked, can introduce long-term security risks.

Best Practices: How to protect your org

Keep sensitive data out of URLs

• Don't pass usernames, passwords, tokens, or personal data as query parameters.
• Use secure storage mechanisms (session state, secure cookies, Apex controllers).
• Review your Visualforce pages, Lightning components, and integrations for unsafe URL patterns.

Control what Salesforce shares

• Enable Referrer Policy Protections: In Setup → Session Settings, enable the referrer-policy HTTP header to control what parts of your Salesforce URLs get shared with external sites.
• The recommended setting is strict-origin-when-cross-origin-it keeps your origin visible when needed but hides the full URL from external sites.
  See how to configure this ›

Monitor and educate

• Audit your internal and external logs for sensitive URL data.
• Make secure URL design part of your development and code review processes.
• Share this knowledge with your admins, dev teams, and security partners.
  

What happens if you don't?

When sensitive data ends up in a URL, it's hard to control where it goes next. If an external site or service captures that URL:

• User privacy could be compromised.
• Attackers might use that info to target your users or org.
• Logs, browser histories, or external systems could inadvertently store private information.

Beyond the technical risks, this erodes the trust your users place in your Salesforce apps.

What to do today

✔️ Review your Salesforce apps and integrations for sensitive data in URLs.
✔️ Enable the referrer-policy HTTP header in your org.
✔️ Share this best practice with your teams-because the best protection is prevention.

Keep learning, keep protecting

Security is a shared responsibility-and it starts with the small things. Review your org today and make sure sensitive data stays where it belongs.

Protect Sensitive Information in Your URLs (Help Article)

Salesforce Security Basics (Trailhead Module)

The more we build with security in mind, the stronger we make our entire ecosystem.

Share article

Just For You

Explore related content by topic

• Security

Laura engages with customers, partners and the security industry to drive awareness and adoption of security best practices. She has worked in the security industry for more than 10 years and is extremely passionate about helping people keep their valuable PII and data secure. Currently, Laura runs...Read More Salesforce's external security awareness programs and educates customers on how to secure their Salesforce orgs.