Is it possible to KEEP SOMEONE OUT of an Airtable base?

Topic Labels: Collaboration
Jump to Solution
6925 30
Showing results for 
Search instead for 
Did you mean: 

Earlier today I responded to a question from a new user here, explaining how she could hide a field on a locked view and keep the field hidden from non-creator users by making it visible only on a personal view configured by the creator. I then had to add that this is security theater (I think that’s the phrase we use these days) because in truth, any user with editor or commenter privileges can simply duplicate the locked view as a new personal view, which they can then configure to their heart’s content–including making visible the fields that the base creator wanted hidden.

After posting my response, I began to feel uneasy, so I looked into this a little more deeply than I have before, and I’m a bit disappointed by what I’ve found. I’m praying someone here tells me that I didn’t look deep enough–that there are better answers to my concerns. But at the moment it appears that base creators have only a very limited, casual sort of control over who gets into their bases.



Consider this scenario. I develop a base for a law firm. I’m the creator, my contact at the law firm is the Owner, and the half dozen users in the firm are editors, because, well, because they need to be able to edit the data in the base. And let’s say that the base contains info that the law firm regards as sensitive: perhaps info about their clients, or data for a lawsuit they are working on; etc.

Now, one of the employees at the law firm is let go. Naturally, the firm’s manager (the base Owner) emails me and I remove that person’s sharing privileges. But the person calls somebody still working at the office and that person (whether maliciously or stupidly) shares the base with the ex-employee. The ex-employee is back in, thanks to a decision by somebody who perhaps should not have the authority to make that decision.

Or somebody on the other side of the lawsuit sweet talks one of the firm’s employees and they agree (again, doesn’t matter whether this is malice or mistake) to share the base with somebody who shouldn’t be allowed to view what’s in the base at all. And if these security breaches are committed by somebody with editor privileges, the person who should not have access but now does will actually be able to do things like edit records, delete records, etc.

I use the example of a law firm because most of my development work has been for law firms. But I don’t think I’ve ever developed a base for any client where the client didn’t care about controlling access.

And what if the security breach is committed by somebody with only read-only privileges? Well, even somebody with read-only privileges has the ability to share the base. Okay, fine, maybe I’m willing to live with that. The problem is, if I’m not happy about that, even as base creator there’s not a thing I can do about it.

Wow, just wow.


Living in the real world

Now systems like FileMaker, AppMaker, Caspio, Servoy and nearly all SQL app front ends, give developers the ability to restrict access to the databases to specific users and only those users. (I don’t understand the security models for Coda or SmartSheet well enough to comment on them.) If developers wish to authorize admin users to control access, too, they can do that. But who gets into the solution is always restricted to somebody who is, in theory at least, a responsible user. With Airtable on the other hand, granting access to the base is the prerogative of any and all users, regardless of their privileges.

Of course, I’m aware that users are always the biggest weakness in any security system. There’s always the chance that an authorized user might share his or her credentials with somebody who’s NOT supposed to have access. But doing so would be hard to do by accident. In those other systems there’s no “Share” button that invites the user to give some stranger access to the base. Since my users all log in using their email addresses, anybody who logs in using somebody else’s email address will be aware that they’re doing something fraudulent (even if they don’t realize how serious it could be). And in at least some of those systems, it’s possible to do various other things to minimize the risk of unauthorized access: require two-factor authentication to an authorized user’s mobile phone or email perhaps; and/or track IP address from which user is connecting and even restrict users on that basis.


My three wishes

I know that Airtable is designed to be like the friendly and convenient corner store, not like an distribution center that uses metal detectors and employs armed security guards. I love that about Airtable.

Still, at a minimum, I wish that any (or all) of the following were possible:

  • Creator should have option to hide the share button for all non-creator users
  • If creators aren’t given ability to decide who can share/not share the base, then read-only users absolutely should NOT have this ability. When I think “read only” I don’t think “read and make a copy for all your friends”.
  • Finally, there should be a privileges level just below Editors called perhaps “End Users”. End Users should be allowed to edit data in records but NOT edit locked views, that is, for End Users, the “create private view” button would disappear.

