Security assessment for Add-on that uses Google APIs??

[Andrew Roberts]

I have searched back through the archive and not been able to find a definitive answer to this, so apologies if I missed it:

If I have an Add-on that uses the external_request scope to access a Google API - for which there isn't an Advanced Service (like Google Cloud Storage) - will I definitely have to have a security assessment to get the Add-on published publically?

Update:

Looks like it is a yes: From https://support.google.com/cloud/answer/9110914#security_assessment

"Customers manage Google Cloud Platform and FirebaseCP services, so they would still require a security assessment. "

[Romain Vialard]

Only if you are accessing user data in Gmail or Google Drive. Those are the 2 services where a security assessment is needed.

[Faustino Rodriguez]

And there are some exceptions that might avoid the security assessment (SA)

As far as I know, at least these cases won't require the SA

- using the scopes gmail.readonly and gmail.send, but not script.external_request

- using the scope drive.file

[Alan Wells]

There's a difference between verification and security assessment.  They aren't the same thing.

• Sensitive Scopes - Needs verification but not an Security Assessment - Basically all non-restricted scopes as far as I know
  
• Restricted Scopes - Needs a Security Assessment - Full access to Gmail or Drive is restricted
  

Security Assessment - You must pay - is tied to Restricted Scopes

I don't know if there is such a thing as a scope that isn't even sensitive.  As far as I know, if something requires a scope, then it's automatically at least sensitive.  There are some classes that don't require a scope, like Logger, console, blob.

If you or your customer doesn't care about a warning message, and you'll stay under 100 installations/users, then you don't need to go through verification, and my impression is that you can use restricted scopes without needing a security assessment.

If using UrlFetchApp.fetch() to call an API, could get around the need for verification or a security assessment, then that would be a huge security hole.

[Romain Vialard]

Indeed there's no difference if you are using the standard services, advanced services or the REST API using Urlfetch.

But, if you don't use the scope script.external_request (no urlfetch in your code), it means you can manipulate user data retrieved from Gmail or Drive but you won't be able to send it to an external database. In that specific case, a security assessment is not needed (as the whole point of the assessment is to make sure you are not stealing / sending away user data).

[Dimu Designs]

I've thought a lot about add-ons with restricted scopes and avoiding security assessments. And I think I have a possible workaround but it will require massive buy-in from end users so its probably not going to be viable. 

So here's the basic idea. Extract code that uses restricted scopes into a series of CRUD(Create, Read, Update, Delete) operations to form the equivalent of a custom API. Provide this code publicly and free-of-charge to end-users with instructions on how to deploy it as an API Executable (under their own accounts) and how to generate OAuth2 refresh tokens specific to their accounts. 

When end-users install an add-on they will be asked to provide the refresh token (along with the client_id and client_secret) of their custom API which the add-on will then leverage to make calls against the API executable. In this scenario, the add-on does not have direct access to any restricted scopes, its the end-user that ultimately provides that access and they who ultimately own the API executable. Of course, the add-on will still require the sensitive "script.external_request" scope and require verification, but it won't need to undergo a security assessment.

The core issue is how to cultivate trust with end-users for them to buy into this workflow. We would probably need to establish some kind of overseeing review body of our own to make this approach feasible.

Just some thoughts...

[Alan Wells]

I think it's a great idea.  Count me in.

On Friday, February 7, 2020 at 10:08:15 AM UTC-5, Dimu Designs wrote:

I've thought a lot about add-ons with restricted scopes and avoiding security assessments. And I think I have a possible workaround but it will require massive buy-in from end users so its probably not going to be viable. 

So here's the basic idea. Extract code that uses restricted scopes into a series of CRUD(Create, Read, Update, Delete) operations to form the equivalent of a custom API. Provide this code publicly and free-of-charge to end-users with instructions on how to deploy it as an API Executable and how to generate OAuth2 refresh tokens specific to their accounts. 

When end-users install an add-on they will be asked to provide the refresh token of their custom API which the add-on will then leverage to make calls against the API executable.

[Andrew Roberts]

So:

IF the Add-on uses a restricted scope AND accesses an external service with a call to UrlFetch.fetch() THEN you need a security assessment (unless it is private, has less than 100 users, etc.) ELSE you just need Google verification?

[Alan Wells]

Yes, correct.  I'm not sure if the

"AND accesses an external service with a call to UrlFetch.fetch()"

part is documented anywhere. Or explicitly stated in those terms. And I'm not sure if you'd need to argue your case with the add-on advisor, or whatever it's called now, to make sure that they understood the difference.

Of course, if you don't use
UrlFetch.fetch()

and it's a paid add-on, then you'd need to have your users go to your website, pay, get a Registration Code, come back to your add-on, enter the registration code. Then your add-on would need to know that the Registration Code is correct without making an external request to anywhere.

Unless there is something that I'm missing. (Probably)

[Andrew Roberts]

This is my interpretation of the docs here:

“...if the app accesses or has the capability to access Google user data from or through a server, the system must undergo an independent (3P) security assessment.”

Which ties in with what Romain has said about how basically they don't want your Add-on to be able to take user data and send it to a third-party server.

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/028e73ec-96c9-4e59-ad09-b2d56c0f4a88%40googlegroups.com.

[Alan Wells]

 Can we send user data somewhere through the client?  And not need the $15,000 security assessment?  That's what I want to know.  Firebase can work totally through a client side script, correct?

[Andrew Roberts]

Interesting idea Alan. As a matter of course the client-side code will be accessing other sites to download CSS files and the like, so there shouldn't be a reason it can't access Firebase too??.

On Wed, 12 Feb 2020 at 13:39, Alan Wells <aj.a...@gmail.com> wrote:

 Can we send user data somewhere through the client?  And not need the $15,000 security assessment?  That's what I want to know.  Firebase can work totally through a client side script, correct?

--

You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/293ff5af-bf38-4c99-af9b-b2fadc80dede%40googlegroups.com.

[Alan Wells]

 Well, what makes sense, and what actually works might be different.  Unless I'd tried it, or someone let us know, then I don't have a definitive answer.  I'm assuming that a flow of events that would work is:

• User goes to your website and pays and gets a code/key/whatever you want to call it
• Your website sends the user key to your Firebase database
  
• User goes to your add-on and enters the key in client side sidebar or dialog box
  
• Sidebar or dialog box makes a call to Firebase and checks the user key to determine if it's valid.
  
• If the key is valid then save a setting to Properties Service so that when server side Apps Script code runs, it can check payment status without needing to make a UrlFetchApp.fetch() call
• Any time the user opens the add-on user interface, check payment status, and if expired or near expiration, notify user.  If need be, the client side code can call Firebase again.
  

I'm quite sure that would work for checking payment status.  You could also send the user email through the client side to your Firebase database, but I don't know if the add-on adviser checks for client side code sending user information.