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

I don’t have a clue. But Microsoft is really good at this and they - more than any technology company - can withstand and likely prevail in lengthy legal battles; even the ones they shouldn’t win. Perhaps Airtable has been damaged by this, or perhaps there’s another explanation.

Engineers at Microsoft - and most tech R&D labs - are intentionally kept away from products and services on the competitive compass heading as they pursue new solutions. At a former employer where I led the R&D team, we required our team to have zero contact with competing solutions prior to and during design sessions. It was carefully documented that our teams were not influenced by other systems nor did they have any access to images, examples, or other external influences as they crafted a new product.

Anyone is allowed to innovate. The pathway chosen to get from zero to innovation may create risks and open the door to litigation.

More security holes in Airtable:

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

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

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

1 Like

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

1 Like

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