I gather that some greater degree of control MIGHT be achievable if I gave access to bases strictly on a view-by-view basis using links that are embedded in a web page, but for me, that dramatically limits Airtable’s appeal and potential usefulness.

Somebody is going to read this and think, “My my, he’s not a very trusting person!” Guilty as charged, your honor.

Please tell me what I’m missing!


1 Solution

Accepted Solutions
Airtable Alumni (Retired)

Hi all! Wanted to follow up and close the loop on this thread. I’m excited to share that Airtable now supports workspace sharing restrictions so that Enterprise admins and workspace owners and Pro workspace owners can restrict the addition of new collaborators to specific workspaces or bases. Enterprise admins and workspace owners can also toggle a setting to prevent future share link creation on a given workspace. Thank you so much for the transparent feedback on this topic, we really appreciate it!

See Solution in Thread

30 Replies 30

Have you actually tested this assertion? I don’t believe that it is possible for a non-creator to share access to a base.

Indeed; access control in tools and systems that are in their mid-life stages are always likely to have advanced access control. Airtable is still an adolescent and especially the case with regard to access control and security.

Commentary and opinion from here down -

I suspect no one has commented on this because it requires a deep level of reading and thought just to get to the point where the reader could begin to discuss the merits and provide any sort of advice.

I’ll make it simple for ya’ - stick with FileMaker; it is 22 years old (140 Internet years), you know it, the access control is ideal for law firms, and It has a very good UI/UX - significantly better than Airtable. I am also a certified FileMaker developer from a previous life. :winking_face:

I jettisoned all clients and all work in FileMaker in 2012 because it wasn’t modernizing with open web standards. And I didn’t fill the database void left by FileMaker with Airtable - to the contrary. It’s a long story how I got here but that will soon come to light in a podcast I recorded with BuiltOnAir.

I digress - pretty much everything you say here is fully expected of good database management systems, and I think the latest advanced security features (in beta) cover these for the most part.

No one’s responding because they don’t have 2 hours to do your comments justice. :winking_face:

10 - Mercury
10 - Mercury

There’s nothing wrong with the conclusion that Airtable might not be the best application for storing sensitive data. But it’d be nice to see Airtable mature into a platform that could better handle this type of use case. Redefining permissions is definitely a good route if the new definitions are well thought out.

Granular control over permissions would be more flexible, especially for super users/developers. But without proper hierarchical design, there’s a risk of creating key functionality that intimidates new users. Thinking of applications (like Excel) that sometimes wander towards functionality that isn’t super user friendly.

Well, sorry, but I don’t believe you are correct. :frowning:

Yes, I have tested it, repeatedly. And I just tested it once again. I used four different email accounts that I have (my work account, my personal domain account, a Gmail account and an account).

  1. The work account is the creator.
  2. From the work account, shared base with my personal domain account as Editor.
  3. From there shared with my Gmail account as read-only.
  4. From Gmail read-only account, shared with my account (at read-only level).

Note that not only can a read-only level account share the base with someone else, this lowliest level of privilege can also do things like email a record to, well, anybody.

It’s not inconceivable that my tests were faulty, but I was as careful as I could think to be. I used 4 different browsers to do this – in each new browser I made sure that I was NOT logged into Airtable and when accepting each new invite, I created a new test account in that browser. And to make extra-sure, I then shared the base with a fellow developer at the read-only level and asked him to try to share it with himself at one of his other email addresses. He was able to do so.

I’m pretty surprised.


Good advice and I thank you for trying to get me to see reason. But if I wanted to make things easy on myself I wouldn’t be here. :slightly_smiling_face:



Thanks for responding.

I don’t think I’m asking for the moon here. I already have the moon and then some in FileMaker, where I can, as developer, control pretty much every aspect of a user’s access to every specific item in a solution. If I want to create a privilege set that will prevent certain users from accessing the solution from any IP address except the one I specify, I can do that. If I want to prevent users from editing the records of accounts that have the letter “Q” in them or from editing anything on a Tuesday, I can do that too. All that control was fascinating when I first learned it. But for the most part it’s overkill.

