Tool allows publishing an existing site from the wrong project!

[kevmoo]

[REQUIRED] Environment info

firebase-tools: 15.15.0

Platform: macOS

[REQUIRED] Test case

A firebase.json file with a hardcoded site property under hosting:

{
  "hosting": {
    "site": "my-shared-site",
    "public": "public",
    "rewrites": []
  }
}

[REQUIRED] Steps to reproduce

1. Create two distinct Firebase projects, let's call them project-a and project-b.
2. In project-a, create a hosting site named my-shared-site.
3. Set up the firebase.json as shown in the test case with site: "my-shared-site".
4. Run firebase deploy --project project-a. (This succeeds and deploys to my-shared-site).
5. Now, switch to the other project and run firebase deploy --project project-b.

[REQUIRED] Expected behavior

The CLI should fail the deployment on step 5 or at least show a warning stating that the site my-shared-site does not belong to the active project project-b.

[REQUIRED] Actual behavior

The deployment in step 5 succeeds without any error or warning.

Because the Firebase Hosting API uses the wildcard project path projects/-/sites/my-shared-site/versions, the backend resolves the site solely by its ID (my-shared-site). Since the authenticated user has permissions on both projects, the backend allows the deployment, and the files are actually uploaded to Project A's site, even though the user explicitly targeted Project B in the command.

This leads to accidental production overwrites when developers switch project contexts but forget that they hardcoded a site ID in firebase.json.

[aalej]

Thanks for the thorough report and for sharing your feedback! I agree with you here, we should check if a site belongs to the corresponding project before proceeding with deployments to avoid accidental overwrites. I will route to our engineering team and mark this as reproducible.

[kevmoo]

Who did the thingy not close this @joehan ? Was your commit message not include the fix bits?