Endpoint `/users/me` may incorrectly apply CLP

[coderabbitai]

Summary

@jduskes-mogiletech raised a concern in PR #10279 (comment: #10279 (comment)) that the refactor of handleMe in src/Routers/UsersRouter.js may introduce a breaking change.

Claim

The Parse Platform REST guide (Security Edge Cases) documents that the /parse/users/me endpoint intentionally bypasses the Class-Level Permission (CLP) "Get" setting, allowing a logged-in user to always retrieve their own data regardless of CLP configuration.

What changed in PR #10279

Before the PR, handleMe fetched the user via { include: 'user' } using the master key context, which bypasses CLP entirely.

After the PR, handleMe re-fetches the user via rest.get using the caller's auth context, which causes CLP, protectedFields, and auth adapter afterFind hooks to be applied. This means if the _User class has a restrictive "Get" CLP (e.g., set to Master Key only or no access), a valid session holder may no longer be able to fetch their own data via /users/me, which is a behavioral regression.

Action Required

• Verify whether the Parse Platform spec mandates that /users/me bypasses "Get" CLP.
• Determine if the PR fix: Auth data exposed via /users/me endpoint (GHSA-37mj-c2wf-cx96) #10279 change breaks this documented guarantee.
• If confirmed, decide how to re-apply protectedFields and afterFind hooks while still bypassing CLP for /users/me.

References

• PR: fix: Auth data exposed via /users/me endpoint (GHSA-37mj-c2wf-cx96) #10279
• Comment: fix: Auth data exposed via /users/me endpoint (GHSA-37mj-c2wf-cx96) #10279 (comment)
• Reported by: @jduskes-mogiletech

[parse-github-assistant]

🚀 Thanks for opening this issue!

[mtrezza]

@jduskes-mogiletech Thanks for reporting this. The behavior change in PR #10279 is intentional and was introduced as a security fix for GHSA-37mj-c2wf-cx96.

The previous implementation of /users/me used the master key internally to fetch the user via a session include. This caused all security layers — including auth adapter sanitization — to be bypassed for the returned user data. As a result, highly confidential authentication data such as MFA TOTP secrets and recovery codes was leaked to the client in plaintext. This data is internal to Parse Server and is not supposed to leave the server scope.

The fix separates the session validation (master key) from the user fetch (caller's auth context), so that protectedFields, auth adapter afterFind hooks, and CLP apply correctly. The CLP bypass documented in the REST guide was never an intentional security design — it was a side effect of the master key usage that happened to be documented. Preserving backward compatibility here is not possible without re-introducing the vulnerability, since it is the master key context itself that causes the data leak. Fixing the leak and maintaining the CLP bypass are mutually exclusive.

If your setup relies on a restrictive "Get" CLP on the _User class while expecting /users/me to still work, the recommended approach is to adjust your CLP to allow authenticated users to "Get", and use protectedFields to control which fields are visible. The protectedFields owner exemption ensures that a user accessing their own record sees their full data.

I'm closing this issue for now, but if you want to make a case for why the behavior should change, I'll be happy to re-open.

[jduskes-mogiletech]

@mtrezza Thank you for the thorough response and for including an alternative solution. I appreciate it! 🙂