Is it secure to include the 'admin' api in the 'standard' trpc api?
I'm building a standard B2B app, which obviously has a trpc api.
I'm looking to add an admin area, which allows me to manage the B2B customers.
This will include tasks, like listing the customers' (confidential) data.
Obviously the api route itself is going to be protected by authentication, but I still obviously wouldn't want normal users,
to see which apis are exposed at which endpoint.
Are the 'admin routes' automatically tree-shook, or would they be visible to the customers?
And if they are, what would be the alternative?
8 Replies
None of the trpc backend code is available to the users by default the front end only imports the types
I know that, but still, having the admin api contract public may not be a good idea.
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
The API contract isn't public - the types are removed at compile time. You could obfuscate the JS but that won't help if your server is insecure and can leak data.
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
Yes, I'm aware of this method and this is also what I'm currently using, thanks 🙂
It's certain that interfaces etc. are removed BUT a lot of people also export their zod schemas etc. which certainly won't be removed.
Also, I'm concerned about the contract itself, in order for the frontend to be able to make calls to the backend, at least the admin routes, i.e. /api/v1/admin/user/create (or whatever path trpc creates),
need to be shared with the frontend, don't they?
Again, I'm NOT concerned with leaking any actual implementation or creating an api, which isn't authed. This is purely because I wouldn't want any 3rd parties to
know what kind of methods my backend provides to admin users.
I might be wrong on this, but Im almost 100% sure all tRPC calls go to the same endpoint. It's got it's own "router" which delegates procedures
AFAICT the most you can do is code-split your frontend routes so that code which calls admin routes is only loaded when you're in the authenticated-required part of your app, but even then people could figure it out
imo it's just unreasonable and non-helpful to think that any of your public-facing stuff is private. someone with enough time and determination can probably reverse engineer it