Third-party script data leakage in SaaS login and account portals

Your SaaS login page can expose customer data before the customer signs in. An approved analytics tag, support widget, or other integration may collect information outside its intended purpose, then send it to systems your security team has not approved for that data.

The same risk can continue inside your account portal. As customers update profiles, manage subscriptions, or work with sensitive records, scripts running in the page may encounter information that was never needed for analytics or support.

For a SaaS security team, third-party script data leakage creates an ownership problem: who controls what those scripts can access, what additional code they load, and where the collected data goes? Answering it requires following both the code and the data.

Your portal exposes more than a login form

A third-party script executing directly in your page can access information available in that page’s execution context. Depending on the implementation, that may include form inputs, rendered account details, URLs, and data your application exposes to browser code. OWASP identifies sensitive-information disclosure and loss of control over application changes among the risks of third-party JavaScript.

Browser boundaries still apply. A script on your portal does not automatically gain access to a separate identity provider’s login page or a cross-origin frame. The same-origin policy restricts those interactions. HttpOnly cookies also cannot be read directly by JavaScript. Your assessment should identify the data actually exposed in each context.

Form submission is not a good boundary for that assessment. The 2022 Leaky Forms study, presented at USENIX Security, documented email-address collection before users submitted forms and incidental password collection by session-replay scripts on 52 websites. Keep in mind that the report shows a collection mechanism. It’s not a report on portal exposure.

Piggybacking brings additional scripts through an approved integration

Piggybacking means an additional script reached your page through a service or tag you installed. Your team adds one integration, and that integration brings another bit of code with it.

For example, a product analytics integration may load a connected destination’s browser library. That downstream provider becomes part of your portal’s script environment even though your developers did not add its script directly to the application.

Piggybacking can be intentional and documented. The security gap appears when approval of the original integration is treated as approval of every downstream script and its data access. Your AppSec team will want to know who the owner is for each script, what the business purpose is, and what access it should have.

Chain loading describes how that code arrives

Chain loading is the successive loading process: one script loads another, which may load further dependencies.

• Piggybacking describes the indirect arrival of additional code;
• Chain loading describes the loading path that enables it.

A tag manager might load a customer-engagement tool, which then loads a separate analytics component. Reviewing only the scripts listed in your application’s source code would miss part of that execution chain.

This is documented integration behavior. Twilio Segment explains that adding a device-mode destination can cause Analytics.js to load that destination’s code when a user next loads the site. A configuration change can therefore change the browser’s script environment without an application-code release.

Your inventory needs to capture which script initiated each load and whether the resulting code executes on login, recovery, or authenticated account pages. The loading relationship alone does not prove malicious behavior. It identifies code whose purpose and behavior need review.

Data can propagate without another script loading

Uncontrolled data propagation happens when information is collected, copied, or forwarded beyond its approved purpose or recipients. It can begin with a legitimate event containing more information than the receiving service needs.

A shared data layer is one place to examine. Google’s Tag Manager documentation describes how events and variables make information available to tags. Placing customer information there does not automatically send it to every destination, but it makes that information available to code that can access the shared object. Review what each tag actually reads and transmits.

URLs deserve the same attention. Google Analytics warns that personally identifiable information can be inadvertently transmitted in page URLs and titles. On a SaaS portal, review whether those values contain an email address, customer identifier, or account-specific information before a tool collects them.

Forwarding can also happen after data leaves the browser. Segment’s connection-mode documentation distinguishes device-mode delivery from cloud-mode delivery, where its servers route data to connected destinations. A browser request map can reveal the first recipient while leaving subsequent server-side distribution unseen.

Keep two records: the scripts that execute and the recipients that receive data. Neither record substitutes for the other.

How the exposure can develop in a SaaS portal

Consider an illustrative account-settings journey. Your product team adds an engagement tool to help customers complete onboarding. That tool loads an additional browser library through a configured integration.

A customer opens their profile and changes a billing contact. An event includes the contact’s email address and the page URL. If your event mapping forwards that payload to an analytics destination approved only for aggregate usage reporting, customer data has crossed its approved boundary. The engagement service may also route the event to another configured system.

The customer completes the update normally. No attacker or stolen credential is required for this example. The exposure comes from unnecessary data collection and excessive distribution through functioning integrations.

For your CISO, that can mean investigating which customers and data were affected. AppSec needs to trace the collection path and stop it. GRC and privacy teams need evidence of recipients and permitted uses, while the product owner needs the customer journey to keep working during remediation.

Start with one sensitive customer journey

For a midmarket SaaS team, begin with a bounded review of login, password recovery, and account settings. Agree on the data those journeys handle, then work through these steps:

1. Observe the complete journey. Use synthetic accounts and test data to record script loads and outbound requests before form submission and after authentication. Include in-app navigation when your product changes screens without a full page reload. Repeat across relevant user roles and configurations.

2. Trace both kinds of dependency. Record which script loaded each dependency. Separately, document the receiving service, destination account or property, and any configured onward routing. Confirm server-side recipients with integration owners and vendors.

3. Remove unnecessary collection. Inspect event payloads, shared data objects, URLs, and replay or diagnostic settings. Exclude credentials and recovery tokens. Minimize customer identifiers and free-text content to what the approved use requires. Validate masking before transmission.

4. Restrict runtime access. Define which scripts need access to which page elements and data. Apply controls that can enforce those boundaries, then test legitimate functionality. A script’s approved source does not establish that every action it takes is authorized.

5. Review integration changes. Assign security and application owners for each integration. Include tag-manager and vendor-side configuration changes in review. Keep a tested rollback or blocking path, and recheck sensitive journeys when scripts, routes, or destinations change.

Prioritize findings where a script accesses credentials, recovery information, or customer content without a documented need. A familiar vendor name should not lower that priority.

Put controls around customer data in the browser

Source Defense’s Client-Side Security solution provides script dependency mapping through Visual Request Map, runtime behavior monitoring, and outbound destination monitoring. These capabilities help your team investigate what runs in customer browsers and where browser requests go.

Enforcement depends on the selected plan and configuration. Standard supports on-demand script blocking; Professional and Enterprise support granular runtime policies with optional automated enforcement. Use those controls to restrict unauthorized script behavior while validating the functionality your customers need.

Browser controls address collection and transmission at the page. Your team still needs to govern what an authorized recipient retains or forwards through its own systems.

Start with your account portal’s most sensitive journey. Establish what each script needs, verify what it actually does, and restrict access that has no approved purpose.

Review your SaaS portal’s script exposure with Source Defense.