33

If I write a google apps script, and within the script I need to invoke third party APIs or make database calls, what is the appropriate way of managing secret API keys and passwords?

Is there any risk in placing the secrets directly within the script if I publish the script as an API but don't share access to the Google Drive location that contains the Google Apps script

Master_Yoda
  • 1,092
  • 2
  • 10
  • 18
  • 4
    For example, how about using Web Apps to your situation? I think that you can use the secret keys in the script of Web Apps. A sample flow is as follows. 1. Create the script using Google Apps Script including the secret keys. 2. Deploy it as Web Apps. 3. You call the Web Apps like an API and retrieve the values by running the script. In this case, the ID including the endpoint of Web Apps is not script ID and also the script is not required to be shared. https://developers.google.com/apps-script/guides/web If this was not what you want, I'm sorry. – Tanaike Nov 07 '18 at 22:44
  • 5
    Also, store it in [User Properties](https://developers.google.com/apps-script/reference/properties/properties-service#getUserProperties()) – TheMaster Nov 08 '18 at 01:53
  • @OP - Did you manage to find a better solution than keeping it in script? – Anshu Prateek Jun 30 '19 at 08:54
  • 1
    @Anshu Prateek unfortunately user properties seems to be the only alternative. it's not a great soliton. – Master_Yoda Jun 30 '19 at 13:10
  • @Master_Yoda Why is user properties not a great solution? – IMTheNachoMan Dec 11 '19 at 03:48
  • @IMTheNachoMan One reason: If you share the script, everyone can see the user properties. – Master_Yoda Dec 11 '19 at 15:31
  • 1
    @Master_Yoda the UserProperties is different on a user-by-user basis. If you are wanting to be able to share a script but still keep it secret you might need to look into publishing an Add-On which will allow you to keep your code secret while allowing the process to be open. – Rob Dec 31 '19 at 00:16
  • 1
    @Master_Yoda No they won't. user properties is private to the user setting the property. – TheMaster Mar 21 '20 at 14:55
  • @Rob - Good to know. Still unfortunately doesn't help because other people should be able to invoke the script when I share. – Master_Yoda Sep 04 '20 at 02:11
  • Because that's what Google does, the UserProperties have been deprecated. Sigh. – dannysauer Feb 17 '21 at 20:29
  • 2
    @dannysauer UserProperties were deprecated but were replaced by PropertiesService.getUserProperties() which, despite the 'get' name, has 'set' functions to set the properties as well. Bad naming, but works. https://developers.google.com/apps-script/reference/properties/properties-service – Trashman Feb 08 '22 at 15:40
  • using UserProperties doesn't seem to work, see https://stackoverflow.com/questions/73248451/sharing-secrets-in-apps-scripts – Nik Aug 05 '22 at 10:45

2 Answers2

10

There is no right or wrong answer. There are numerous factors to consider:

  • If this is for/in G-Suite, then your G-Suite admins'll have (or can get) access to anything. This may or may not be an issue.
  • If you put the data in a sheet, anyone that has read access to the sheet can see the data.
  • You can use PropertiesService but then folks can access as explained in the documentation. User properties is one way but may not work in all use-cases -- like if another user is executing the code. You could use installable triggers if that is do-able for your use-case.
  • If folks need to be able to make the API call with your key, you could write a proxy web-app that they can call but not see source for.
IMTheNachoMan
  • 5,343
  • 5
  • 40
  • 89
  • I want to make sure I understand this correctly. If I set UserProperties in an installable trigger, that will make them execute as ME (not the user accessing the sheet with the associated script) and the user using the sheet will have no way to see those properties, correct? – Trashman Feb 08 '22 at 15:43
  • Depending on what scopes the trigger uses, if the user has edit access to the sheets, the could edit the script to read the property and write it somewhere -- like a cell in the sheet. – IMTheNachoMan Feb 08 '22 at 15:48
  • Good point. It seems the only truly secure way then is to deploy as a WebApp? – Trashman Feb 08 '22 at 15:54
  • Well it all depends on who you give access to. Even a WebApp would have the same issue if you gave someone access. – IMTheNachoMan Feb 08 '22 at 16:02
  • The secret is, wherever the secret is, be it a container bound script, or a standalone script, don't give people you don't trust access to it. – IMTheNachoMan Feb 08 '22 at 16:04
  • Thank you for the help. I know this is bordering on "I should ask a new question" but also the new question could be redundant with this one. The script must be executed from a shared drive, I don't "trust" everyone that has access to that drive and I can't limit the permissions of everyone I don't trust. However, I do need to "trust" two other specific users in case I were to leave/transfer. If I put it just on MY drive then they won't all have access. If I share it from my drive, if and when my permissions get revoked, everyone will lose access based on company policy I don't control. – Trashman Feb 08 '22 at 16:14
  • I wonder if you could use sheet protections to limit access. Lock and hide a sheet such that only you can access it. I wonder how that translates to GAS. – IMTheNachoMan Feb 08 '22 at 17:06
-2

You can now make a library with hidden functions (using a trailing underscore) so that another script cannot remotely access the hidden functions. Simply store the credentials in a hidden function, then call that function within the library script, then reference the library script from another script.

user18570235
  • 5
  • 1
  • I don't think that's secure. First, you have to share the source code of library with the script using the library. – TheMaster May 06 '22 at 08:02