Describe the bug
createProlinkUrl() can silently replace the encoded prolink payload when additionalQueryParams contains a p key.
The helper always sets the encoded payload under the reserved p query parameter first, then applies every extra query parameter with URLSearchParams.set(). Since set() overwrites existing keys, a caller that passes { p: "..." } in additionalQueryParams gets a URL whose p value is no longer the prolink argument.
Affected file:
packages/account-sdk/src/interface/public-utilities/prolink/createProlinkUrl.ts
Current code:
const link = new URL(url);
link.searchParams.set('p', prolink);
Object.entries(additionalQueryParams ?? {}).forEach(([key, value]) => {
link.searchParams.set(key, value);
});
Steps
Minimal reproduction against the current implementation:
import { createProlinkUrl } from '@base-org/account/prolink';
const url = createProlinkUrl('real-prolink', 'https://base.app/base-pay', {
p: 'not-the-prolink',
ref: 'campaign',
});
console.log(new URL(url).searchParams.get('p'));
Observed result:
The same can be expressed as a unit test beside createProlinkUrl.test.ts:
it('does not allow additional params to overwrite the prolink payload', () => {
const result = createProlinkUrl('real-prolink', undefined, { p: 'override' });
expect(new URL(result).searchParams.get('p')).toBe('real-prolink');
});
Expected behavior
The encoded prolink payload should remain authoritative for the reserved p parameter. Additional query parameters should not be able to overwrite it silently.
Possible fixes:
- apply
additionalQueryParams first, then set p, or
- reject
additionalQueryParams.p with a clear error.
Either behavior would be safer than returning a URL where the payload no longer matches the prolink argument.
Version
Current master at 79355e2445889c3ad8a2689d5759978dc9403151.
Additional info
I searched existing issues/PRs for createProlinkUrl, additionalQueryParams p, and prolink query parameter overwrite and did not find an existing report.
Desktop
N/A
Smartphone
N/A
Describe the bug
createProlinkUrl()can silently replace the encoded prolink payload whenadditionalQueryParamscontains apkey.The helper always sets the encoded payload under the reserved
pquery parameter first, then applies every extra query parameter withURLSearchParams.set(). Sinceset()overwrites existing keys, a caller that passes{ p: "..." }inadditionalQueryParamsgets a URL whosepvalue is no longer theprolinkargument.Affected file:
packages/account-sdk/src/interface/public-utilities/prolink/createProlinkUrl.tsCurrent code:
Steps
Minimal reproduction against the current implementation:
Observed result:
The same can be expressed as a unit test beside
createProlinkUrl.test.ts:Expected behavior
The encoded prolink payload should remain authoritative for the reserved
pparameter. Additional query parameters should not be able to overwrite it silently.Possible fixes:
additionalQueryParamsfirst, then setp, oradditionalQueryParams.pwith a clear error.Either behavior would be safer than returning a URL where the payload no longer matches the
prolinkargument.Version
Current
masterat79355e2445889c3ad8a2689d5759978dc9403151.Additional info
I searched existing issues/PRs for
createProlinkUrl,additionalQueryParams p, and prolink query parameter overwrite and did not find an existing report.Desktop
N/A
Smartphone
N/A