Help

Re: Making attachments private

Solved
Jump to Solution
1629 6
cancel
Showing results for 
Search instead for 
Did you mean: 
Team_Upp
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi everyone

I would like to know if anyone has a solution to make attachments in Airtable private. Looks like all attachments hosted in Airtable are public.

I have a Bubble App that is private and uses Airtable as a database, I wish that users outside the app or not logged couldn’t see images hosted in my Airtable base.

Thanks

1 Solution

Accepted Solutions
kuovonne
18 - Pluto
18 - Pluto

This is not possible. All Airtable attachments are public.

See Solution in Thread

10 Replies 10
kuovonne
18 - Pluto
18 - Pluto

This is not possible. All Airtable attachments are public.

Chuck_G
5 - Automation Enthusiast
5 - Automation Enthusiast

This is utterly ridiculous. Can’t believe that this is still a thing.

Let’s add a finer point to the term “public”.

“Public” is not the same as openly accessible. Airtable uses an unpredictable and undiscoverable URI for its attachments. Many SaaS systems use exactly this approach. While these resources are openly accessible by those who possess such unpredictable and undiscoverable URIs, they are secure to the extent that you take full responsibility for revealing them ONLY to trusted parties.

Airtable attachments cannot be added [via URL] to a database unless they are openly accessible. If you upload attachments from your desktop, you have [perhaps unintentionally] agreed to transform them from a local and largely inaccessible artefact into a cloud-based artefact with all risks associated with such action.

For sensitive information and where you intend to expose the unpredictable and undiscoverable URIs for these assets, this is not ideal. You need a different architecture or at least a different document management approach. But Airtable does this in ways that are identical to many other platforms and for sensitive data they (and other platforms) are creating risks. Security through obscurity is simply a bad idea.

But, they offer this because you want convenience. You’d prefer a system that magically makes it easy to curate, host, and render attachments and all without the headaches of authentication between two very different platforms - the database app and the CDN where information is hosted.

You have chosen this path because making copies of your information truth (the original documents) is easier than handling the security architecture required and the negative impact it will have on your users’ productivity.

Workaround

Stop using Airtable attachments as a document management system for sensitive information. Instead, store attachments by reference (i.e., links) to their original, secure, truthful locations. Force your users to re-authenticate when accessing attachments.

To be clear, Airtable - especially its attachment feature - was never intended to be used as a back-end database. I get it - we want to use the information for many objectives. But Airtable provides fair warning about using it as a broad CDN or database platform for other apps.

But even in your Bubble app, I struggle to understand how your non-Airtable users of a private app are able to learn the unpredictable and undiscoverable URIs for your attachments. Please explain - I just don’t understand how this breach is occurring.

Can you cite where Airtable provides this warning?

No, but I have seen it referenced by various Airtable employees here in the forum, like this one. And also many times in support tickets and I recall a few times in developer meetings, maybe even in a podcast somewhere.

But let’s be realistic - if Airtable were intended to be a CDN (whether attachments or data) the API would not be so constrained.

Thank you for the answer. I have referred to that particular community post myself several times. I was wondering if there was some notice that I had missed.

I do not think that what you cite counts as “providing fair warning” to users. Users have to dig too hard to find this info for me to consider it “fair warning”.

That said, Airtable must be aware that more and more people are using Airtable as a CDN and I have not seen more recent public comments discouraging the practice.

I never had the intention of creating a CDN. If I share a base with attachments with someone and then revoke access, maybe I don’t want them to somehow regain access to the base or any of its data.

You mention other SaaS applications that do this. Which ones? No idea why you would want to do this with a database. This is inline with the inability to easily obfuscate an API key in a shared base. Sometimes if it walks like a duck, it’s just a duck…

The ToS tiptoes around this issue in a few places. I took passages like this to be fair warning (to me anyway).

… use any robot, spider, scraper, data mining tool, data gathering or extraction tool, or any other automated means, to access, collect, copy or record Airtable;

… use Airtable in a manner that impacts: (i) the stability of our servers; (ii) the operation or performance of Airtable or any other user’s use of Airtable; or (iii) the behavior of other applications using Airtable;

… overload, flood, spam, or mail-bomb the Service; or otherwise use the Service in a manner that interferes with or creates an undue burden on the Service, including by sending unsolicited communications, promotions, advertisements, or spam;

Exposing attachment links in a way that causes any of these outcomes falls into a category of unexpected use of Airtable as a backend. Any reasonable person would read this and conclude you shouldn’t rely on document/attachment hosting for broad unnamed user access - it’s clearly not their intent.

I’m not suggesting you did. You are simply using their hosting capability to offer document access using their CDN.

Any trusted user who makes a copy of or bookmarks an openly hosted file is likely able to access that data after you’ve revoked permissions for that user. Try it in Google Drive - totally possible. Like Google, Airtable doesn’t go back and clean it up because you may have extended access to dozens of other legitimate users. If they delete openly accessible content for one, they delete it for all.

Google. Documents “attached” to a record are not part of your database; they’re captured and openly hosted separately in a CDN. If you don’t like that behavior, you need to not use that feature.

It would be nice if it didn’t work this way, but you must also consider the implications. Making attachments private will require only named users should have access. Perhaps that’s the feature you want, but it’s currently not supported that I know of.

I’m really not following this assertion. API keys are protected by the account; sharing a base does not openly share the API key (that I am aware). Give me a little more detail behind this claim.