This is an important nuance worthy of a rant.
We often say “embed” but, we and mean “link”. And sometimes we say “link” but, we’re thinking “embed” because - well - embedding does require a URL, ergo, it’s a link. Where was I going with this? 
Oh yeah…
Another nuance is the notion that anything shared through Google Drive is “public” if it is not shared with a named user. This is not a precise interpretation of Drive’s behavior.
Public on the Web
By Google’s definition, Public on the web means publicly accessible and possibly discoverable through indirect means (such as a search engine that happens to find the document or folder that is also shared publicly). This should not be interpreted as a bad thing. There was a time - many years ago - when users lobbied for this feature because security was too rigid and unable to meet commonly expected use cases.
Anyone with the Link
Sharing via Anyone with the link is actually very secure. Document owners who enable this feature create no risks whatsoever UNTIL AND AT SUCH TIME the link is exposed. The context of the exposure sets the security level because these links are comprised of essentially GUIDs and almost impossible to guess.
When such a link is dropped into a Coda table, it is every bit as secure as the Coda document itself. Anyone with access to the Coda document is equally authenticated to view the document – and no more than the document specified by the link.
This is far different than dropping the link into an email and trusting the planet’s entire hacker community to ignore such links in SMTP packets. SMTP is not only not secure, it is the opposite - it is a broadcast of the link across the inter-webs. Do this at great risk.
When was the last time you heard about a security breach in Google Drive because the Anyone with Link method was used?
I can’t recall (myself), but I’m sure there are instances. But it is not a likely occurrence nor is it apparently a pervasive and debilitating issue for businesses and organizations, otherwise, this feature would probably be gone.
Embedding Documents
As @BenLee intimates, no platform can embed anything without open access to that which it needs to render inside another page (in this case, a Coda document). It’s simply not possible unless there exists authenticated soft tissue between Coda and the platform that possesses the content. Ben said “almost” every platform requires this; I think it’s simply not possible, so [in my opinion] every embed requires access without credentials.
This is a good example - a Google Data Studio Dashboard. It can render just fine in Coda if …
- The Data Studio dashboard is shared as Anyone with the link;
- All of the data sources utilized in the dashboard are also shared as Anyone with the link;
In a specific production instance, this dashboard would not be at risk any more than the Coda document rendering this dashboard as an embedded iFrame. In the example, I did it with the Embed formula, but the Embed feature works equally well.
Indeed, sharing documents is not ideal in the current feature set, but it’s not bad either. I’m sure there are some CSOs and IT people who simply do not allow such link sharing behavior, but that’s why Coda supports HTTP links. Any document - even documents that require credentials and a security context can be accessed from Coda. It’s not seamless (of course) and sometimes the friction is annoying. Perhaps a future Pack will make it friction-free.
Signed URLs
If none of these approaches satisfy your security requirements, you can add a security layer to your Coda UX that uses the API to temporarily open Anyone with Link access to a specific document (or folder) for a set period of time (like maybe five minutes). Once the time has expired, the document sharing reverts back to the named users. It’s no different than opening a server port for a specific process and then closing it after the process has finished.
This is not easy, nor is it cheap to build into your Coda apps, but it does allow you to sustain a very tight grip on your external documents while mimicking an open pathway for Coda app users.
Below is a system I built in Google Drive that generates 24-hour signed URLs for extractions of Zendesk tickets. This is secure because the links are set to Anyone with the Link and only named users (on the Zendesk platform) are able to use these signed URLs which themselves expire after 24 hours. The logic behind signed links is that –
- Any support data that’s more than 24 hours old should not be relied upon by anyone;
- Any possibility of a link shared through accidental or unintentional activities becomes worthless in a day or less.
In this design, attackable surfaces vanish and are re-established every 24 hours with completely different URLs.
