User profile API ignores privacy settings and always returns email and wallet address

[3m1n3nc3]

Description

app/app/api/users/[id]/route.ts selects profileVisibility but never enforces it, and always returns email and walletAddress regardless of the user's showEmail / showWalletAddress flags (both default to false). This applies to any caller, including anonymous requests, and the profile sub-resource endpoints (posts, entries, stats, activity, followers, following) have no privacy gating either.

The result is a PII leak: any user's email and Stellar wallet address are publicly readable, and "private" profiles are fully visible.

More info

• File: app/app/api/users/[id]/route.ts (approx. lines 19-73)
• Files: app/app/api/users/[id]/{posts,entries,stats,activity,followers,following}/route.ts
• Gate the response by profileVisibility and the requester's relationship (self / follower / public).
• Strip email and walletAddress unless the requester is the user themselves or the corresponding show* flag is true.
• Add tests asserting a third party cannot read email/wallet of a user with the default privacy settings.

[amina69]

Hi team,

I would love to work on this issue. I have experience with Next.js App Router API routes, TypeScript, and implementing role/relationship-based access control (RBAC).

Proposed Solution:

1. Centralized Privacy Helper: Create a utility function (e.g., validateProfileAccess) to check the requester's identity, follow status, and the target user's profileVisibility (PUBLIC, FOLLOWERS, PRIVATE).
2. Sanitization Engine: Create a helper to strip email and walletAddress based on showEmail, showWalletAddress, and whether the requester is the resource owner.
3. Main Route Protection: Update app/app/api/users/[id]/route.ts to block unauthorized requests and apply the sanitization engine.
4. Sub-resource Gating: Apply the visibility check to the sub-resource routes (posts, entries, stats, activity, followers, following) to ensure "private" profiles return a 403 Forbidden or 404 Not Found for unauthorized callers.
5. testing Write integration tests (using Jest/Vitest or Playwright) confirming that anonymous/third-party requests cannot read sensitive PII under default privacy configurations.

Could you please assign this issue to me? Thanks!

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. Thank you!

[grantfox-oss]

🦊 GrantFox — @amina69 has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #353)
2. Your PR will be reviewed by the geevapp maintainers

Good luck! Track your progress on GrantFox.

[Auwal007]

@Auwal007 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I can architect the privacy gating layer across your user profile endpoints. I'll focus on refactoring app/app/api/users/[id]/route.ts and its associated sub-resource routes to evaluate the profile owner's privacy configurations against the requester's session context. I will build an isolation check that determines the relationship tier (self, follower, or public) and dynamically strips out PII fields like email and walletAddress unless explicit visibility criteria or user ownership checks pass. Having designed secure access control layers and defensive data-gating mechanisms for Web3 and identity backends before, I'll ensure we completely plug this PII leak.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Auwal007 to this issue.

[samlogy1]

@samlogy1 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I’d like to work on this. I’m comfortable with backend API/privacy fixes and can enforce the profile visibility rules properly, prevent unintended email and wallet exposure, and add tests around third-party access to protected profile data.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @samlogy1 to this issue.