Yes, 110%. It doesn’t make sense to me why Airtable wouldn’t include this simple feature when it’s clearly already available with link sharing. All they need to do is add the same checkmark functionality either per-user or make it default that only the ‘creator’ role has permission to CREATE a copy :winking_face:

I feel like this would be a big for any organization that has any form of sensitive information or proprietary nature to how they do business. Their current solution is “copy and paste” any data you want someone to have access too but not have access to copying all your data… yikes.

I suppose an alternative solution could be… If they had a way to ‘mirror data from a view or table to a separate special-use base’ that kept up with all the updates and didn’t require constant upkeep, I suppose that would work too… but at that point, why not just link bases :winking_face: to me, there is no simpler (obvious) solution then just to implement the feature above. Creators should be able to create, period.

Hopefully, they get this implemented sooner than later because as a marketing agency we can’t afford for someone to just walk away with our ‘agency in a box’ we’re trying to build. So it makes our lives very clunky currently having to avoid that and I’m even considering moving away from air table to a custom solution if the pain continues to increase as we grow, because it’s lacking this one simple feature!! So hopefully they fix it sometime soon, so we can continue to remain a loving user

Totally agree with you. This is actually a really big security hole in Airtable, and in my personal opinion, it should be addressed ASAP.

The proprietary data of a business is often its most important core asset. The fact that Airtable makes 100% of this data instantly 100% copyable in its full 100% entirety to even the lowest level of employees (read-only employees) is one of the biggest security risks, security holes, and of the Airtable platform.

But the fact that Airtable allows any level of collaborator to instantly duplicate THE ENTIRE COMPANY’S DATA IN ONE CLICK is just as misguided as letting the lowest level employee be able to do it.

As a business owner, none of my employees should be able to run off with all of my company’s data with one click of one button.

This security hole could potentially make Airtable a non-starter in organizations that are more than a solopreneur — or more than a mom & pop organization run by LITERALLY a husband & wife who implicitly trust each other (and who do not foresee divorce in their future).

Another example to build upon your marketing example above: could you imagine a gym where one of the personal trainers could grab all of the gym’s customers with one click?

There is no other database platform that makes it possible or this easy for ANY USER OF THE SYSTEM (including read-only users) to copy the ENTIRE SYSTEM with one click of a button.

And, of course, giving users the ability to select all the records in an entire table with one click, and then being able to press command-c to copy all of those records (immediately prior to pasting those records into an external text editor) is also a deal-breaker. It’s actually the exact same problem as duplicating an entire base. Copying entire records — particularly copying all the records in an entire base — is never allowed (by default) in other database systems.

So this security hole applies to 3 areas of the product, in order of importance:

1. Duplicating an entire base.


2. Exporting a CSV file of an entire table.


3. Selecting an entire record — or all of the records — in an entire table and being able to press command-C to copy all of the table’s data with one click. (And then, instantly being able to paste all of that data into an external text editor.)

All 3 of these options are available to all collaborators, including read-only collaborators.

I already predict that somebody might try to make this point:

“Well, if someone can SEE all of your data, then they already have access to all of your data anyways!”

Well, yes, that’s “technically“ true… and it would be amazing someday to have record-level permissions built into Airtable.

But there is a night-and-day difference between one-click duplication of an entire company’s data vs. forcing someone to scroll through 5,000 records and individually taking screenshots of each record… or forcing someone to manually scroll through 5,000 records to manually copy data out of each field one field at a time — and then having them manually repeat that process for every record in every table.

The task of stealing all of your company’s data should be as difficult & unwieldy as possible, which acts as a deterrent.

The “partial” good news here is that this security hole can be solved by having your users interact with Airtable entirely through Stacker… but that’s a pricey solution and your users will end up losing the overwhelming majority of the features of Airtable (blocks, interacting with Airtable’s user interface, all the different types of views, instantly updating data in real time, etc.). Stacker is really best-suited as a customer portal for customers to see their own customer data, not for internal employees to interact with an entire database.

@Jason @Kasra @Aron @Adam_Minich @Katherine_Duh @VictoriaPlummer How can I best escalate this security issue to the internal engineering team at Airtable?

Again, this security hole applies to 3 different areas of the product:

1. Duplicating an entire base.


2. Exporting a CSV file of an entire table.


3. Selecting an entire record — or all of the records — in an entire table and being able to press command-C to copy all of the table’s data with one click.

All 3 of these options are available to all collaborators at all times, including read-only collaborators.

Thanks!

Scott

p.s. This large security risk also sort of ties into the much smaller security risk here, which is that collaborators can share the base with anyone, without the other collaborators being alerted to it.

