Web frameworks: hosting:channel:deploy creates broken preview channels when the SSR function lacks public invoker IAM

[dxdc]

[REQUIRED] Environment info

firebase-tools: 15.19.1

Platform: macOS

[REQUIRED] Test case

A minimal Next.js app deployed through the Hosting web frameworks integration
("source" + "frameworksBackend" in firebase.json), where the generated
SSR function's Cloud Run service is missing the public invoker IAM binding
(allUsers with roles/run.invoker).

Note: the app needs at least one page using next/image (or some other
reason for a backend, like a dynamic route). A fully static app never gets an
SSR function created, so there is nothing to reproduce against. Image
optimization is the easiest trigger and also what surfaces the failure on
otherwise prerendered pages.

We hit this state in production: the IAM policy on our ssr<site> service
was completely empty (just an etag). We don't know exactly how it got that
way. The repro below sidesteps that question by
removing the binding manually, which puts the service in the same state.

// firebase.json
{
  "hosting": {
    "source": ".",
    "frameworksBackend": { "region": "us-central1" }
  }
}

[REQUIRED] Steps to reproduce

1. npx create-next-app@latest repro and add a page that renders a
   statically imported image with next/image. This is required, otherwise
   no SSR function is created and the deploy is fully static.

2. firebase init hosting (web frameworks), then deploy live with
   firebase deploy --only hosting. Everything works.

3. Put the service in the broken state:

   gcloud run services remove-iam-policy-binding ssr<site> \
     --member=allUsers --role=roles/run.invoker --region us-central1

4. Deploy a preview channel:

   firebase hosting:channel:deploy preview --only <site>

   The command succeeds and prints the channel URL.

5. Open the channel URL and load a page with an image.

[REQUIRED] Expected behavior

The channel deploy should check that the rewrite target is publicly
invokable, and either re-assert the invoker binding (live frameworks deploys
do this when they redeploy the function) or fail loudly. Even a one-line
warning ("the ssr function is not publicly invokable, dynamic routes on this
channel will return 403") would save a lot of debugging time.

[REQUIRED] Actual behavior

The channel deploy reports success, but the channel is broken for all
dynamic content:

• Prerendered pages load fine, since they come from the Hosting CDN.

• Anything that has to invoke the SSR function, including /_next/image,
  returns Google's generic 403 page ("Error: Forbidden. Your client does not
  have permission to get URL ...") with nothing in the function logs. The
  request is rejected by IAM before the container runs, so there is no
  invocation to log. For example:

  https://<site>--preview-<hash>.web.app/_next/image?url=%2F_next%2Fstatic%2Fmedia%2F1.479aff49.jpg&w=1080&q=75
  -> 403 Forbidden
  https://<site>--preview-<hash>.web.app/about
  -> 200 (prerendered, served from CDN)
  

• Meanwhile the live channel looks healthy the whole time, because the
  popular _next/image URLs are already in the Hosting CDN cache. That makes
  this look like a preview-channel-specific problem and makes it very hard to
  search for.

What finally surfaced it:

$ gcloud run services get-iam-policy ssr<site> --region us-central1
etag: ACAB

That's an empty policy, no allUsers binding at all. Restoring it fixed every
channel immediately, no redeploy needed:

gcloud run services add-iam-policy-binding ssr<site> \
  --member=allUsers --role=roles/run.invoker --region us-central1

Running the channel deploy with --debug shows no IAM-related warning or
error anywhere, which is the core of the issue. Happy to attach the full
debug logs if that helps.

[aalej]

Thank you for the detailed report! I was able to reproduce the issue, when opening the channel it returns a 403 permission error, and the CLI does not give any information during deployment as to why this occurred.

I agree that having the CLI either automatically detect and re-assert the missing IAM binding, or at least surface an error/warning message would help improve the debugging experience.

I’ll raise this to our engineering team so that we can determine which approach would be the best to handle this scenario.

[aalej]

Quick update here, just relaying some information from discussing this with our engineering team.

1. The Firebase CLI should be able to check during deployment if there are missing permissions needed to publicly invoke the function and re-apply them, or fail loudly(error out)
   • We want to trust that if a user does change the permissions, we want to avoid overwriting the changes they made
2. If the CLI cannot automatically fix the permissions, show a clear warning message during deployment to make it easier to debug
   • We agree that showing a warning message should be good here as it will be helpful during debugging.

[dxdc]

@aalej thx for the follow up!

We want to trust that if a user does change the permissions, we want to avoid overwriting the changes they made

one note: the repro I provided does not mirror the way the problem surfaced. I never revoked any permissions on my end... just ran into it on preview channels and traced it down.

I have a feeling that the preview deploys cause this somehow, but haven't gone through all the internals to verify.

[leoortizz]

@aalej @dxdc Thank you for all the info. FYI I'm investigating it and planning to create a PR with a fix by end of week.

[leoortizz]

Opened #10690 for this.

Root cause: the SSR function is created with public invoker, but the update path never re-asserted it. So once the allUsers / run.invoker binding is removed for any reason, no later deploy restores it, and the channel deploy succeeds while every server-rendered request 403s.

@dxdc On your note about preview deploys causing it — I couldn't reproduce that. On 15.19.1, live + channel deploys don't touch the service's invoker policy, so the removal is likely coming from outside the CLI (most likely an org policy / security automation that strips allUsers from public Cloud Run services). The fix sidesteps the "why" by re-asserting the binding on every frameworks deploy.

The PR makes each frameworks deploy ensure the SSR service stays publicly invokable. It's additive (won't clobber any invoker members you've added) and, if something blocks the grant such as Domain Restricted Sharing, it logs a clear warning instead of silently shipping a broken channel.

Would you be able to try the PR build and confirm it resolves your case?

npm install -g github:firebase/firebase-tools#leoortizz_fix-frameworks-ssr-public-invoker

Then, against a project where you can reproduce the broken state:

1. firebase hosting:channel:deploy <channel>
2. Load a page that hits the SSR backend (e.g. a dynamic route or /_next/image) and confirm it returns 200 instead of 403.
3. gcloud run services get-iam-policy ssr<site> --region <region> should show the allUsers / roles/run.invoker binding restored.

If your org blocks allUsers, you should now get a warning during deploy pointing at the missing invoker rather than a silent failure. Either way, let me know what you see.

CC @aalej