Despite the fact that we work and develop apps in a climate of extreme security, the fear concerning Airtable API keys is growing and will likely worsen in the future; Airtable, after all, provides an all-or-nothing API key architecture. And we often leave security requirements until long after the solution is working, at times creating serious exposure to our customer’s data.
In Google Apps Script there are a number of ways to separate API keys from the code, but this is typically not enough as far as security professionals are concerned. Separation from code, they argue, still makes it possible for developers to discover the keys.
But even this accessibility can be eliminated by moving your API calls into a library and enforcing a basic principle -
… only the methods in the library should be able to call methods that can access the keys which are stored in the script project properties.
This is achieved with a simple enhancement to a library by setting the method such as getAirtableAPIKey() to be hidden and forcing all access to this method through other library methods:
getAirtableAPIKey_() // hidden from remote access by the trailing underscore
This makes it impossible for developers with access to the library to also access this method as both of these calls will reject such requests:
AuthLib.getAirtableAPIKey() // TypeError: Cannot find function in object AuthLib.getAirtableAPIKey_() // TypeError: Cannot find function in object
One must ask - if the method is hidden, how will apps that use the AuthLib platform be able to access this method?
The answer is very simple - through indirect calls.
The library itself (in this example) is designed to encapsulate all Airtable API interactions. And since this code is encapsulated in the library, it is able to see any and all “local” methods including those established as hidden from the remote apps that use the library. The Airtable API methods are exposed to developers, but hidden functions related to API keys and other sensitive information are not.