MAJOR SECURITY HOLE IN AIRTABLE: Any collaborator (even read-only collaborators) can steal 100% of your data with one click

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. :wink: 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. :wink:

1 Like

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. :wink: 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

Security issue #7, as brought up in this thread:

  1. 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:

  1. All collaborators, even read-only collaborators, can duplicate an entire base into their own personal workspace.

  2. All collaborators, even read-only collaborators, can export a CSV file of any table in a base.

  3. 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.

  4. 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.

  5. All collaborators, even read-only collaborators, can always view 100% of the fields, records, and tables in an entire base.

  6. 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.

  7. When sharing a block using the new block sharing feature (which is currently in beta), users have access to all data in all tables.

  8. 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.

  9. 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.

1 Like

#7 & #8

I consider these as a feature very important to me. If this wasn’t available I would possibly stop using AirTable (or use it way less than I do). The ability to download images by their URL without logging in is necessary if those images are downloaded by a 3rd party service or 3rd party app. I use AirTable as go-to application to manage my entire multichannel eCommerce activities. AirTable provides me the CSV which then is loaded to Amazon, eBay, Mercari, Craigslist, Poshmark, Etsy, Kijiji, Gumtree, and many many other market places. One of great features of AirTable is the ability to easily save and store images (my product images). When I create the CSV out of my base, the CSV contains hot-links to images. With that, I am able to load images to all these marketplaces directly from AirTable servers. If AirTable required a login, it would not allow the 3rd party service and apps to download the images. I don’t have expertise to program my own apps to use AirTable API and the services and apps I use do not support integration with AirTable directly or with Zapier and similar (All Zapier can do is to download a ZIP file of all images stored in the field, that wouldn’t help because it would require manual work around).

I agree downloading images is a security problem, but the problem is not that the images shouldn’t be downloadable by the publicly accessible URL. The issue is that a collaborator or perhaps shared user is able to create export of the CSV file (or any format) showing the public image links.

IMHO preventing the non-owner user from getting hands on the public version of the document/image links would sufficiently protect against misuse. However, if that’s not going to satisfy the safety police, then perhaps there should be a setting where I allow 3rd party access to stored documents and images without need of API or logging in.

Yes, that is a very handy feature — to be able to distribute the URL to people.

(Although note that most — probably all? — 3rd party services are using Airtable’s API without you being aware of it. So you don’t need to have a technical understanding of Airtable’s API in order to benefit from it.)

However, comparing Airtable to a service like Dropbox, Dropbox lets people specify between “public” files and “private” files. Airtable, by default, makes all files “public” — and there’s no option to change that. I would be totally okay if Airtable gave users the option to make their files “public” or “private”. That would be a good solution to this issue.

For example, while having all the files be public might suit your needs, that’s not okay for my clients who are lawyers or other professionals that need their documents to be secure. Several of my clients have actually MOVED AWAY FROM Airtable because of this flaw, and they moved to the highly-secure FileMaker platform instead. So I have personal experience with businesses abandoning Airtable because of this.

When professionals with confidential data sign up for a service like Airtable, they often mistakenly & erroneously THINK that their documents are secure in Airtable, when they’re actually accessible to the entire world — once the URL is revealed to someone.

Are you okay with this flaw as well? This is a huge one. If you delete an attachment from Airtable, it continues to be accessible for AT LEAST A YEAR AFTER IT HAS BEEN DELETED from the URL, and possibly longer than that. There is no circumstances whatsoever where a deleted attachment should still be allowed to be viewed.

@Jason @Raghav_Sethi @Taylor_Savage

Agreed.

No I am totally not OK with that. I forgot to respond to point 8. The headline says both 7&8 but I didn’t touch point 8. Completely agreed, this 8 issue is completely childish flaw that AirTable has. No excuses here.

Added:

Just to add to my comments for Point 7. I wound’t mind to make whole AirTable public, as long as the links (both to database and to documents stored within the fields) are only known to me and anybody with the link to document won’t be able to access to the entire tables.

So simply setting the tables and the documents (links) either private or public would resolve the issue with the document links. It would satisfy both needs.

A few years ago I worked in an IT company. They had an inexpensive file sharing software because the owner was concerned about not putting anything in the cloud. Because of the flaws in the file sharing software, the public links to internal documents still work today and all company database 1000’s of internal clients documents can still be downloaded today after many years. I didn’t tell them about the flaw even after I left the company, because I don’t care, because they owed me and other people money and didn’t treat people well. But if somebody was going to figure that out, it would expose the company to millions of dollars in damages from litigations.