I love and support your response! Thank you for helping voice this concern. Hopefully that solve the security risk sooner than later

Disappointingly, I just had an email conversation with Airtable Support (whom I do not believe is very good, because they seem to have less of an understanding of the product than most of the people in this community), and they couldn’t even understand the problem that I was describing to them. I even linked them to this thread.

They were like, “Just make your collaborators read-only”, and I was like “No, you’re not understanding the problem — the problem still crops up with read-only collaborators. ANY collaborator can steal all of the data from a system by just duplicating the base, exporting the base, or copying/pasting all the records. One-click theft of an entire system."

And they were like, “Well, we offer the ability to turn off creation of new records for users." And I was like, “No, you’re not understanding.”

:man_facepalming:t2: :man_shrugging:t2: :man_facepalming:t2: :man_shrugging:t2:

I’m not sure if my frustration could get much higher, but I’m sure it probably could. Lol!

I’m typically blocked by the community for using metaphors and I can think of three Dennis-Miller-isms that would be ideal right about now.

In any case… who thinks this is a good idea?

I believe the creator of a base copied by a read-only user has no idea that a 3rd party has full access to the content. I think this is possible today despite the recent security updates, and I think it’s really problematic.

That’s a fantastic illustration!!

It will be completely 100% lost on Airtable Support.

Perhaps. But management? That’s a different story. Let’s hope they boost this up to clear and present danger.

The argument that many will make is that in any trusted network of people, content can be copied and shared without authority and without notification. That’s a fine argument for a chart image you just shared with another person in your company in confidence. It was shared with a read-only intent and that trusted person decided to make it known to another person whom the creator had no intention of ever sharing.

It’s a violation of trust concerning a digital artefact; happens all the time and no one – not even with the vast resources of Microsoft – can prevent this from happening.

This is an entire database shared without authorization in a few clicks. It ostensibly provides the thief with a fully gassed truck, the keys, a lift-gate, and a prepaid FastPass for the HOV lane.

Airtable … this is not your best work. You have a duty to make this as hard as possible. And even when it approaches the difficulty of a daylight break-in at Fort Knox, you have to notify base creators of the breach in real-time.

Upvote. Huge security hole.

Right, I’ve already addressed this argument above:

Again, this security hole applies to 3 different areas of the product:

1. Duplicating an entire base.


2. Exporting a CSV file of an entire table.


3. Selecting an entire record — or all of the records — in an entire table and being able to press command-C to copy all of the table’s data with one click.

All 3 of these things can be done instantly, with one click of the mouse button, and can be done by read-only collaborators.

This makes Airtable a complete non-starter for most businesses. Airtable might not take security seriously, but security risks are a huge concern to most of the businesses that I work for.

The suggestions in this thread are a feel-better bandaid, but don’t actually plug the hole that worries you. And, I wouldn’t call this a security flaw. This is the way read-only access works. If someone can access data, they can copy it — that’s true in any database system. Some systems might add some hoops to jump through so it isn’t as easy to do, but at the end of the day it’s always possible for a determined viewer.

(Go to one of those shared no-copy-allowed views, right click somewhere and choose “Save As” to download your own, local copy of the entire page… in just two clicks. There is absolutely no way Airtable can stop anyone from doing that, or a number of other technical tricks.)

Never let someone view data when copying that data is an unacceptable risk.

A far better solution would be granting individual collaborators access to some, but not all bases/tables/views. The best way to do this now is to use multiple workspaces, and keep sensitive data in one with only “trusted” collaborators.

I’d love to see a “collaborator groups” feature within a workspace, so we could choose between allowing all collaborators to access a base, or only allowing group A/B/C to do so… even better if read/edit permissions could be assigned similarly. That would open up a lot more use cases for Airtable.

Go to one of those shared no-copy-allowed views, right click somewhere and choose “Save As” to download your own, local copy of the entire page… in just two clicks

The read-only shared link pages aren’t really a part of this security problem, because those read-only shared link pages can already be restricted to only showing certain records. And doing “Save As” from those read-only shared link pages doesn’t save any data. Although you can “Print” those pages and save as PDF. But again, those pages can already be restricted to certain records.

If someone can access data, they can copy it — that’s true in any database system.

Yes, this is technically true. But as I mentioned above, there is a huge difference between:

1. Instant theft of an entire company’s data. (With 3 different ways of performing this instant theft.)
   
   vs.


2. Forcing someone to scroll through 5,000 records and individually taking screenshots of each record… or forcing someone to manually scroll through 5,000 records to manually copy data out of each field one field at a time — and then having them manually repeat that process for every record in every table.

