At minimum, the vendor learns the visitor's IP address, browser details and the request headers. It may also receive cookies it set earlier on other sites and, depending on settings, the page address you came from. If the script runs, it can read whatever the page exposes.
The browser talks to the vendor directly
The OWASP Third Party JavaScript Management Cheat Sheet explains the mechanism. When a third-party script is invoked, the browser contacts the third-party server itself, and by default the request includes all regular HTTP headers.
OWASP lists what the third party obtains beyond the originating IP address: the referrer (the cheat sheet notes this for non-HTTPS requests) and any cookies the third party set before, for example when the person visited another organization's website that also invokes the same script.
That second part is the one store owners miss. If many shops load the same vendor script, the vendor can recognize the same visitor across all of them.
What is exposed at each layer
| Layer | What the vendor can receive |
|---|---|
| Network request | IP address, request headers, any cookies it set before |
| Referrer information | The address of your page, limited by your Referrer-Policy |
| Script running in the page | Anything the page exposes to JavaScript, such as visible text and form values |
| Data you pass on purpose | Fields in your data layer or event calls |
OWASP also notes that when a third party shares one script across many entities, it gathers secondary data from all of them. The vendor sees who your visitors are and which other organizations they interact with.
Why this matters for a store
A product page address can reveal what a person is shopping for. An order confirmation page can carry order details. A URL with an email address or a token in the query string can end up in a vendor's logs if it travels in the referrer or in an event.
Mixed into this are privacy duties that differ by region. Ask your own counsel what applies to you. The security point is simpler: you cannot control what a vendor does with data you let it see, so decide what it should see before the script loads.
Ways to limit exposure
- Pick the pages. Do not load marketing scripts on checkout, login or account pages unless the business case is clear.
- Set a Referrer-Policy. The MDN documentation lists values that limit how much of the address is shared. The default when none is set is strict-origin-when-cross-origin, which sends only the origin on cross-origin requests over HTTPS.
- Keep personal data out of URLs. No emails or tokens in query strings.
- Use a defined data layer. Send vendors a fixed set of fields instead of letting scripts read the page.
- Mirror where you can. OWASP lists in-house script mirroring as a defense against leakage of requests to third parties.
You can read more about the referrer part in which Referrer-Policy value stops URL leaks.
Write down what each vendor receives
For each vendor in your register, list the data it can see and the pages it runs on. When someone asks a question about a customer's data, you will have a starting point.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers the packages in your build, and its policies can enforce rules on them. For vendor scripts the controls are on the page and in your contracts. A free scan is at gold.safeguard.sh/scan.
Quick check
Does the vendor see my customers if I use HTTPS?
HTTPS protects the connection from outsiders. The vendor still receives the request and everything the script reads.
Can a Referrer-Policy stop all leakage?
No. It limits the referrer. The IP address, headers, cookies and anything the script reads are separate.
Sources
Last reviewed: 19 October 2026.