But I DO need to know that I am the only person who has the ability to share the base. The three wishes I described – which I have also now posted as a feature request – would get me a long way towards happiness and towards making Airtable a useful tool for some of my clients.

And if Airtable’s developers are hard at work preparing to give us more control over access and permissions, well, that would be fantastic. Airtable team: More all nighters, please!! :slightly_smiling_face:


That seems like a reasonable test methodology. If this can be validated then Airtable should probably run similar tests and advise us accordingly. I have a sense that a few folks in this community like @cor, @Kasra, and @kuovonne can probably guide us a bit regarding your test results.

I was able to successfully reproduce @WilliamPorterTech’s results.

Three users, each on a different physical device.

  1. UserA, the creator of the base, shared the base with UserB, with read-only permissions.

  2. UserB duplicated the base and now had two copies of the base: one with read-only permissions, and one with owner permissions.

  3. UserB shared both copies of the base with UserC. The version with read-only permissions was shareable only with read-only permissions, and the version with owner permissions was shareable with creator permissions.

UserC ended up with two copies of the base: one with read-only permissions, and one with creator permissions.

Ultimately there were two total bases with identical data:

  • The original base has UserA with owner permissions and UserB & UserC with read-only permissions.
  • The copy of the base has UserB with owner permissions and UserC with creator permissions. UserA has no knowledge of the existence of this copy of the base.

Continuing my tests …

UserA was never notified that the base was shared or duplicated. The only way UserA could tell that UserC was added to the original base was by viewing the list of collaborators (either by viewing who the base was shared with or when picking a collaborator in a collaborator field).

UserB was able to unshare the original base from UserC. UserC no longer showed up in the list of collaborators.

The only evidence I found of UserB’s sharing and unsharing of the bases was in UserC’s email. There were no notifications sent to UserA or UserB.

It would be quite possible for UserB to share the original base with UserC, then minutes later decide it was a mistake and unshare the base, leaving no evidence in UserB’s email or in the base itself. However, in the few minutes when UserC had access to the base, UserC could duplicate the base. UserC never even had to check email. The shared base showed up automatically in Airtable for UserC.

Okay, so this is going to sound odd, but I think this is by design despite the fact that it may be a poor (or incomplete) collaboration design.

Anyone who has the right to view a base apparently has the implicit ability to make a personal copy of that base and ultimately re-distribute that data as they desire. This action violates the spirit of the original owner’s intent because it makes it really easy for the data to move outside the original creator’s sphere of control.

The act of re-distributing the data (created by first copying) is different from re-sharing the original data because any changes to the re-distributed base does not impact the original creator’s base.

To answer the question that @WilliamPorterTech posited in this thread, the answer is yes. Sharing with read-only permissions seems to keep a read-only user from violating the ability to modify the original base or to transform the ability to grant others the ability to modify the original base. The only issue made evident in these tests by @kuovonne demonstrate that a read-only user is able to make a copy of the data and to then engage in nefarious actions to re-distribute that data.

But isn’t this the same approach more mature services like Google Docs allow notwithstanding the additional feature - allow read, but no ability to make a copy?

Even Google will not be able to prevent a copy/paste of a document shared without copy authorization. Ergo… no data is adequately defended from nefarious or untrustworthy members of a shared group.

Perhaps I haven’t considered all factors, but it appears you can keep someone out of a base. What you cannot do is prevent nefarious actors from using your content when you share your content. This is very different from claiming there is a deep security flaw.

Tell me what I’m missing.

In my tests, Airtable acted as I expected it to. I was not trying to expose a security flaw. Rather, I was trying to re-create @WilliamPorterTech’s results.

As soon as you allow someone to view data, it is possible for that person to copy that data. If nothing else, the user can take a photo of the data.

However, from a security point of view, being able to copy small amounts of data at a time (a screen’s worth) is very different from being able to do bulk operations (copying an entire base). The former is a trickle; the latter is a flood. A dam can continue to function (or at least there is hope of patching it) if there are only a few trickles. However, a large flood can overwhelm the dam and cause widespread problems downstream.