So I can completely understand your situation with your clients. I don’t want to come across as selfish. It’s just that I found AriTable to be a sweet solution to my needs and spent 100’s of ours setting it up and works well. So if AirTable doesn’t provide an option to have publicly accessible links to documents, it would break it for me.

I wouldn’t cross my fingers for how AirTable is going to deal with this issue. They seem to resolve things but they seem to either overcook or undercook the meal… “Either have full access fully exposed to web or no access at all and can’t really download the complete image of the database easily.” That’s the situation today.

1 Like

Just wanted to interject a reality check on these comments.

Suggesting that uploaded attachments are always “visible” to the general public is wildly inaccurate. Public visibility and conditional accessibility are two very different concepts and you are conflating them in a somewhat sensational way that is not fact-based.

Attachments URLs are like signed URLs with an indefinite termination point. They are not visible to the public – or ANYONE for that matter – unless the links themselves are openly published in a manner that the public is aware of them. Furthermore, they cannot be found through crawling techniques nor are they easily discovered through hacking techniques.

The Facts

Assuming the document ID distribution is uniform and unpredictable (which it appears both requirements are achieved with Airtable attachments), here’s the math:

  • 44 characters long
  • Uppercase, lowercase, digits and underscore =
    26 + 26 + 10 + 1 = 63 character alphabet

Therefore…

The total possible combinations: 6344 – ergo… 263 bits ⇐ 44 * log2(63)

And we know that brute-force deciphering of a 263-bit key in any reasonable amount of time (lifetime of the universe) is well beyond what the laws of physics will allow, no matter how advanced and magical and “quantum” the computers may become.

This may seem to be a cocky assertion, but it comes from the fact that the sun simply doesn’t put out enough energy in such a timeframe to count that high. See page 157 of Schneier’s Applied Cryptography for the details, or look at this answer here where some really bright people have summarized the math, or this answer where links quoted the entire section from Schneier’s book.

This is precisely why (a) Google follows exactly this security pattern for making links openly accessible without experiencing rampant attacks or enduring the wrath of public relations concerning breaches associated with this improbable threat pattern. In fact – and the math and experience over more than 1.5 decades – prove with great certainty there is no “there” there.

Please consider adopting a more nuanced level of verbiage when asserting “public visibility” and “public accessibility”. For the “public” to access any attachments in Airtable they must first be invited into the secure realm of unhackable URL awareness. This is no different than DropBox, AWS, Google, Box, Microsoft, or the thousands of SaaS services that utilize this approach for billions of secure documents.

Overall Security Model

There is plenty to complain about with regard to usability and user experience. Indeed, we all want Airtable to be as secure as possible and as flexible as needed when it comes to sharing and collaboration. That pressure and many of the weaknesses called out in this thread are well deserved. But, we need to indict patterns that are truly posing threats; #8 and #9 do not fall into this class and they shouldn’t even make the top 100.

1 Like

You’re completely missing my point. Nobody is talking about someone randomly stumbling upon the URL or a hacker figuring out the URL. You keep trying to make it about that point, but that’s not the point I’ve ever tried to make. Not even once.

To clarify my point, so there is absolutely no confusion:

Any collaborator, even a read-only collaborator, has access to ALL of the URL’s in the entire base. Once a collaborator has the URLs, the URLs are known. If they maliciously distribute any of the URLs, there is no way to remove those attachments from circulation.

Even if you delete the attachment from Airtable, the attachments live on (possibly forever, but for at least a year) at their URLs.

There is no way to retract that URL, there is no way to stop that document from being viewed at that URL.

Furthermore, there is no ability to shield that URL from being viewed by only authorized users. Not even a simple authentication process.

And this is for every URL in the entire base.

A system that depends on all collaborators being 100% trustworthy at all times is not a fully-secure system.

And no, Google and DropBox absolutely DO NOT work in this way. They do not make ANY of your files publicly accessible. You have to choose who you want to share each file/folder with: nobody, certain people, or the entire world. And then, you can STOP SHARING at any time or CHANGE SHARING at any time.

Hey, there’s nobody that loves Airtable more than me, and 80% of my business comes from professional Airtable development, consulting, and training. But we need to call a spade a spade: robust security is not on Airtable’s list of strengths. So we should not give them credit where credit isn’t due. They are already complacent enough about fixing problems in the product. So no, Airtable doesn’t even come close to the security protections of what DropBox or Google offer, so I wouldn’t compare the two.

Can you share where you got this information? Have you tested this?

This support page states that data will be automatically deleted at the end of the retention period, which might be shorter than a year depending on the plan.

The page also states that data can be deleted sooner by contacting them.

I believe that access to the unpublished URL’s is a minor security risk considering that collaborators have access to the actual attachments themselves. If someone wants to do something nefarious with an attachment, they can do it with the actual document.

