Authentication and Authorization Security#

The buyer-api and member service contain several overlapping security weaknesses: sensitive endpoints are fully unauthenticated due to an overly broad URL whitelist, MemberService overloads have inconsistent authorization logic, and the acting principal is not reliably verified against the target member in multiple code paths.

Affected files at a glance:

Vulnerability 1 — Overly Broad URL Whitelist (Unauthenticated Access)#

BuyerSecurityConfig enforces anyRequest().authenticated() as the default rule but reads its permit-all list from application.yml. Line 112 of that file includes the wildcard /buyer/passport/member/**, which bypasses JWT token validation for every endpoint under MemberBuyerController 1.

As a result, the Spring Security filter chain never validates a token for any of the following routes, and handlers that call UserContext.getCurrentUser() will receive null rather than blocking at the gateway layer 2:

The extra entry /buyer/passport/member/refresh/** on line 113 is redundant given the broader wildcard already covers it 3.

Vulnerability 2 — Inconsistent Authorization Across changeMobile Overloads#

MemberService declares two overloads 4:

• changeMobile(String mobile) — resolves the current principal from UserContext internally and asserts ownership before writing. ✅ Correctly scoped.
• changeMobile(String memberId, String mobile) — accepts a caller-supplied memberId and updates that record with no ownership check. ❌ IDOR vulnerability.

bindMobile calls the two-argument overload after SMS verification, passing member.getId() resolved from a caller-supplied username parameter. Because /buyer/passport/member/** is on the whitelist, the SMS step is the only barrier. The service layer itself will accept any memberId from any caller, meaning the SMS verification for one phone number can be leveraged to reassign a different member's mobile.

Vulnerability 3 — appSConfirm: Principal Not Verified Against QR Session#

POST /app_confirm delegates to memberService.appSConfirm(token, code). The implementation checks only that some authenticated user is present, then unconditionally associates that user's ID with whichever QR session token was passed in. There is no check that the token belongs to the acting principal.

An authenticated attacker who obtains or guesses another user's QR session token (e.g., from QR code exposure or replay) can confirm or cancel that user's login session.

The correct pattern — used by OrderBuyerController.detail() — is to call OperationalJudgment.judgment() after fetching the resource, which asserts that tokenUser.getId() equals the resource's memberId field and throws USER_AUTHORITY_ERROR if not 5.

Vulnerability 4 — Receipt Endpoints: Missing Ownership Binding (IDOR)#

ReceiptBuyerController exposes two unenforced endpoints under /buyer/trade/receipt:

• GET /{id} — fetches a receipt by primary key with no ownership assertion.
• GET / (list) — returns a paged receipt list; ReceiptSearchParams is accepted from the caller directly with no forced memberId injection.

Neither endpoint calls OperationalJudgment.judgment() or pins memberId to the session principal before querying. This is an IDOR-style data exposure: any authenticated buyer can enumerate or retrieve another buyer's invoice records by supplying an arbitrary id or omitting the memberId filter.

Contrast with the correct pattern in OrderBuyerController.queryMineOrder(): the list endpoint immediately overwrites the caller-supplied memberId with currentUser.getId() before passing params to the service, guaranteeing scope isolation.

Remediation Guidance#

The shared OperationalJudgment utility already provides the canonical ownership-check implementation. Use it consistently rather than relying on individual null-checks scattered across controllers.