Other aspects of society recognize that copying small amounts of data is different from wholesale copying. For example, one of the factors in determining if a copy of a copyrighted work falls under “fair use” is the amount of that is copied. Quoting a sentence from a novel is fair use and legal. Reprinting the entire novel is not. Copying a signature move in choreography can be a nod of recognition that needs no pre-approval; re-staging the entire dance without permission would be wrong.

Other software recognizes that it is important to put up barriers to copying, even when it isn’t possible to completely prevent it. For example, I can create a Word document and set permissions to prevent printing.

More granular permissions has been a long-standing request. The beta that Bill mentioned does a lot regarding more granular permissions, but there are still many use cases that are not covered.

In any case, there is no substitute for user training and granting access only to people you trust.

Thanks for these extra tests, @kuovonne. You took the experiment farther than I had.

I have no problem with anybody sharing their base with the entire world, if that’s what they want to do. But it ought to be an option that can be disabled.

Any platform, like Airtable, that doesn’t give the owner of the data the ability to control who shares and who doesn’t, is, in my view, a platform that shouldn’t pretend to be useful to businesses or, well, anybody who doesn’t want his organization’s privacy policy to be summed up as “We count on our uses not to do anything we wouldn’t want them to do.”


Bill, forgive me but I think you’re missing the point here. The fact that the read-only or commenter user can’t, say, define a new field is, well, not unimportant, but it’s the bun and not the burger. The burger is the data. When we were burglarized twenty years ago, the thief took one of my wife’s jewelry boxes. She was upset about the box, which had sentimental value to her. But she was a lot more upset about the jewelry.


Google does it right

I am not sure I follow you here.

Are you saying data given to Google is just as easily compromised as data given to Airtable? That’s just not right. When I, as owner of a Google sheet, wish to share the sheet with a collaborator,

  • I am given the option to prevent editors from changing access and adding new people.
  • I’m also given the choice *to disable options to download, print, and copy for commenters and viewers."
  • It’s worth noting also that, if I have a G Suite account and the person with whom I want to share the base is outside my organization, Google will warn me about that, too. (I’m not sure but I think this too can be simply disabled by the admin for the G Suite account.)

That strikes me as just about right and I wish Airtable did it that way: editors would not be able to share bases without owner permission (if I as creator or owner chose to disable editor sharing). And commenters and viewers would, if I wanted, be prevented from copying, printing or exporting data.

Or are you simply pointing out the obvious, that even with Google’s tighter security-and-privacy controls, editors can get away with murder, or at least grievous bodily harm? I suspect that’s what you’re saying, because of your use of the word “adequately”. But I think that’s asking “adequately” to work harder than it wants to.

No multiuser database is or can be absolutely secure, because the single biggest problem in computer security is always users. And the only solution to that problem is to get rid of users. As Benjamin Franklin a couple of centuries ago, “Three people can keep a secret–if two of them are dead.” Spot on.

But while killing all the users has a nice ring to it, I’m pretty sure it would be wrong and maybe even illegal, and in any case impractical. So absolute security is impossible and I’m certainly not looking for it in Airtable. Yes, yes, Google can’t even prevent a commenter or viewer from taking a screenshot. And yes, editors more or less by definition need to have the ability to edit, copy, etc., the data. That’s where we are these days and, well, we all have to live with that. We can never absolutely prevent private data from being shared inappropriately.

But we do not have to make it easy.


Security vs Privacy (vs Access)

Business owners and office managers, in general, view privacy and security as near synonyms: security is what keeps their private data private.

Aside from that theoretical issue, I still think you are mistaken about my ability to “keep someone out”. If I share a base with kuovonne as a commenter, and I tell him “For heaven’s sake please don’t share it with Bill French,” I am sure kuovonne is an honest and honorable and trustworthy person, but there’s no way I can prevent him from sharing it with you anyway, and I don’t just mean, I can’t prevent him from sharing his Airtable credentials with you. I mean he can actually click the share button and add your name to the list of “authorized” users. Google would make him ask for my permission first, but Airtable doesn’t. And Google would allow me to say that both kuovonne and anybody he shares with won’t be able to export, copy or print the data, but Airtable doesn’t.

And if kuvonne did share the base with you, as kuovonne pointed out, I wouldn’t even get an email informing me that this had happened.

