chore: fix signature verification sorting issue cp-7.60.0

[smilingkylan]

Related issues

Fixes: #23222

• issue where URL canonicalization was not properly sorting due to the way that .sort works on React Native.
• add case for sig_params being empty, so that we can still sign links without any parameters that need to be signed
• removed edge case unit test since it added very little value (no one should be using spaces in a signed URL)

Description

Reason for change:
Deep link signature verification was failing for marketing links (e.g., https://link.metamask.io/perps?sig_params=...&utm_...). The Mobile app's canonicalize function had diverged from the Extension's implementation, causing signature mismatches.

The root cause: React Native's URLSearchParams.sort() is not implemented — it throws an error. This meant parameters weren't being sorted correctly, so the canonical URL didn't match what was signed.

Improvement/solution:
Updated the canonicalize function to:

1. Use custom array sorting instead of URLSearchParams.sort() (which is broken in React Native)
2. Handle empty sig_params explicitly — when sig_params='', only include sig_params itself in the canonical URL (allows appending UTMs after signing)
3. Use getAll()/append() instead of get()/set() to preserve multiple values for the same parameter (matches Extension behavior)
4. Use encodeURIComponent() for consistent URL encoding

These changes align Mobile with the Extension's canonicalization logic, ensuring signed deep links verify correctly.

Changelog

CHANGELOG entry: Fixed deep link signature verification failing for marketing links with UTM parameters

Manual testing steps

Feature: Deep Link Signature Verification

  Scenario: user opens a signed deep link with sig_params and appended UTMs
    Given a signed deep link with sig_params listing specific parameters
    And UTM parameters are appended after signing

    When user opens the deep link in the app
    Then the signature verifies successfully
    And the user is not shown the unsigned link warning modal

  Scenario: user opens a signed deep link with empty sig_params
    Given a signed deep link with sig_params= (empty)
    And UTM parameters are appended after signing

    When user opens the deep link in the app
    Then the signature verifies successfully
    And only sig_params is used for verification (UTMs ignored)

  Scenario: user opens a signed deep link without sig_params (legacy)
    Given a signed deep link without any sig_params parameter

    When user opens the deep link in the app
    Then all parameters (except sig) are included in verification
    And the signature verifies successfully (backward compatibility)

Screenshots/Recordings

Before

Signed marketing links showed the "unsigned link" warning modal due to signature verification failure.

After

Signed marketing links verify correctly and open without the warning modal.

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

---

Labels to add: team-mobile-platform

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[Cal-L]

Left a comment

[Cal-L]

Add unit test to cover cases that this intends to fix

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.59%. Comparing base (861b876) to head (a1382d1).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #23220      +/-   ##
==========================================
+ Coverage   78.56%   78.59%   +0.02%     
==========================================
  Files        3947     3947              
  Lines      102433   102423      -10     
  Branches    20311    20303       -8     
==========================================
+ Hits        80481    80497      +16     
+ Misses      16407    16385      -22     
+ Partials     5545     5541       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MarioAslau]

LGTM

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeCore, SmokePerps, SmokeRewards, SmokePredictions, SmokeRamps, SmokeSwaps, SmokeCard
• Risk Level: high
• AI Confidence: 85%

click to see 🤖 AI reasoning details

The changes are in a critical deeplink signature verification utility (verifySignature.ts) located in app/core/DeeplinkManager/. This is a security-sensitive component that validates signed URLs for universal/deeplinks.

What Changed:
The canonicalize() function underwent significant refactoring to fix URL parameter sorting and handling:

1. Parameter sorting logic changed: Now manually sorts params array instead of using URLSearchParams.sort()
2. Empty sig_params handling: New special case for when sig_params is explicitly empty string
3. Manual URL encoding: Now explicitly uses encodeURIComponent for both keys and values
4. Bug fix for parameter ordering: Added test confirming fix for marketing link breakage due to alphabetical sorting (sig_params vs utm_*)

Why This is High Risk:

1. Security Component: Signature verification protects against deeplink spoofing and unauthorized access
2. Core Functionality: Located in app/core/ and used by DeeplinkManager, which routes to multiple features
3. Wide Impact: The verifyDeeplinkSignature function is used by handleUniversalLink.ts which routes to:
   • Perps (PERPS, PERPS_MARKETS, PERPS_ASSET)
   • Rewards (REWARDS)
   • Predictions/Predict (PREDICT)
   • Ramps (BUY, SELL, BUY_CRYPTO, SELL_CRYPTO, DEPOSIT)
   • Swaps (SWAP)
   • Card (ENABLE_CARD_BUTTON)
   • Other core features (HOME, SEND, CREATE_ACCOUNT, ONBOARDING, WC, DAPP)
4. URL Canonicalization Change: Any bug in URL canonicalization could cause valid signatures to fail or invalid ones to pass
5. Regression Risk: Changes to cryptographic verification logic have high potential for regression

Why These Tags:

• SmokeCore: CRITICAL - Core deeplink infrastructure affects app navigation and state management
• SmokePerps: Deeplinks route to perps feature (handlePerpsUrl)
• SmokeRewards: Deeplinks route to rewards (handleRewardsUrl)
• SmokePredictions: Deeplinks route to predictions/predict (handlePredictUrl)
• SmokeRamps: Deeplinks route to buy/sell ramps (handleRampUrl)
• SmokeSwaps: Deeplinks route to swap feature (handleSwapUrl)
• SmokeCard: Deeplinks route to card button enablement (handleEnableCardButton)

The changes are well-tested (comprehensive test updates included), but the security-critical nature and wide impact across multiple features warrant thorough E2E validation of all deeplink-dependent flows.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
93.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Cal-L]

LGTM