I’m using Zoom Apps SDK 0.16.41 and trying to understand the SDK-to-client messaging boundary.
Which supported client environments use the WebKit bridge versus iframe/webClient messaging?
What validates that SDK responses and events come from the intended Zoom host, and what checks remain the app developer’s responsibility?
Is there current guidance on supported embedding contexts and frame restrictions?
I found related WebKit/CSP discussions but haven’t found documentation covering these specific questions. I mean the SDK’s internal communication with Zoom, rather than embedding another website inside my app.
Any documentation or guidance would be appreciated. Thank you!
Your content runs on your server and the appssdk connects to you as a js library. It does communication back to your worplace app for you and you can also API to zoom server for other data. To talk to Zoom you collect two security keys which you use to validate every interaction with Zoom API. most appssdk interactions are automatically allowed because you need to be in the zoom app to run them.
Otherwise you write an app. The use of Iframe and webclient is resitracted by your content security policy and the domains you whitelist on the marketplace app. Which you then would need to justify to zoom if you ever want to publish your app.
I hope that helps
John Drinkwater
Zoom Developer Champion
Not a Zoom Employee
Thanks for taking the time to respond. I understand the general distinction between the hosted app, SDK and Zoom APIs.
My question is specifically about the SDK’s internal bridge, rather than REST API authentication or an iframe that our app creates.
In SDK 0.16.41, we observed wildcard outbound messaging and no incoming origin/source check in the iframe/webClient branch. One local desktop observation used the WebKit bridge instead. We haven’t demonstrated exploitability or an authorization bypass.
Could you or someone from the Zoom Apps SDK team clarify:
Which supported environments use the iframe/webClient branch?
What ensures incoming responses/events in that branch come from the intended Zoom host?
What embedding restrictions or application-side checks are required?
If CSP or Marketplace domain allowlists enforce that boundary, a pointer explaining how they apply to these internal SDK messages would be especially helpful. Thanks!
The Zoom SDK talks directly to your Zoom Workplace app.
It does not exist ot work outside that environment;
It does not talk to Zoom directly.
It is a browser instance started and managed by the Workplace app.
The appssdk validates into that environment.
For the next level of verification, when you first load an app, it always starts on the defined app home page, and you can request a set of parameters to pass to you on launch.
If you run iframes or external browsers, they have no connection to the appssdk. You make your own security.
I can undermine the security by running a fake App SDK, but a well-written CSP stops those rogue scripts from being used.
And then, if you can demonstrate a vulnerability, I know Zoom would like to see it and work out mitigation, but also note that the App SDK is limited in scope and only affects a meeting and its controls. You cannot access any data outside a meeting using the App SDK or meeting.
Maybe come to the bi-weekly office hours if you want to discuss further.
Or submit a ticket.
I hope that helps
John Drinkwater
Zoom Developer Champion
Not a Zoom Employee
Thanks, John - I appreciate the explanation and the suggestion about office hours.
We’re trying to establish which SDK messaging paths apply to the client environments we plan to support, and whether any additional application-side controls are required before release. We haven’t demonstrated a vulnerability or authorization bypass.
The remaining question is regarding the iframe/webClient branch in SDK 0.16.41… which supported Zoom environments use it, and what ensures responses and events received through it come from the intended Zoom host? Our one local desktop observation used the WebKit bridge, so we don’t yet know whether the other branch is relevant to our deployment.
hi @Charlos ,
I really don’t like iframes. And I wouldn’t expect them to communicate within the appssdk; I would treat them like external browser calls. You can pass status to them, and I have used that to launch windows that might then talk to the Zoom API for more data, but the connection to the appssdk is lost.
I treat iframes pretty much the same way; I use Node.js and EJS files to serve my pages.
I don’t use WebKit and have no experience with that with Zoom. With so many JS systems out there, I had to choose one.
It is amusing to me that after a few years of coding many apps within the appssdk, its peculiar operation is still hard to explain.
I hope that helps
John Drinkwater
Zoom Developer Champion
Not a Zoom Employee