This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
This thread made me realize that we should probably have an option to PREVENT collaborators (particularly read-only collaborators) from being able to easily duplicate an entire base.
When we share read-only links to bases or views, we have that option that we can uncheck that says: “Allow viewers to copy the data in this base” or “Allow viewers to copy data out of this view”.
But it would be nice if we had that same feature for collaborators.
All blocks that depend on an API key to access an external service (such as the Google Maps block, the SendGrid email block, the Formstack Documents Block, the TypeForm block, etc.) expose your API key to anybody who uses your system, even a read-only user. With access to your API key, every user has unlimited access to your account with that external service. This can cause all sorts of seriously destructive problems, such as: people sending unauthorized emails that seem to be coming from YOU; theft of all of your data from these 3rd-party services; outrageously expensive fees (potentially in the thousands of dollars) when these other services charge “you“ for using their services; complete loss of all your data that is stored at these external services.
When sharing a block using the new block sharing feature (which is currently in beta), users have access to all data in all tables.
Uploaded attachments, even after being deleted from Airtable, are always visible to the general public by their URL. Any unauthorized users who have the URL can access the attachment. The worst part about this is that even if you completely delete the attachments from your system, they are still accessible to the general public. (More details in this thread.)
Hmmm, that’s very troublesome, and while I believe you, I would love to see how exactly a read-only user could find your API key. Steps with Screenshots perhaps? Feel free to DM me on that because we’re starting to get into the weeds by openly showing others how to gain access via API keys. I suppose no one including Airtable want to see the breach recipes openly documented.
Actually, while true, this is the sensationalized (Enquirer) version of this particular security threat, here’s why such claims should be measured:
Anyone with the Link
For a document to become an attachment in Airtable, the original source document must be at least “accessible to anyone with the link”. In that sense, Airtable is not doing anything you didn’t already decide to do to make the attachment possible. This, of course, doesn’t square with the many users who are compelled to make their documents public – if only for a brief time – in order to make copies in Airtable.
Indeed, most of my automated uploads of attachments also handle the security context in an automated fashion - i.e., set the source document to openly accessible, upload the attachment, reset the source document to its previous secure state. But as you point out, once it’s in the Airtable system, the horse is out of the barn - you’ve simply made a “public” copy of the original source document.
General Public
Most of us regard documents accessible by the general public as also openly findable. This is simply not the case with Airtable attachments because the URLs are sufficiently obscure (they are GUIDs) not unlike those employed by Microsoft, DropBox, Google Drive, and the enterprise-worthy Box platform.
Most CSOs will argue that security through obscurity is not a good strategy especially if the content is sensitive. But, to the best of my knowledge, none of the firms mentioned - Airtable included - have ever reported security breaches based on these obscure URLs. If this were a real and present threat, we probably would have heard about it long ago and these practices would have been disbanded.
Sustained CDN Document URLs
This is bad, but not for security reasons; rather, it’s a hygiene issue. Imagine you create an attachment and users bookmark the URL (which is in the Airtable CDN). Then you delete the record and provide an updated attachment. Now users are stuck on the older outdated version. Airtable should finish the play - clean up the mess as new replacements or deletions occur and ideally, create a redirect from the old URL to the replacement (if one exists).
The Remedy
The remedy is simple - either restrain yourself from making copies of the content (via attachments) or retain the original source documents in a secure context and simply link to them from Airtable. The latter is recommended and especially the case with sensitive information. Airtable actually provides a number of ways to provide secure and open document access without exposing the information to the “general public”.
Huh? It’s the exact same way that all users can get the API key. There’s nothing different about the process. Simply open the Blocks area, choose a block, click on the gear, and go to Settings. Yes — read only users can do this, too. The process is the same for all users.
True. It can only get into the hands of the general public after passing through the hands of a previous user. (But note that the previous user could have also been the general public. For example, if you opened up that attachment in a once-public gallery view. And now you want to delete that attachment from being seen.)
The real problem here is: (1) attachments are still visible after being deleted, and (2) attachments never have any layers of security protecting them.
I disagree with this, because just because you decided once upon a time a long time ago to share attachments with someone, doesn’t mean that that person should continue to have access to that attachment in the future if they leave the company — but especially if you delete the attachment from your system.
I would ask the person who created this thread as to how he feels about this. He is actually the one who brought this issue to my attention. I didn’t realize this was an issue until today.
You’re conflating two distinct actions and I want to make sure we put a finer point on this because I don’t perceive it as a security threat. I do agree (100% I might add) that it’s a hygiene issue that can create possible security calamity and other issues.
To this point …
… decided once upon a time a long time ago to share attachments with someone …
That’s not what I’m referring to. It’s the deliberate act of exposing a document (like in Google Drive) for the purpose of Airtable to create an attachment. This is what I’m referring to when I comment -
Airtable is not doing anything you didn’t already decide to do to make the attachment possible.
If you want documents uploaded as attachments, the requirement is that there is no security context on the source document. Ergo, you are overtly exposing the document and you know you are. There’s no circuitous act or hidden process that creates a security threat or unintentionally compromised environment.
Better stated - a trusted user. Users probably wouldn’t be users if they were untrustworthy.
Okay - that’s a big reach. :winking_face: Aren’t we all in the “general public”? If you’re using attachments in a table as an open public content space, you should have no expectation of (a) control or (b) security after the fact. The Interwebs will cache that content and the URL - however obscure it may be - will not matter.
Again, there are two distinct parts to this statement.
… doesn’t mean that that person should continue to have access to that attachment in the future if they leave the company
This is not Airtable’s axe to grind; talk to your CSO and IT people whose jobs exist for building and enforcing protocols that manage content with precision.
… but especially if you delete the attachment from your system.
Stated and I agree; Airtable’s must grind this axe. :winking_face:
We agree on the 2nd point, but I disagree with you on your 1st point. Look at how a secure database system like FileMaker WebDirect handles attachments securely. Attachments always have an extra layer of security on top of them — you can’t see the attachment in your web browser by typing in its attachment URL unless you have already passed through the authentication process.
The Maps block and SendGrid block both clearly state that the API key will be visible to all collaborators. While this is not ideal, at least it is stated clearly.
It looks like the Typeform and Formstack blocks were written by Typeform and Formstack, and not by Airtable directly.
For 3rd party blocks, showing API keys (and similar secrets) is a design decision for individual block authors. In the Custom Block contest, several custom blocks appear to expose the API key to all users, based on how the API key was visible in their videos.
In contrast, I wrote a custom block (Post to WordPress) that takes a username and password, and allows all collaborators to use those credentials without revealing the password to any of them.
However, Airtable could provide better guidance to block developers on how to deal with API keys and other secrets. I believe that Airtable is aware of this issue and working on it behind the scenes.
When you create the attachment in the Airtable user interface from the local file system, you don’t have to directly make the attachment public, not even briefly. If you ask users to submit attachments in a form, they might upload it from their local file system and also never directly make the attachment public.
Theoretically, if someone could get the url of the attachment, that person could then retrieve the attachment without having access to the base. For example, if the person did a screen share of running a script that showed the url for the attachment, then whoever saw the screen share could copy the url and view the attachment. But this is a really unlikely scenario. There are other much weaker links that need fixing before I’d worry about this specific use case.
As far as users bookmarking the URL of an attachment, Airtable has quietly stated somewhere on these forums that they don’t support being a CDN for attachments. Of course, someone might try to anyway without realizing that it is not supported or recommended.
Good point; there are some exceptions. In a cloud-centric world, the vast majority of attachments likely come from other cloud services and public access is required. And in a world of automated processes, the local file system is typically not part of the solution.
Yep, and to add to that, anyone with base access can get the URL of an attachment (display and right-click) and then share as they like or bookmark. We can’t really object to this behaviour because it is a trusted user who did this.
And yet, they use a CDN to host these “public” documents. :winking_face: How did they think people might use document URLs if not to access?
Indeed; they don’t have to do this, so once again, this is not really Airtable’s axe to grind. The blocks mentioned are apparently built by lazy developers who have little concern for security. Any developer creating a custom block knows (or should know) how to abstract security credentials away from the client.
In my view, it’s unreasonable to hold Airtable accountable for what third-party developers might do that’s unwise or risky. As such, many of these threats - while concerning - should not be characterized broadly as security holes in Airtable. Rather, the title should be…
Major Security Holes in Some 3rd Party Airtable Blocks
All collaborators, even read-only collaborators, are allowed to share the entire base with other people. Yes, they can only grant other people the same permissions that they currently have (or lower), but this is still a concern.
In general, it seems like Airtable always requires your collaborators to be highly-trusted people, which is not really the ideal way to design a database system — but it can work in small environments where everyone is fully trusting of everyone else.
A few of these security issues can be worked around with the new Airtable Sync feature, but this is my current list of the 9 security holes that I am personally aware of in Airtable:
All collaborators, even read-only collaborators, can duplicate an entire base into their own personal workspace.
All collaborators, even read-only collaborators, can export a CSV file of any table in a base.
All collaborators, even read-only collaborators, can select all of the records in an entire table and press command-C to copy all of the table’s data with one click.
All collaborators, even read-only collaborators, are allowed to share the entire base with other people. Yes, they can only grant other people the same permissions that they currently have (or lower), but this is still a concern.
All collaborators, even read-only collaborators, can always view 100% of the fields, records, and tables in an entire base.
All blocks that depend on an API key to access an external service (such as the Google Maps block, the SendGrid email block, the Formstack Documents Block, the TypeForm block, etc.) expose your API key to anybody who uses your system, even a read-only user. With access to your API key, every user has unlimited access to your account with that external service . This can cause all sorts of seriously destructive problems, such as: people sending unauthorized emails that seem to be coming from YOU; theft of all of your data from these 3rd-party services; outrageously expensive fees (potentially in the thousands of dollars) when these other services charge “you“ for using their services; complete loss of all your data that is stored at these external services.
When sharing a block using the new block sharing feature (which is currently in beta), users have access to all data in all tables.
Uploaded attachments are always publicly visible at their URL, with no additional security preventing them from being seen. If someone has the URL, they can view the attachment. No logins or authentication required.
Uploaded attachments, even after being deleted from Airtable, are always visible to the general public by their URL. Any unauthorized users who have the URL can access the attachment. The worst part about this is that even if you completely delete the attachments from your system, they are still accessible to the general public. (More details in this thread .)
The solution for numbers 1-7 is to use Stacker instead of Airtable as your user interface. Stacker also adds on tons of other amazing security features as well, such as only allowing people to see the records that you authorize them to see!
However, Stacker can not fix 8 & 9.
As a professional Airtable consultant and developer, Stacker is what many of business clients are using with Airtable.
