I think I’ve made it clear that we both agree the risk of compromised access to data in any platform is high when you do things that allow it to be high. Please stop saying we don’t agree. We agree. It’s bad, and my recommendation 3500 words ago was don’t do that. :winking_face:
If you take that a step further and expose a web app that allows dynamic query construction without a security context in the web app itself, you’ve elevated the risk. If you comingle records intended for multiple classes of users, expose them to an API, and then fail to wrap such access with a security layer singling out the specific class intended, you are creating an even greater risk that class (a) gets a look at class (b’s) data. You don’t have to use filterByFormula to create this additional security risk.
Initially, you framed the narrative as a broad security flaw related to Airtable. You have since agreed that it’s not really Airtable; it’s any poorly designed web app. I think we both agree that the security architecture of web apps that lean on APIs from ANY platform matters greatly, and the complexities and risks of getting it wrong are far greater than simply focusing on filterByFormula.
Where I think we do not agree is the very premise of using filterByFormula in use cases external to the Airtable platform;
-
I think it’s no different than the risks posed by javascript eval() and should be avoided if at all possible. I have found many ways to do this, and I tend to believe the best part in a machine is no part at all. More parts lead to a greater risk of breakage and a whole host of problems. filterByFormula is simply one that exacerbates the likelihood of a security issue, but it also has the propensity of easily creating unanticipated queries which fail, and this is especially the case when allowing user input to craft such filters.
-
You’ve made it clear that filterByFormula is fine if you undertake the challenge of properly escaping various characters. Some developers have no qualms about using eval() as well.
Both our viewpoints are a matter of engineering preference and ironically resolve deep in the shadow of a #no/low-code platform. Since you clearly understand this problem well, why don’t you just build a better SDK? What’s stopping you from showing Airtable and the user community a better approach?
If you agree to stop sensationalizing this as an Airtable security flaw, I’ll agree to like your future posts where you frame narratives that are reasoned and helpful to API users without creating unnecessary fear, uncertainty, and doubt. Deal?