As for accidental leaks, Airtable has stated that they are not to be used as a CDN for attachments, so people shouldn’t be sharing those urls to begin with.

I agree that there are security issues with Airtable. But no system is 100% secure and users need to balance security with the need for people to get stuff done and with budgets.

That’s a nice find there!

Although it would be impractical to contact Airtable Support every time a lawyer deleted a file from one of his attachment fields. But that’s still a great find on that page! :slight_smile:

True, and this is a good point.

However, the attachments are stored as URL’s in the system, so the nefariousness would come from exporting the table as a CSV file, and then having the full list of URLs always accessible for a year — even after the collaborator is fired from the company. (Normally, any sort of nefarious employee can be STOPPED from doing a ton of harm as soon as they are fired.)

After 30 years of database development, I’ve seen all sorts of crazy things happen at businesses with untrustworthy employees: embezzling, stealing data, sharing proprietary data, etc. But typically, much of the damage can be stopped once the employee gets fired, or their access to the links is cut off, or whatever.

This isn’t really a budgetary thing — free & very inexpensive platforms have robust security built into them: Dropbox, Google Drive, FileMaker, etc.

I’m just trying to help Airtable here — I receive 5-10 new client inquiries every week for Airtable development work, and I can specifically tell them what drives businesses away from using the product, and what keeps businesses using the product. This issue has been one that has come up several times with companies that have sensitive data & can’t trust their employees.

I hate losing business as much as Airtable probably hates losing business!

I was specifically referring to the Pro Plan 1-year retention. I’ve actually tested as far back as 10 months, and my deleted attachments are still visible at their original URL’s. My guess is that this is because of the 1-year snapshot revision history. This is actually awesome that we can go back as far as we can in time! I actually love this! :slight_smile: These attachments should simply be protected.

Not a deal-breaker for most businesses, but it HAS been a deal-breaker for several of the businesses who have contacted me.

I lose business when people walk away from Airtable, and I don’t like that. Although if they migrate to FM, I gain the business, but still — I’d love to keep people in Airtable, because it’s such a fun & easy & great product! :slight_smile:

And yet, that was my relatively deeply informed impression that I got from the tone of this thread. :wink: I think the words with regard to #8 and #9 are not well-nuanced to provide the average reader with this clarity.

Ah, but my friend - you are so deeply invested in this that are you are failing to recognize a few aspects of these worries that @kuovonne elegantly called out.

Malicious distribution of content - whether by reference (URLs) or by value (actual documents) is not in the scope of any platform’s security model. Rather, they only have the responsibility of making it difficult for nefarious actors to do harm. They have no responsibility to prevent bad actors from doing harm beyond a reasonable degree. The architecture and the experiential evidence suggests Airtable has been both reasonable and relatively sound for sustaining secure operational outcomes and we can all agree that no platform is impervious to this type of security threat.

Could they provide better security and user experience? Certainly - no debate! Categorizing the items in my commentary as part of a MAJOR SECURITY HOLE is a leap that seems unreasonable.

Indeed, disabling URLs to deleted documents should be instant and at least as fast as the platform was able to take your FULLY PUBLIC URL FOM ANOTHER PLATFORM and make a copy of it.

I think it’s reasonable to expect the system loses the attachment’s URL in a timely fashion, but let’s be very honest about the facts - the documents that exist as attachments (contributed via URL) must ALL be public for such documents to exist in Airtable. Users are taking these steps with full awareness not unlike when they install a new app to their computer, or when they proactively share links to “anyone with the link”.

A more nuanced issue is uploading documents from the desktop - this exposes the files perhaps in a way where average users are not fully informed about the security implications. But, even in this case, uploading a document is not a security breach because the URL it creates is not predictable, findable, or indexable on the public Interwebs. As such, it is simply a security implication - it is neither a security threat, compromise, or breach.

It’s my opinion that attachment URLs which are long-sustained is an operational issue, not a security breach; another reason they have no basis for landing on your short list of major security holes.

Not entirely true. My experience shows that if you create a document in Google Drive, then expose the [secure] URL it in an email, Google will reset the permissions to “anyone with the link” in the background unless - and only unless - the indicated recipient is a Google Account-backed email address in which case, it shares it to that person, and only that person. Ideally, Airtable would work similarly, but Airtable doesn’t own any email systems, so it’s in no a position to assert such automation.

