IDOR in a newsletter API — the UI hides it, the API hands it over

Quick answer

An endpoint on a professional social network let you query the subscriber list of any newsletter by changing a public parameter in the URL. The interface only showed the button to the owner, but the server didn't validate authorization: the "protection" was purely visual. A classic IDOR pattern — the UI restricts, the API doesn't.

Context

The platform has a newsletter system: creators publish content and users can subscribe. A newsletter owner can view their subscriber list from the interface, but that information should be private and accessible only to them.

The problem is in the endpoint that serves that list. It doesn't validate on the server that whoever makes the request is the newsletter owner.

The vulnerable endpoint

GET /voyager/api/PublishingDashSeriesSubscribers
  ?decorationId=com.target.voyager.dash.deco.publishing.SeriesSubscriberMiniProfile-2
  &count=10
  &q=contentSeries
  &seriesUrn=urn%3Ax%3Afsd_contentSeries%3A<NEWSLETTER_ID>
  &start=0
HTTP/2

The key parameter is seriesUrn. It contains the newsletter ID. That ID is public — it appears in the URL of any newsletter visible on the platform.

There's no check that the authenticated user making the request is the owner of that newsletter. Any authenticated session can query the subscriber list just by changing the NEWSLETTER_ID.

Steps to reproduce

1. Create your own newsletter.
2. Open the newsletter and click Subscribers.
3. Capture the GET request with Burp.
4. Identify the seriesUrn parameter with your own NEWSLETTER_ID.
5. Get the victim newsletter's NEWSLETTER_ID from its public URL.
6. Replace the NEWSLETTER_ID in the captured request.
7. Replay the request → response with the full list of subscribers and their data.

Root cause

The UI only renders the Subscribers button to the newsletter owner. That creates a false sense of security. But the visual restriction doesn't imply a restriction in the API. Any authenticated client can call the endpoint directly, ignoring entirely what the interface shows (or doesn't show).

Web interface
    ↓ Only shows "Subscribers" to the owner (visual-only protection)

Server / API
    ↓ Receives an arbitrary NEWSLETTER_ID
    ↓ Does it check the requester is the owner?  →  NO
    ↓ Returns the subscriber list

Exposed data

The response includes each subscriber's profile: full name, job title, company, profile photo and profile URL. On a platform with hundreds of millions of professional users, a niche newsletter's subscriber list can be competitively sensitive information.

Impact

• Full enumeration of the subscribers of any newsletter, including profiles that might not be public or that the user wouldn't want associated with a specific subscription.
• Competitive intelligence: subscriber lists of competitors', investors', or relevant industry figures' newsletters.
• A basis for phishing or unsolicited outreach campaigns with very precise targeting.

What to hunt for in similar targets

This pattern shows up constantly. When you audit any feature that has an "owner" and an associated data list:

• Capture the legitimate request from your account.
• Identify the parameter that references the resource (here seriesUrn).
• Check whether that identifier is predictable or public.
• Swap it for another user's and observe the response.

If the server returns data without validating that the requester has access to that specific resource, it's an IDOR. The fact that the UI doesn't show the button does not count as access control.

Related labs

Practice IDOR on real APIs with public identifiers and see how to separate UI-gating from real authorization: IDOR labs.