Deterring theft is the best way to prevent the majority of thefts. You don’t want to hang the key on the doorknob. Right now, they’re hanging the key on the doorknob.

So while all the other solutions you outlined are absolutely the correct long-term approach to solving this problem, the dangling key needs to be removed first.

Then, we can start getting into the other solutions that you outlined. The other solutions that you outlined are absolutely necessary for any secure database system, and would be very much welcomed in Airtable, but — let’s remove the key hanging on the doorknob first!

Then, after the dangling key is gone, we can start adding in all of the excellent security measures that you are talking about!

But yes, what you suggested as the solution is how all other database systems have solved this problem. We need Airtable to take this same approach.

No one can argue this point; as @Andron_Ocean indicates, it’s the vast nature of systems that put data in front of eyeballs and along side a variety of copy tools that create risks. But I think it’s also wise to ponder the subtle difference between copying, replicating, and replication awareness.

Let’s all agree that copying should be set aside in this conversation because there are so many ways to make copies that we’d be wasting energy and time debating the undebatable. Copying is a risk that is virtually unavoidable.

Replicating

Almost without exception, the vast majority - perhaps north of 90% - of the database systems available as modern SaaS solutions make it almost impossible to replicate a database or to do so without someone knowing about it. This is not the case with Airtable - they are (unfortunately) in the top 90+ percentile of this category; clearly not something you want to be good at.

Replication Awareness

If you’re going to make it really easy for read-only users to swipe a fully functioning copy of a database app, you might want to at least let the creator/administrator of that database know that it has been replicated and access automatically extended to that original creator.

Far Worse than Copy Risks

Replication is in a vastly different class from copying. The ability to make a “copy” of a fully functioning base represents an outcome unlike any definition or notion of simply copying the data. It is fundamentally different because it comes pre-installed with a completely new security context that the replicator can use to inflict harm, cause misleading conclusions, modify, and misrepresent as an authoritative version of the original base.

Replicated Airtable bases are virtually indiscernible replicas that can be used for nefarious purposes both inside and external to an organization without so much as more than a few clicks. It is no different than printing counterfeit currency without the need for paper, ink, or design templates.

The absolutely amazing thing is that Stacker has fixed every single security issue that is broken in Airtable. Every single issue. All fixed with Stacker.

In my opinion, Stacker is actually what people are hoping to get when they sign up for Airtable… until they realize that they don’t get ANY of it with Airtable. None of it available in Airtable.

If I ran Airtable, I would purchase the entire Stacker team & Stacker product today… and I would integrate it natively into Airtable by tomorrow morning.

Personally, I find it scary to collaborate in Airtable. Airtable should really take these securities stuff seriously. They should also add the ability to make specific tables, custom fields, and even specific records private. ClickUp is not a fully-featured database like Airtable but the permission features there are pretty good. Airtable should really copy its permission features.

Yes. Luckily, we have all of these permissions built into Stacker, but it’s a VERY expensive add-on. It’s a minimum of $120 per month, and that’s if you pay for a year in advance.

Indeed.

Um, yeah - notwithstanding the massive legal risks of doing so.

As consumers, we tend to assume that everything anyone else has implemented is available for the taking. This is simply not the case and companies that fail to innovate along the pathway to meeting specific customer requirements often get sideswiped with costly litigation. We should be careful what we encourage any vendor to do. And this is why acquisitions sometimes occur the likes of which @ScottWorld has suggested.

I’m not suggesting Airtable is constrained by any specific IP high-ground to improve its security and on the flip side, Airtable has likely been a target of flagrant intellectual property infringement. Does anyone see the resemblance?

Yes, I have checked Stacker and the permissions are very good. As you have mentioned, it’s very expensive and we don’t get all the good things that Airtable provides. Hope Airtable purchase them right away and implement the features right into Airtable.

Yeah, what I meant was be inspired by it.

Is Microsoft even allowed to do this? They totally copied everything and are not shy about it as well.

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:

4. 
   

   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.

   
   


5. 
   

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

   
   


6. 
   

   Uploaded attachments, even after being deleted from Airtable, are always visible to the general public by their URL. Any unauthorized users who have the URL can access the attachment. The worst part about this is that even if you completely delete the attachments from your system, they are still accessible to the general public. (More details in this thread.)

   
   

Hmmm, that’s very troublesome, and while I believe you, I would love to see how exactly a read-only user could find your API key. Steps with Screenshots perhaps? Feel free to DM me on that because we’re starting to get into the weeds by openly showing others how to gain access via API keys. I suppose no one including Airtable want to see the breach recipes openly documented.