So, no, I can’t keep someone–anybody, really–out of my Airtable bases, once I make the first share with somebody else.


I remain excited about Airtable. I am continuing to use it for my own purposes, largely so I can continue to learn it. I’m hoping that the improved security and privileges features will become available soon and if they address my concerns I will be delighted to come back here and delete my posts or add a followup saying “These complaints are no longer valid.”

But in the meantime, any base creator or owner who shares data with someone else, needs to understand that the someone else can–without asking for permission–very easily turn around and share the entire base with anybody else in the world.



No. I didn’t say that the ease with which each solution’s read-only shares can be copied were equal. But both Google and Airtable share a similar threat - at least a few pathways for users to abscond with data and do as they wish with it.

@kuovonne’s tests verified this was indeed the case with Airtable as well.

Indeed, Google offers a few more options to make you feel better about security and it might dissuade some would-be ner’do’wells from getting the data. But make no mistake - Google is not much different from Airtable and these “security features” are far from secure. Here’s an example -

I shared a sheet from another company that I own to my personal Gmail account. I set the tightest security possible - read-only, no copies, etc. By all accounts the sheet itself seems secure and impervious to copying and repurposing the data.


But, in 4 minutes and just 10 lines of code that a couple kids could write blindfolded, I had all the data.

Clearly, this is not as easy as getting read-only data from Airtable with a simple base copy, but certainly Google’s approach could not be characterized as “secure” either.

It’s important to parse these words more carefully. Your statement is not really being truthful. I [personally] would say that:

… a read-only user may make a copy of your data and republish it through any means they so desire including in a new Airtable base and in an entirely different workspace if they so chose.

The original base from which the data is copied is not being shared; rather, a copy of the data is being republished. This requires a proactive rejection of the spirit in which the data was initially shared. The actions by a “trusted” individual are no different than my example above; they must seek to thwart the security options prescribed - ergo, they must engage in an intentional bad act to publish a completely different version of the base at the time the copy was made by the bad actor.

This is not the “entire base” (as you characterize it), nor is it being republished in a way that has any impact whatsoever on the original data which is precisely what I demonstrated with a private, read-only Google sheet.


If you think that a screenshot is a high-friction defence from copying Airtable data, consider this simple example…


This AI app will read any image, any size, and provide you with a CSV or JSON file in seconds. And there are many tools for grabbing very long screens from web browsers.


I’m responding right now just to this part of your response to me because this is absolutely central to my complaint. I don’t think @kuovonne’s tests verified that Airtable can do this. I do not see how they could have, because it’s not possible.

I beg you or somebody to prove that I’m wrong. How do I, as creator, share a base with an editor and prevent the editor from re-sharing the base with somebody else? I just tested this again. I do not see any option to prevent re-sharing. Where is this option?

For comparison, here’s where it is in Google Sheets:


True, it’s slightly hidden underneath an Advanced disclosure triangle, but it’s right there if you look for it. Where is the corresponding option in Airtable?



My statement was both truthful and correct. I just tested this again, for what?–the fourth or fifth time. I took a different base, shared it with another email account I have as editor. In different browser, opened that base in account #2, then changed account #2’s privileges to read only. That you can do that in itself is weird or at least interesting: a non-creator user can actually downgrade his or her own privileges! Anyway, now, from read-only account #2, I shared the base with a third email account, also as read-only (the only option, of course). Then in a third browser, I opened the base with the third account. Remember, #2 and #3 are now both read-only. And #3 is somebody totally unknown to #1, the creator.

My recollection is that kuovonne confirmed all of this. But wait, there’s more!

Then I went back to the “original” base (in my creator account) and made some edits. I added a table. I created some records, etc. I went back to the base in acct #3, and, yep, the new table was there, the new records were there.

So in what way is that a copy and not the original?


The only way in which what account 3 is accessing, is not the “entire base”, is that the read-only #2 and #3 accounts can’t edit anything.

But as I just showed, #2 and #3 are accessing the original base and can see edits and changes to it. And #2 and #3 can access and copy data in every view including locked and personal views. Copying is a simple matter of typing Cntl-A and Cntl-C. No need to write any code.


