Security issue, never initialize AuthorizationContext buildEnv with "prod" on SaaS and Self-hosted

[istarkov]

Now at open-source previews | dev-mode we use Canvas to show production builds. And it reads project data from DB directly. That's why we have buildEnv parameter in the AuthorizationContext https://github.com/webstudio-is/webstudio-designer/blob/124ab25174ea9faca2290f6377038541b5f4cd8b/packages/trpc-interface/src/context/context.server.ts#L24-L27

If it is set to prod we allow view access to the project. If it ok for development and previews it's a security hole for SaaS/Self-Hosted projects, as allows to get access to all the sources of a project.

Now it's used in 2 places.

1. To show production build on canvas at preview/development and not used at production (SaaS) from what I know https://github.com/webstudio-is/webstudio-designer/blob/124ab25174ea9faca2290f6377038541b5f4cd8b/apps/designer/app/routes/$.tsx#L55

2. To clone project into KV storage at SaaS https://github.com/webstudio-is/webstudio-designer/blob/124ab25174ea9faca2290f6377038541b5f4cd8b/apps/designer/app/routes/rest/project.$projectId.tsx#L22

2nd case is used at SaaS now, but used by our worker and the endpoint can be protected with API KEY as its interservice communication.

What to do

• To avoid this at SaaS/SelfHosting we need to have env variable disallowing set buildEnv = prod at /routes/$.tsx endpoint
• Protect /rest/project.$projectId.tsx endpoint with API_KEY as its interservice communication and should not be accessed directly at all

[istarkov]

Probably we need some naming for prod context creation, like createContextWithBuildEnvProd_DO_NOT_USE_IT

[istarkov]

Also, as of now we don't have a working publish at opensource, probably it can be only development issue. In that case buildEnv can be a synonim of NODE_ENV !== "production"

[rpominov]

Maybe something like createViewAnyProjectContext if that's what it actually does?