Actually, while true, this is the sensationalized (Enquirer) version of this particular security threat, here’s why such claims should be measured:

Anyone with the Link

For a document to become an attachment in Airtable, the original source document must be at least “accessible to anyone with the link”. In that sense, Airtable is not doing anything you didn’t already decide to do to make the attachment possible. This, of course, doesn’t square with the many users who are compelled to make their documents public – if only for a brief time – in order to make copies in Airtable.

Indeed, most of my automated uploads of attachments also handle the security context in an automated fashion - i.e., set the source document to openly accessible, upload the attachment, reset the source document to its previous secure state. But as you point out, once it’s in the Airtable system, the horse is out of the barn - you’ve simply made a “public” copy of the original source document.

General Public

Most of us regard documents accessible by the general public as also openly findable. This is simply not the case with Airtable attachments because the URLs are sufficiently obscure (they are GUIDs) not unlike those employed by Microsoft, DropBox, Google Drive, and the enterprise-worthy Box platform.

Most CSOs will argue that security through obscurity is not a good strategy especially if the content is sensitive. But, to the best of my knowledge, none of the firms mentioned - Airtable included - have ever reported security breaches based on these obscure URLs. If this were a real and present threat, we probably would have heard about it long ago and these practices would have been disbanded.

Sustained CDN Document URLs

This is bad, but not for security reasons; rather, it’s a hygiene issue. Imagine you create an attachment and users bookmark the URL (which is in the Airtable CDN). Then you delete the record and provide an updated attachment. Now users are stuck on the older outdated version. Airtable should finish the play - clean up the mess as new replacements or deletions occur and ideally, create a redirect from the old URL to the replacement (if one exists).

The Remedy

The remedy is simple - either restrain yourself from making copies of the content (via attachments) or retain the original source documents in a secure context and simply link to them from Airtable. The latter is recommended and especially the case with sensitive information. Airtable actually provides a number of ways to provide secure and open document access without exposing the information to the “general public”.

Huh? It’s the exact same way that all users can get the API key. There’s nothing different about the process. Simply open the Blocks area, choose a block, click on the gear, and go to Settings. Yes — read only users can do this, too. The process is the same for all users.

True. It can only get into the hands of the general public after passing through the hands of a previous user. (But note that the previous user could have also been the general public. For example, if you opened up that attachment in a once-public gallery view. And now you want to delete that attachment from being seen.)

The real problem here is: (1) attachments are still visible after being deleted, and (2) attachments never have any layers of security protecting them.

I disagree with this, because just because you decided once upon a time a long time ago to share attachments with someone, doesn’t mean that that person should continue to have access to that attachment in the future if they leave the company — but especially if you delete the attachment from your system.

I would ask the person who created this thread as to how he feels about this. He is actually the one who brought this issue to my attention. I didn’t realize this was an issue until today.

You’re conflating two distinct actions and I want to make sure we put a finer point on this because I don’t perceive it as a security threat. I do agree (100% I might add) that it’s a hygiene issue that can create possible security calamity and other issues.

To this point …

… decided once upon a time a long time ago to share attachments with someone …

That’s not what I’m referring to. It’s the deliberate act of exposing a document (like in Google Drive) for the purpose of Airtable to create an attachment. This is what I’m referring to when I comment -

Airtable is not doing anything you didn’t already decide to do to make the attachment possible.

If you want documents uploaded as attachments, the requirement is that there is no security context on the source document. Ergo, you are overtly exposing the document and you know you are. There’s no circuitous act or hidden process that creates a security threat or unintentionally compromised environment.

Better stated - a trusted user. Users probably wouldn’t be users if they were untrustworthy.

Okay - that’s a big reach. :winking_face: Aren’t we all in the “general public”? If you’re using attachments in a table as an open public content space, you should have no expectation of (a) control or (b) security after the fact. The Interwebs will cache that content and the URL - however obscure it may be - will not matter.

Again, there are two distinct parts to this statement.

… doesn’t mean that that person should continue to have access to that attachment in the future if they leave the company

This is not Airtable’s axe to grind; talk to your CSO and IT people whose jobs exist for building and enforcing protocols that manage content with precision.

… but especially if you delete the attachment from your system.

Stated and I agree; Airtable’s must grind this axe. :winking_face:

We agree on the 2nd point, but I disagree with you on your 1st point. Look at how a secure database system like FileMaker WebDirect handles attachments securely. Attachments always have an extra layer of security on top of them — you can’t see the attachment in your web browser by typing in its attachment URL unless you have already passed through the authentication process.