Security: /api/bundle/getunsendbundles does not verify the path userId matches the authenticated user

[hmoreras]

Description

BundleResource#getUnsendBundles (path /api/bundle/getunsendbundles/userid/{userId}) reads the target userId from the URL path parameter (initData.getParamsMap().get("userid")) and passes it directly to BundleAPI.getUnsendBundles(userId, ...).

There is no check that the path userId matches the authenticated caller's user id — only requiredBackendUser(true) is enforced. Any authenticated backend user can therefore enumerate the draft bundles of any other backend user by editing the URL path.

Code location: dotCMS/src/main/java/com/dotcms/rest/BundleResource.java:181-232

Impact: horizontal information disclosure — bundle names and identifiers created by other backend users leak to any authenticated backend user. The shipped Publishing Queue UI only calls the endpoint with the current user's own id (via DotCurrentUserService), so there is no exploit path from the admin UI itself. The gap is exploitable via direct API calls (curl, Postman, browser dev console).

How it was surfaced: code review of PR #36413 (Publishing Queue Angular portlet).

Acceptance Criteria

To be refined. (Quick draft — details to be added after team confirms scope.)

• Confirm with team whether the intended behavior is "own drafts only" or "all drafts visible to admins"
• If own-drafts-only: reject requests where params.userid does not equal initData.getUser().getUserId() (return 403); allow admins to bypass if that's the intended model
• Postman coverage: 403 when user A queries user B's userid; 200 when user A queries their own

Priority

Medium — no exploit path from the shipped UI, but the endpoint is publicly reachable to any authenticated backend user.

Additional Context

Same category as the retry/push gating gap filed in #36414 — hardening the v1/legacy Publishing endpoints as part of the Angular migration cleanup.

[hmoreras]

QA Verified ✅

Ran manual QA against a local sender (localhost:8081, dotcms/dotcms:modernization built from f574a9de4a). Confirmed PR #36446 (bce3f77) is present in the image via the class-string marker is not allowed to list bundles owned by.

Test setup

• UserA (qa36414-usera2) — non-admin backend, has Site layout
• UserB (qa36414-userb) — non-admin backend, has Site layout
• Admin (dotcms.org.1)
• Seeded real unsent bundle qa36415-userB-draft owned by UserB, so cross-user leak would surface real data if the guard failed

Results

#	Scenario	Expected	Actual	Verdict
1	GET /getunsendbundles/userid/{self} as UserA	200	200, empty list (UserA has no drafts)	✅
2	GET /getunsendbundles/userid/{userB} as UserA	403, no leak	403 — User 'qa36414-usera2' is not allowed to list bundles owned by user 'qa36414-userb' — UserB's bundle name not in response	✅
3	GET /getunsendbundles/userid/{userB} as admin	200, sees UserB's bundles	200, returns [{id: d1dab227…, name: qa36415-userB-draft}]	✅
4	GET /getunsendbundles/userid/{self} as UserB	200, sees own bundle	200, returns [{id: d1dab227…, name: qa36415-userB-draft}]	✅

Follow-up worth noting (not blocking)

Two edge-case paths skip the new check via UtilMethods.isSet(userId):

#	Scenario	Actual
E1	GET /getunsendbundles/ (no userid/… segment) as UserA	200, empty list
E2	GET /getunsendbundles/userid/ (empty userId) as UserA	200, empty list

Behavior today is safe — BundleAPI.getUnsendBundles(null, …) returns [], so no data leaks. But the guard depends on the BundleAPI's null-handling remaining that way. Two options if we want defense-in-depth here:

1. Reject when userId is not set (400) — tightest and most explicit
2. Fall back to currentUser.getUserId() when absent — matches the intent that the endpoint returns the caller's drafts

All shipped callers (Angular Add-to-Bundle, legacy Dojo dialog, dot-rules, legacy queue JSP) pass the current user's id, so neither option should break real traffic. Happy to file this as a small follow-up if desired.

AC coverage

• Confirm intended behavior — "own drafts only, admins may query anyone" ✅
• 403 when user A queries user B's userid ✅
• 200 when user A queries their own ✅

Closing this out — PR #36446 addresses the ticket as scoped.