I feel like I’m being a major bore about this. But this is really important, no? And if wish, I’m happy to do a test with you or anybody else. Share a base with me. Give me read only privileges. Make changes to the base–new table, new records, edits. Create a locked and/or personal view. Let me know when you’re doing making changes. I’ll copy all the data in the base and send it back to you.


You’re moving the goal posts. :winking_face:

And what if the security breach is committed by somebody with only read-only privileges? Well, even somebody with read-only privileges has the ability to share the base.

Central to your [original] complaint - can you keep someone out of Airtable - and the suggestion that a read-only user was able to share a base with third-parties has been proven to not be the case as confirmed by @kuovonne.

This question - while certainly in a similar security vein - is different from your original premise.

I made it clear early on that Airtable’s security model was both poorly implemented and adolescent. And despite this fact, read-only shares were indeed as good as Google’s read-only shares. And while it’s true that Airtable makes it far easier for highly trusted editors to expose your data without the original creator knowing it, “highly trusted editors” should be highly trusted people.

In Airtable [today] if you give someone editor capability, it is not largely different than giving them the ownership keys. I suspect that will change and possibly already has in the new beta features being tested.

What would be the point of doing this [again]? @kuovonne made this obvious in tests and anyone can circumvent this exact scenario in Airtable OR Google as I already demonstrated.

Permission definitions

The definition of “keep someone out” of a base does is not clear.

  • William seems more focused on reading and copying data from the original base.
  • Bill seems more focused on editing the data in the original base.

My tests show that someone can share a base at any permission level equal to or lower than the original permission level. A user with read-only access to a base can share that read-only access to a third party. The third party will be able to read and copy all the data in the base, and will continue to be able to read and copy any new data that is added to the original base. A user with editor access to abase can share that editor access with a third party.

Thus, there is no way to prevent someone from spreading their own access level to a third party.

Sharing permissions on different device types

Editing permissions on a mobile device (phone/tablet) is not as robust as on a computer. On a mobile device, I cannot unshare a base or downgrade permissions. I can do both on a computer.

Some unexpected testing results

In the various scenarios that I tested, Airtable permissions did not work as expected in one case.

  1. UserA is the creator/owner of a base. UserB has editor permissions.
  2. UserB shares the base with UserC, granting editor permissions.

As far as I can tell, both UserB and UserC should have identical permissions, but they do not. UserB can both downgrade UserC’s permissions and unshare UserC, as I expected. However, UserC cannot downgrade UserB nor unshare with UserB. Neither UserB nor UserC are workspace collaborators; they are only base collaborators.

Additional thoughts

All of my tests have occurred with free workspaces. Paid plans might have more granular permissions. Pro and Enterprise workspaces have the ability to limit sharing via private links (no sign-in) by domain or password. I do not know if these limits extend to sharing with collaborators. I have no plans to do tests in a paid workspace, as I do not want to pay for more collaborators.

Airtable permissions for collaborators do not seem to differentiate between manual actions and bulk actions. If a collaborator can view a field on the screen, that person can read that field for every record in that view. If a collaborator can edit a field manually, that person can edit that field, for every record, including batch processing via either the Standard API (50 records/second) or Scripting API (undocumented rate limit, but my tests at 200 records/second were successful). The Airtable interface does introduce some friction when performing bulk actions in the user interface (e.g. asking before doing fills or pastes that would affect large numbers of cells.)

The permissions beta does offer more granularity in permissions, but it does not appear to cover the situations described in this thread.

Airtable is capable of pushing out changes without user action or user notification.

According to my tests, a read-only user of a base could share that read-only access to the original base with a third-party. This is in addition to being able to copy the base.

If true, this is not right. But I thought you examined this and concluded that it worked as expected.

CORRECTION - I think this is by (Airtable’s) design, but it’s not right. However, even if Airtable removed this ability to re-share, it would still not be ideal.

It works as I expected, not necessarily as someone else expected. I expected that all users would be able to share the base at the same or lower level of permissions as their own. Thus, a read-only user would be able to share read-only access, which is what happened and what I reported.