firstParty proxy: multiple bugs in proxy URL construction, script bundling, and registry matching

[felixgabler]

Environment

• @nuxt/scripts version: 1.0.0-beta.1 (built from commit b0a5dca on main, PR feat: first-party proxy mode with privacy anonymization #577)
• Mode: firstParty: { privacy: 'proxy' }

Description

Two bugs in the firstParty proxy implementation:

1. Missing path separator in proxy URL construction

Both the beacon intercept plugin and the SW template construct proxy URLs by concatenating rule.target + pathWithoutPrefix, but when pathPrefix is / (e.g., Meta Pixel at connect.facebook.net/en_US/fbevents.js), the stripped path loses its leading /:

pathPrefix = "/"
pathname = "/en_US/fbevents.js"
pathWithoutPrefix = pathname.slice(pathPrefix.length) = "en_US/fbevents.js"  // no leading /
proxyUrl = "/_proxy/meta" + "en_US/fbevents.js" = "/_proxy/metaen_US/fbevents.js"  // WRONG

Expected: /_proxy/meta/en_US/fbevents.js

Affected locations:

• module.mjs ~line 1175 (beacon intercept plugin)
• runtime/sw/proxy-sw.template.js ~line 39 (SW fetch intercept)

Fix: Add a separator:

const separator = pathWithoutPrefix.startsWith('/') ? '' : '/';
const proxyUrl = rule.target + separator + pathWithoutPrefix + parsed.search;

Note: rewriteScriptUrls in runtime/utils/pure.js correctly uses joinURL() for the same operation, so this is only a bug in the two intercept paths.

2. Registry scripts with static src (no scriptBundling) are never bundled

Scripts like Meta Pixel and Reddit Pixel define src in their registry entry but don't have a scriptBundling function:

// registry.mjs - Meta Pixel
{
  proxy: "metaPixel",
  src: "https://connect.facebook.net/en_US/fbevents.js",
  // no scriptBundling
}

In the AST bundle transformer (NuxtScriptBundleTransformer), registryNode.src is only checked in the guard at line ~496 but never used as a fallback source for bundling:

// Line 496: guard passes because registryNode.src is truthy
if (!registryNode.scriptBundling && !registryNode.src) return;

// Line 513-518: but src is only set from scriptBundling, never from registryNode.src
if (!scriptSrcNode) {
    src = registryNode.scriptBundling && registryNode.scriptBundling(mergedOptions);
    // registryNode.src is never used as fallback!
}

// Line 520: both are falsy → early return, bundling skipped entirely
if (!scriptSrcNode && !src) { return; }

Result: The script loads from the third-party URL at runtime. The SW must intercept it, but the SW isn't active on first page load → script only loads through proxy on refresh, not on initial visit.

Fix: Add registryNode.src as fallback after line 517:

if (!src && registryNode.src)
    src = registryNode.src;

This makes scripts with static src get properly bundled at /_scripts/hash.js with proxyRewrites applied to their content, removing the SW dependency for initial script loading.

Reproduction

1. Configure scripts: { firstParty: { privacy: 'proxy' } } with metaPixel in registry
2. Deploy to Vercel
3. Observe /_proxy/metaen_US/fbevents.js (404) in network tab instead of /_proxy/meta/en_US/fbevents.js
4. Observe that Meta Pixel script is NOT bundled at /_scripts/ — it tries to load from the third-party URL
5. On first page load, SW isn't active → script loads directly from connect.facebook.net (bypassing proxy entirely)
6. On refresh, SW intercepts but constructs wrong proxy URL (bug 1)

[felixgabler]

TikTok pixel: missing TiktokAnalyticsObject global in clientInit

The TikTok pixel factory (runtime/registry/tiktok-pixel.js) creates window.ttq but doesn't set window.TiktokAnalyticsObject = "ttq".

TikTok's events.js expects this global on line 2:

window[window["TiktokAnalyticsObject"]]._env = { env: "external", key: "" };

Without it, window[undefined] is undefined, so this throws:

Uncaught TypeError: Cannot set properties of undefined (setting '_env')

The standard TikTok snippet sets this global, but the simplified clientInit omits it:

 clientInit: () => {
+  window.TiktokAnalyticsObject = "ttq";
   const ttq = window.ttq = function(...params) { /* ... */ };
   // ...
 }

Workaround: Set window.TiktokAnalyticsObject = 'ttq' in your own code after calling useScriptTikTokPixel().

[felixgabler]

Registry key matching is case-sensitive, breaking TikTok proxy routes

The first-party proxy route registration matches config registry keys to script imports using:

registryScriptsWithImport.find((s) => s.import.name === `useScript${key.charAt(0).toUpperCase() + key.slice(1)}`)

For tiktokPixel, this generates useScriptTiktokPixel — but the registry defines the import as useScriptTikTokPixel (capital T in "Tok"). The match fails, so:

1. TikTok proxy routes (/_proxy/tiktok/**) are never registered
2. The beacon intercept still rewrites browser-side URLs (it uses all configs)
3. Server returns 404: No proxy target found for path: /_proxy/tiktok/api/v2/pixel/act

Fix: Use case-insensitive comparison:

-s.import.name === `useScript${key.charAt(0).toUpperCase() + key.slice(1)}`
+s.import.name.toLowerCase() === `usescript${key.toLowerCase()}`

---

rewriteScriptUrls drops trailing slash via joinURL

When a script URL has a trailing slash (e.g. "https://www.google-analytics.com/"), rewriteScriptUrls computes rewriteSuffix = "/" and calls:

joinURL("/_proxy/ga", "/")  // returns "/_proxy/ga" — trailing slash lost\!

The rewritten string "/_proxy/ga" is missing the trailing slash. If the script later appends a relative path like "g/collect", the result is "/_proxy/gag/collect" instead of "/_proxy/ga/g/collect".

Fix: Preserve the trailing slash by skipping joinURL when suffix is just "/":

-const rewritten = rewriteSuffix.startsWith("?") || rewriteSuffix.startsWith("#")
+const rewritten = rewriteSuffix === "/" || rewriteSuffix.startsWith("?") || rewriteSuffix.startsWith("#")
   ? to + rewriteSuffix
   : joinURL(to, rewriteSuffix);

---

rewriteScriptUrls rewrites bare hostname strings, breaking dynamic URL construction

Hostname-only rewrite rules (e.g. { from: "www.google-analytics.com", to: "/_proxy/ga" }) match bare hostname strings in the script source that lack a URL scheme. GA4 gtag.js stores the hostname in a variable and constructs URLs dynamically:

// In the minified GA script:
var h = "www.google-analytics.com";   // ← rewritten to "/_proxy/ga"
// ...later...
fetch("https://" + h + "/g/collect"); // → "https:///_proxy/ga/g/collect"
//     browser parses _proxy as hostname → ERR_NAME_NOT_RESOLVED

The rewriteScriptUrls function has three branches for matching:

1. Full URLs (url.host set) — line 15: rewrites correctly, strips scheme
2. Protocol-relative (//hostname) — line 27: rewrites correctly
3. Bare strings — line 40: problematic for hostname-only rewrites

The bare-string branch should skip hostname-only rewrites since the string may be used in dynamic "https://" + hostname construction. Path-specific and suffix-match rewrites are fine because they include the path component.

Fix: Only enter the bare-string branch when the rewrite rule includes a path or is a suffix match:

-} else if (inner.startsWith(from) || isSuffixMatch && inner.includes(from)) {
+} else if ((fromPath && inner.startsWith(from)) || (isSuffixMatch && inner.includes(from))) {

This way hostname-only rewrites still work for full URLs (branch 1) and protocol-relative URLs (branch 2), but won't break bare hostname strings used in dynamic URL construction.

[harlan-zw]

Thank you for this detailed write-up. All should be fixed in v1.0.0-beta.2

[felixgabler]

Thanks for the quick fix! Most issues are resolved in beta.2. One thing I wanted to flag — on line 40 of pure.js, the bare-string branch:

} else if (fromPath && inner.startsWith(from) || isSuffixMatch && inner.includes(from)) {

Due to operator precedence this evaluates as (fromPath && inner.startsWith(from)) || (isSuffixMatch && inner.includes(from)), so the isSuffixMatch branch isn't gated by fromPath. In our testing this still caused the GA4 Yv function's "analytics.google.com/" to be rewritten to "/_proxy/ga/", which breaks the dynamic URL construction ("https://" + "" + "/_proxy/ga/" + "g/collect" → _proxy as hostname).

Was this intentional? We ended up using fromPath && (... || ...) in our vendored patch to gate both branches — curious if there's a reason to keep suffix matches ungated for bare strings.

[harlan-zw]

No that was a mistake, thanks for bringing it up. Have pushed a fix.

[felixgabler]

Another issue we're seeing in production (42 occurrences, 29 users) — this time with TikTok:

TypeError: "/_proxy/tiktok/api/v2/pixel/act" cannot be parsed as a URL.

Stacktrace points to the TikTok pixel script's r8 function:

var r8 = function(t, e) {
  var r = new URL(t);  // throws — relative path can't be parsed without a base
  // ...
}

What's happening: rewriteScriptUrls correctly rewrites "https://analytics.tiktok.com/api/v2/pixel/act" → "/_proxy/tiktok/api/v2/pixel/act". But the TikTok script passes this to new URL(t) without a base argument, which requires an absolute URL.

This is a different class of issue from the bare-hostname rewrite bug — here the full URL rewrite works as designed, but the resulting relative path breaks new URL() calls that don't provide a base. GA4 happens to use document.createElement("a") for URL parsing (which resolves relative URLs against the page), so it doesn't hit this, but TikTok's new URL() does.

Not sure what the right fix is here — the build-time rewrite can't really know how the script will consume the string. Maybe the rewrite should preserve the origin for scripts that are known to use new URL(), or produce absolute URLs like ${window.location.origin}/_proxy/... instead of bare relative paths?

[harlan-zw]

Thanks for all the help diagnosing this. Should be fixed in 1.0.0-beta.5.

If you're finding it too unstable you can always disable this firstParty mode, i need to do some deeper testing around it :/ Appreciate all the feedback though.

[felixgabler]

Thanks for the quick turnaround on all of these fixes — really appreciate it! We've switched from our vendored patch to beta.5 and are deploying it now. Will report back if we see any issues.