Skip to:
Content

BuddyPress.org

Opened 5 months ago

Last modified 5 months ago

#9296 new enhancement

Username exposed in members url

Reported by: aboutm2's profile aboutm2 Owned by:
Milestone: Awaiting Review Priority: high
Severity: major Version: 14.3.2
Component: Core Keywords: has-privacy-review
Cc:

Description

profile URL structure is typically /members/[username]/, where [username] is the user's username.

Username is sensitive information and exposing it is a security risk.

Could the profile url structure be reconsidered?

For example use [user_id] as a long, randomly generated, non-sequential string (a UUID or GUID, e.g., a1b2c3d4-e5f6-7890-1234-567890abcdef

Change History (2)

#1 @dcavins
5 months ago

Thanks for creating this ticket. I am not sure that usernames are generally considered sensitive (thinking of other social networks like twitter and facebooks that use the same URL structure, like https://x.com/username/), so would not be in favor of obfuscating them by default--since connections are the whole point of BP.

Have you considered checking the "private community" option on your BuddyPress site and putting the members area completely behind a login fence?

Thanks!

#2 @joelkarunungan
5 months ago

Totally understand the comparison with platforms like Twitter or Facebook. However, many modern platforms now allow user-controlled handles that are distinct from login IDs. In BuddyPress, since user_nicename is used for both the public profile URL and @mention handle, and it's auto-derived from user_login, there's currently no way to decouple the two — and that’s where the privacy concern arises.

Even if usernames aren’t always considered sensitive, it would be helpful if:

  • The user_nicename could be editable by the user or admin — similar to how social platforms let users set their public-facing handle.
  • There was an option to allow a custom alias or slug override, separate from login credentials.

Understandably, changing user_nicename could break existing links or mentions, so perhaps a redirect mechanism or canonical mapping could address that.

Not advocating for UUIDs or hashes in URLs, but for flexibility, especially for communities that want user-friendly URLs without exposing login IDs.

Appreciate the continued work on BuddyPress. Just hoping it evolves toward a more decoupled and privacy-aware identity system in the future.

Note: See TracTickets for help on using tickets.