Skip to content

/api/user-data trusts an x-wallet-address header - #10

Merged
P3az3 merged 2 commits into
MillestoneX:mainfrom
Kwin-xeexee:api/user-data-trusts-an-x-wallet-address-header
Aug 24, 2026
Merged

/api/user-data trusts an x-wallet-address header#10
P3az3 merged 2 commits into
MillestoneX:mainfrom
Kwin-xeexee:api/user-data-trusts-an-x-wallet-address-header

Conversation

@Kwin-xeexee

Copy link
Copy Markdown
Contributor

Summary

This PR secures the /api/user-data endpoint and replaces the race-prone file-based user data store with durable server-side storage.

Previously, the API trusted the client-supplied x-wallet-address header as the user's identity. This allowed any client to access, modify, or delete another user's data by providing their wallet address. User data was also stored in a single JSON file, where concurrent read-modify-write operations could overwrite each other's changes.

This change derives the wallet address from a verified authentication token and moves user data to a durable storage backend while preserving the existing UserDataSnapshot shape.

Changes

  • Added authentication checks to GET, PUT, and DELETE /api/user-data.
  • Derive the user's wallet address from the verified JWT walletAddress claim instead of trusting x-wallet-address.
  • Ignore forged or mismatched x-wallet-address headers when an authenticated identity is present.
  • Reject unauthenticated requests.
  • Replaced the single-file JSON persistence layer with durable server-side storage.
  • Prevented concurrent updates from silently overwriting another user's changes.
  • Preserved the existing UserDataSnapshot structure to avoid unnecessary changes to consumers.
  • Updated the user data flow where necessary to work with the authenticated identity.
  • Added security and persistence tests covering cross-user access and forged headers.

Security

The previous implementation allowed requests such as:

GET /api/user-data
x-wallet-address: another-users-wallet

to access another user's data.

The API now requires a valid token and derives the wallet address from the authenticated identity. The client can no longer select which user's data to access simply by changing a request header.

Testing

  • Verified unauthenticated GET, PUT, and DELETE requests are rejected.

  • Verified an authenticated user can access their own data.

  • Verified a client cannot access another wallet's data by modifying x-wallet-address.

  • Verified a forged x-wallet-address is ignored when a valid authenticated identity is present.

  • Verified user data persists across application restarts.

  • Verified concurrent saves do not silently discard updates.

  • Ran:

    • npm run type-check
    • npm run lint

Files Changed

  • app/api/user-data/route.ts
  • lib/server/userDataStore.ts
  • lib/api/userData.ts
  • hooks/useUserDataSync.ts
  • Relevant tests and configuration for the new persistence/authentication flow

Acceptance Criteria

  • User data endpoints require a verified authentication token.
  • Wallet identity is derived from the authenticated token.
  • x-wallet-address cannot be used to impersonate another user.
  • User data is stored durably rather than in a single local JSON file.
  • Concurrent updates do not silently overwrite user data.
  • Existing UserDataSnapshot consumers continue to work.
  • Security and persistence behavior is covered by tests.

Closes #4

@P3az3 P3az3 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

/api/user-data trusts an x-wallet-address header and persists to one race-prone JSON file

2 participants