Ever seen an overzealous user madly clicking on an image button in Google Sheets to run an automation script? It’s maddening, frustrating and most importantly, may cause errors in your beautifully crafted code.
In this short tutorial, we explore how to use Google Apps Script’s Lock Service to prevent users from executing your code from your image button while the original instance of the code is still running.
Grab a copy of the starter sheet below to play along.
If you have landed on this page you may have discovered that dates and times don’t always work as you might expect with the Google Sheets FILTER function.
In this tutorial, we are going to cover how to use FILTER on dates, times and date and time stamps (DTS).
You can follow through the tutorial in its entirety or use the table of contents below to get directly to what you need.
Cross-Site Request Forgery (CSRF) is a web security vulnerability that allows a nefarious entity to take actions on a website that are unintended by the user.
Typically, this is done by tricking the user into using another website resembling the intended site and then submitting a form or clicking a button. The dodgy site then sends a request with its own payload of nasty stuff on the user’s behalf.
Google Workspace and Google Apps Script’s HMTL Service API protect the user with OAuth2 authorization standards and embed dialogues and sidebars in restrictive iframes to sandbox these environments. However, there may be a requirement to further protect your users from unintentionally sending form data using the google.script.run Client-side API that sends data back to Google Apps Script, with a server-side generated anti-CSRF token.
Indeed, when completing a CASA Tier 2 security assessment for a Google Workspace Editor add-on this was a requirement for me to not only pass the assessment but to also meet GDPR requirements.
An anti-CSRF token will allow us to create a unique ID for the current sidebar or dialogue session. We can store this token server-side in the User Properties of the Properties Service and then add the token to a hidden input element in our form client-side on our dialogues and sidebars. We can then send this token along with our form payload back to Apps Script where we can first validate the token before continuing.
The following script and tutorial provide a brief example of how to do this.
Table of Contents
The Example Dialogue
We will first open a Google Sheet (but you can open a Google Doc or Slide and do the same thing) and create a bound Google Apps Script.
Our simple tasks will be to:
Create a menu to access a modal dialogue in the Google Sheet.
Create the modal dialogue with a form containing a radio selection and a submit button.
On submission, the form is validated with the anti-CSRF token before
Create a Menu Item and Modal Dialogue in Google Sheets
onOpen runDialogue functions
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//
/**
* Creates a menu item to access the dialogue.
*/
functiononOpen(){
constui=SpreadsheetApp.getUi()
ui.createMenu("Anti-CSRF token")
.addItem("Run dialogue","runDialogue")
.addToUi()
};
/**
* Creates the dialogue as a template so we can directly add the getCsrfToken to the sheet.
Next, we build the dialogue. Here, we invoke HtmlService to create a template from a file, referencing the ‘Index.html’ file as our source file. We will take this approach to use scriptlets in our HTML to define our CSRF token.
Finally, we will call the UI method again to display the HTML in a modal dialogue.
Create the Front-end ‘Index’ HTML Page
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This is where we are inserting a custom token into the current dialogue session. we have named it “_csrf”. You can also see that we have used Google Apps Script’s HTML printing scriptlets to display the anti-CSRF token returned from the getCsrfToken() function.
This function is called from the Google Apps Script side and generated as a part of the HTML template-building process. More on this function later.
Line 20-21: The submit button is added outside the form so as not to generate an error when clicked.
A response line is also added to display if the token is correct or not.
Submitting the Form
submit()
Lines 43-64
When the ‘Submit’ button is clicked, the submit() function is invoked.
Here we retrieve the form element and use the new FormData() constructor to gather all the form responses including our hidden CSRF token.
Next, we iterate over the form data entries sorting the keys and values in the payload object.
Finally, we use the google.script.run API to send a stringified version of the payload back serverside.
We also invoke the withSuccessHandler method to return a message once validation of the token has been carried out.
onSuccess(e)
Once the CSRF token has been validated against the stored token value serverside (Apps Script-side) a stringified object will be returned back to the HTML file containing a hasError boolean property and a text string property.
If there was no match between the sent CSRF token and the stored token, we change our message colour to red.
Then we report the message in the ‘response’ span under the submit button.
Generate the CSRF Token in Google Apps Script
getCsrfToken()
1
2
3
4
5
6
7
8
9
10
11
12
13
//
/**
* Generates the anti CSRF token for for the current user and stores it for the current session.
* Token is stores in the users properties service.
* A new one is created each time the dialogue is built.
Next, the token is stored in the user’s property service. This way the token is only accessible for that use for this script. We will generate and store this token each time the user opens dialogue to make it even more challenging for an attacker to breach.
Finally, the token is returned so it can be stored in the HTML file.
message.text="Your choice has been adde successfully!"
// Continue with form content validation.
// ...
returnJSON.stringify(message)
}
Lines 6-10: When the user submits the form, it is sent to the formInputs() function. Here we first parse the stringified form data back to an object and then set up a message object that we will return when our script is complete.
On line 14, we grab our stored CSRF token value so that we can compare it against the one coming in.
Then on lines 17- 27, we check if the form CSRF value matches the store CSRF token value. If it doesn’t, then we return the message variable with our error text.
If the tokens match, then you can carry on a validate your other form inputs before continuing with your data.
That’s it. That’s the whole script. Google Apps Script makes it really easy to implement this security token.
Is It Really Necessary to Add CSRF Tokens to your Google Workspace Dialogues and Sidebars?
Well…probably not. Particularly if you do not intend to publish your Add-on to the public. However, if you do have some restricted scopes that need to be authorised by your users then part of the CASA Tier 2 Assessment then it probably isn’t a huge deal.
The likelihood of someone finding or caring about your dialogues and then trying to exploit them along with Google OAuth and Iframe restrictions would make it pretty hard for a baddie to do any damage to your Google Workspace environment. But, you never know.
Need help with Google Workspace development?
Go something to solve bigger than Chat GPT?
I can help you with all of your Google Workspace development needs, from custom app development to integrations and security. I have a proven track record of success in helping businesses of all sizes get the most out of Google Workspace.
