Private events and attendee data are fully accessible without authentication

[Ridanshi]

Summary

The event read endpoints currently expose private event data and attendee information to completely unauthenticated users.

Endpoints intended for event viewing do not enforce:

• authentication,
• authorization,
• or isPublic visibility checks.

As a result, private event metadata and attendee profiles can be enumerated freely.

---

Affected File

apps/backend/src/routes/event.ts

---

Root Cause

The following endpoints:

• GET /api/events/:slug
• GET /api/events/:slug/attendees

perform unrestricted queries using:

where: { slug: paramsSlug }

without validating:

• whether the event is public,
• whether the requester is authenticated,
• or whether the requester is authorized to view the event.

The attendee endpoint additionally exposes:

• usernames,
• display names,
• bios,
• pronouns,
• and company metadata.

---

Security Impact

Any unauthenticated caller can enumerate:

• private company events,
• invite-only meetups,
• internal communities,
• and attendee identity information.

Potential impact:

• PII leakage,
• private community exposure,
• social graph enumeration,
• and unauthorized access to sensitive event information.

---

Reproduction

No authentication required:

curl https://api.devcard.app/api/events/private-event-slug

curl https://api.devcard.app/api/events/private-event-slug/attendees

Response includes:

• full event metadata
• attendee public profile information

even when isPublic === false.

---

Proposed Fix

Enforce visibility validation before returning event data.

Suggested approach:

if (!event.isPublic) {
  const userId = await getAuthenticatedUserId(request);

  if (!userId) {
    return reply.status(401).send({
      error: 'Unauthorized'
    });
  }

  // optionally validate organizer/attendee access
}

Additional recommendations:

• restrict attendee enumeration,
• minimize exposed attendee fields,
• and centralize event authorization logic.

---

Acceptance Criteria

• private events are inaccessible to unauthenticated callers
• attendee data requires authorization
• public event behavior remains unchanged
• organizer/attendee access works correctly
• unauthorized requests fail safely
• regression coverage added

---

Why This Matters

Private-event visibility controls currently provide no actual protection, resulting in unrestricted exposure of event and attendee information.

[Ridanshi]

Hi @Harxhit,

I’d like to work on this issue under GSSoC'26.

I’ve already analyzed the affected event visibility flow and understand the missing authorization checks causing the exposure. I can work on implementing proper public/private visibility enforcement and attendee-access validation while preserving existing public event behavior.

Could you please assign this issue to me?

[Harxhit]

@Ridanshi I have assigned this issue to you.

[Ridanshi]

Implemented and opened PR #335 to address #300.

This patch enforces authorization checks for:

• GET /api/events/:slug
• GET /api/events/:slug/attendees

Private events are now restricted to:

• organizers,
• confirmed attendees,
• and authorized authenticated users only.

Anonymous access to private event metadata and attendee enumeration is blocked with proper 401/403 handling, while existing public-event behavior remains unchanged.

Also included:

• centralized event visibility helpers,
• regression coverage for all access combinations,
• and route registration cleanup to prevent double-prefixed event paths.

Conflicts with latest main are being resolved and the branch will be updated shortly for re-review.