Inbound Traffic Path for Zoom In-App (Embedded WebView) vs. Firewall Inbound ACL Configuration

Zoom Apps
, ,
1

Zoom Apps Configuration

  • Frontend: React 19 / Zoom Apps SDK

  • Backend: Java 21 / Spring Boot 4.0

  • Web Server / Reverse Proxy: Nginx (Listening on port 443 with SSL)

  • Environment: On-premises corporate data center behind a strict firewall

Description We are currently managing a custom Zoom In-App called “ZiWorks” for our organization. Recently, we experienced server sluggishness, and our network infrastructure team proposed restricting our corporate firewall’s Inbound ACL to allow ONLY official Zoom Outbound IP ranges, while blocking all other public IPs to prevent users from bypassing the Zoom Client and accessing our URL directly via standard web browsers (Chrome/Edge).

However, I understand that the Zoom Client operates as an embedded WebView running locally on the user’s PC. This implies that the HTTP/HTTPS requests originate from the user’s actual public IP, not from Zoom’s servers.

To resolve our internal technical debate and establish correct security guidelines, I would like to clarify:

  1. Does the incoming HTTP traffic hitting our web server from the Zoom In-App originate from the user’s actual public IP or Zoom’s official IP ranges?

  2. If we restrict our firewall to allow ONLY official Zoom IP ranges, will it completely block our users from accessing the Zoom In-App service?

  3. What is the recommended best practice to prevent users from bypassing the Zoom Client? Should we validate the X-Zoom-App-Context header in Spring Boot, or use User-Agent filtering in Nginx?

Error? No explicit error message yet, but we are facing a structural conflict regarding firewall implementation that might lead to a complete service outage.

Troubleshooting Routes We analyzed our Zoom Marketplace Admin Dashboard (Webhooks & Server-to-Server API logs) and confirmed that current logs (sendMessage, /v2/users/*) are strictly outbound requests initiated from our server to Zoom, which does not provide evidence for inbound user routing.

How To Reproduce N/A (Architecture and security configuration inquiry)

2

Hi @irlink_hong ,

OK, let me try and keep this simple.

  1. The app is running locally wihin a browser in Zoom Marketplace App.
    So just conside that running in a browser

  2. It is going to talk to your web server where you hosted your code
    just like a browser hosted app would do so.

  3. It can talk to the Zoom Workplace app locally with the appssdk.
    which is does as within the browser.

  4. You may load the appssdk from its online home in zoom, there may be other libraides where you get code from. All these should be easy to see because they have to be defined in the marketplace app definition

  5. It will talk to Zoom.us for any api calls to send commands and recive data back.

So determining the URL and domain names is straight forward.
Converting them to all the IP of the servers and CDNs could then follow

Creating access for Zoom its self is probably the bigger list of servers to define. that list is also available.

hope that helps

John