The definition of “collaborator” is a trusted person and even these trusted persons would be hard-pressed to locate the URL of an attachment in Airtable. As @kuovonne said, the easiest pathway for a trusted user to go rogue with your content is to make a copy of, download, and share, etc, etc, etc. Even if they could locate the URL easily, they are not likely to share it because they would probably assume the unauthorised recipient would get an access challenge. Nefarious actors simply don’t attempt to create data breaches by sharing deep links. :wink:

Here’s an attachment in Airtable - a picture of my wife. (yes, she’s a solid 9.5 and I’m like a 2.8 on a good day; I cannot explain this)

Seemingly (and based on your commentary) one might assume that you can copy the URL for this attachment, delete the record, and successfully access URL, right? For most users, this is what they will take away from your assertions. So let’s follow this example and delete the record, but first, let’s just try to see her smiling face from another browser which has no security context with my Airtable account. As hoped, the URL that Airtable gave me when viewing the attachment is secure.

Now, let’s delete the record and try it again - this time from the browser that DOES have a security context with my Airtable account. Hmm, the link logs me into the table where the image used to be but provides no deep link access to the original content. That seems reasonable.

The only way to make a case for deep links exposed beyond the deletion point is to recognize that you must deal directly with the attachments CDN and most users have little understanding of this nor are they able to even discover the underlying links unless they are logged in as trusted users. This is the actual underlying CDN URL in case anyone was wondering - it remains accessible after the record deletion. Perhaps you should document the steps required to acquire these URLs.

In my view, what Airtable has built with regard to attachment content seems reasonable, seems fairly secure and requires a lot of what-if’s to create a hypothetical breach.

My understanding is that there are multiple fairly easy ways of obtaining the underlying CDN attachment URLs

  • Export the table to a CSV file
  • Copy/paste the table or cell value to another app, such as Excel
  • Use the attachment field in a formula field
  • Access the cell value from any of the APIs (okay, this one isn’t quite a easy)

BTW, your wife is beautiful.

Hahaha! Bill, that’s a solid 7.5 difference!! How did you accomplish this amazing feat!?!? :stuck_out_tongue_winking_eye: I have several friends who would love to learn this trick from you! :wink:

My answer to your overarching question is this, and I apologize if I haven’t made this clear earlier:

  • All collaborators, even read-only collaborators, can instantly download an entire table as a CSV file. But — drum roll, please — all of those dl.airtable.com links are a part of the CSV file. Those are the underlying URL’s that have no protection. So, with one click of the mouse button, any collaborator (even a read-only collaborator) has access to ALL the underlying unprotected URL’s in the entire table.

And THIS is the crux of the problem. It’s actually tied into the other security issues, which is that read-only collaborators can instantly download an entire table (or duplicate an entire base) with one click.

In essence, Stacker solves the majority of these security issues, because collaborators can only grab ONE underlying URL at a time.

None of this is probably that big of a deal for MOST people. I just don’t like losing business due to security issues like this. :stuck_out_tongue: And I know that Airtable probably doesn’t like losing business, either. But when I get calls from law firms that ask me “How safe our are attachments in Airtable?”, I have to go down this whole rabbit hole with them and explain these potential issues.

p.s. Regarding Google, good point about how the link actually IS public when choosing that one option that they provide to people. Many people don’t realize that when they choose that option.

Indeed. I handle this a bit differently. I simply say -

It is not unlike the exposure most businesses currently endure with G-Suite.

Two quick side-bar comments…

  1. If security is critical, attachments are not where you want to place sensitive documents.
  2. Any business attempting to blend sensitive documents into their data should consider hosting them by reference (URL), not value (copies of the sensitive documents).

As to #2 - a secure document in Google Drive will require authentication even when published in a fully open database in Airtable. Making copies of any sensitive information should always be guided by business policy which for most firms, it is frowned upon.

As to #1, Airtable made attachments very flexible because document management is a difficult science; they built what we (generally) asked them to build.

We cannot blame Airtable for these constraints or unintended uses of the product. At some point, users must take responsibility because Airtable has provided a reasoned and relatively secure collection of protective measures to make safe applications.

Correct. They don’t, just as Airtable users generally don’t understand the underlying loosely-configured mechanics. And given this, when was the last time Google was hauled into CNBC to explain why sensitive Drive documents were breached? 2006 to date and not a single instance. Same for Airtable - 2015 to date; not a single instance.

Thank you. Like I said - I cannot explain it. 38+yrs of marriage and so far she’s exhibited no interest in fleeing. From time-to-time she has mentioned that sentiment could change.

1 Like

I can confirm that Stacker is indeed absolutely incredible and user permissions is one of the main reasons I use it.

You noted the cost, but for many enterprise applications it’s cheaper since it doesn’t charge per user.

So my setup is a small team of database administrators using Airtable, while the rest of my clients use Stacker.

1 Like