Get best of the week

How did we google security checkup

To ensure the security of user data, Google carefully checks all applications that use restricted API scopes and have access to Google User Data. Not so long ago, we at Snov.io went through the verification process and received Google approval, with which we want to share.

New rules for applications


On October 9, 2018, Google announced new rules for applications that use the Google restricted API scopes. They included 2 stages of verification:

  • Verify that your application complies with Google API User Data
  • Verify minimum security requirements

The restricted scope app verification verifies compliance with the Google API User Data Policy and an additional set of policies outlined in Additional Requirements for Specific API Scopes. First, your application will be reviewed for compliance with the Google API Services: User Data Policy. Thereafter, you will have the remainder of 2019 to demonstrate compliance with the secure handling requirements.

Verification of compliance with minimum security requirements cost a lot of money - from $ 15,000 to $ 75,000.
Assessments will be conducted by a Google-designated third-party assessor, may cost between $ 15,000 and $ 75,000 (or more) depending on the complexity of the application, and will be payable by the developer. This fee may be required whether or not your app passes the assessment .

As early as January 9, 2019, Google tightened the rules for applications that plan to use the Google API. For applications that used the Google API earlier, there was a requirement to submit an application for verification before February 15 . Otherwise, access to the application would be closed to new users starting February 22 , and existing users could not use the application from March 31 .

The consequences of such a development would be unpleasant. This is due to the fact that a significant number of our users (and there are more than 100 thousand) use Gmail. Therefore, we would simply lose these customers.

For projects that require action, you must submit apps for verification before Feb 15th, 2019. If you don't, access for new users will be disabled on February 22nd, 2019, and existing grants for consumer accounts will be revoked on March 31st, 2019.

How did everything happen before the updates?


Our Snov.io platform has been using the Google API since 2017. Our application used several restricted scopes: for reading incoming mail and for working with drafts. 

Google has previously tested applications that use the Google API. In order to apply the new API scope, it was necessary to add it to the console and indicate what it will be used for. While Google employees checked the application, users saw the notification “This app isn't verified” on their screens: 



Usually, this check took us 2-3 business days (although, in a letter from Google, it was indicated that the process can last up to 7 days) and always passed without problems. We waited until Google checked our application and only then poured the feature on the prod so that users would not see the notification “This app isn't verified”. 

Passage of the first stage


To begin with, we decided to focus on the first stage of verification, namely, the compliance of our application with the Google API User Data policy. 

On January 16, the Submit for Verification button appeared in the Google console and we sent an application. Before departure, we made sure that we comply with all the points in the Google API User Data policy. We made changes to our privacy policy, in particular, added the Google User Data section, which described in detail what data received from the Google API we store, how we use it and when we delete it. 

February 12, we received a response to the submitted application. We were asked to record videos and show how we use the requested restricted API scopes. 

As a result, we had to abandon our two projects on Google Cloud and merge them into one. We abandoned the first project for the test server, which worked in test mode, and used the same project for the test as on the prod. We also deleted the second project for authorization into the system through Google and instead used the project that required verification to log in. 

Representatives of Google answered our letters somewhere after 2 weeks. For questions, instead of direct answers, we received quotes. It seemed to us that they have a special script by which they check applications. 

For example, we were reminded that we use an application with one ID to enter the system, and when connecting an email account, an application with a different ID. We did this on purpose, as these are two completely different functions. The login application did not require any checks and we did not want the failure to pass the application verification with restricted API scopes to disable the verification application.



On April 20, we finally passed the first stage of the Google Data Policy Compliance Check!

Passage of the second stage 


Step 1. Choosing a company to pass the audit


By the second stage of testing our application, Google sent contacts of two companies to choose from - Bishop Fox and Leviathan Security . It was possible to pass the check only with them. The deadline was given until December 31 .

On May 20, we sent letters to two independent experts to pass the audit. Bishop Fox and Leviathan Security sent questionnaires with questions about our application. It was necessary to answer what kind of Google data we use, how many lines of code are written for each programming language, as well as questions about our infrastructure, the process of software deployment and hosting provider. We filled out everything and began to wait for the price offer.



During the preparation and preliminary communication with company representatives, we learned that the hosting on which our servers are located does not comply with SOC2 . And for successful verification we had to move to the appropriate SOC2 hosting . We have long been thinking about moving to Amazon , so we started the process of moving in parallel. 

We also learned that we need the Bug Bounty program offered by many websites and software developers. With it, people can receive recognition and reward for finding bugs, especially those related to exploits and vulnerabilities. 

In September, we had two ready-made contracts from Bishop Fox and Leviathan Security. We had to decide with whom to conclude a contract. We did not know what criteria to choose an expert for, but the agreement with Leviathan Security seemed more transparent to us, despite the fact that it cost slightly more.

Step 2. Signing the contract and preparing for verification


On October 8, we signed an agreement with Leviathan Security. At the time of signing the contract, we have not yet completed the process of moving to Amazon. Therefore, in our contract in the column "hosting" there was a gap and we had to enter it later.

We also learned what verification will include:

  • External Network Penetration Test 
  • Application penetration testing 
  • Deployment Review 
  • Policy & Procedure Review 

And the following steps:

  • Preparation 
  • Assessment
  • Verification & validation
  • Final report

Check lasts about a month. Its price includes time to eliminate the vulnerabilities found. Then a second check is performed. As a result of the verification, we should have received a Letter of Assessment (LOA), which then needs to be sent to Google representatives. But the expert does not guarantee receipt of LOA as a 100% result of the assessment. 

On October 23, Leviathan Security sent a Self-Assessment Questionnaire (SAQ). Together with her, we also provided our policies that were needed to pass the audit:

  • Incident Response Plan: Establishes roles, responsibilities, and actions when an incident occurs
  • Risk Management Policy: Identifies, reduces, and prevents undesirable incidents or outcomes
  • Vulnerability Disclosure Policy: Provides a means for external parties to report vulnerabilities
  • Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
  • Privacy Policy: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant

On November 8, an External Alignment Meeting took place, at which we discussed all organizational issues, identified a messenger for communication ( Slack ) and briefly talked about our application. We were warned that it would be necessary to provide access to the source code - this was not a problem for us. 

At the rally, we learned that we need to encrypt Oauth tokens using KMS , which we did not do before. We also discussed the approximate time of our check. We were assured that if she was appointed at the end of the year and we did not have time to go through it, Leviathan Security will negotiate with Google to extend the deadline for us.

November 14thWe received information about the planned start of our inspection: late December or early January. And Leviathan Security warned Google that we could provide LOA later than the deadline. 

On November 16th, we received confirmation from Google that the deadline was postponed until March 31st.

Step 3. Verification


On December 13, we received a letter in which we were notified about the start of the audit - on January 2, and asked to fulfill the following requirements: 

1. Confirm the possibility of an audit.

2. Once again provide the necessary information. 

Documents had to be uploaded to the shared folder on OneDrive a week before the scan - until December 26th . We did not provide any additional documents except the required ones: 

  • Incident Response Plan
  • Risk management policy
  • Vulnerability Disclosure Policy
  • Information Security Policy
  • Privacy Policy
  • Supporting Privacy Documentation
  • Terms and Conditions
  • Self Assessment Questionnaire (SAQ)
  • API
  • URL-
  • IP


3. Provide access to the source code.

4. Invite certain people to the Slack messenger.

5. Indicate the phone number and details for the escalation of the project.

6. Provide information on how we should be billed.

7. Inform the internal security teams, CDN and hosting providers that the verification will take place from January 2 to January 27.

8. Create a shared folder on OneDrive.

9. Check out Google Checkout Frequently Asked Questions . 

December 30tha kick-off meeting took place, at which almost everything was the same as at the first rally. We introduced ourselves, described the product with a set of technologies, and confirmed that our system is stable and that no major releases will be released during product evaluation. It ended with questions and comments. 

On January 2, a security check began. Note that it took place without much difficulty. Sometimes it was inconvenient because of the difference in time zones - all the calls and communication in Slack we already had during off-hours for us. 

We have found many vulnerabilities - high and critical level (high and critical). Such vulnerabilities needed to be fixed. Vulnerabilities of the middle level and below could be corrected at one’s discretion. The correction was given 30 days. But we fixed them literally the next day. 

The vulnerabilities were mainly related to outdated methods of encrypting user data and insufficient logging. There were no complaints against our policy documents. The Leviathan Security Policy Department asked a few clarifying questions and said that they looked solid.

There was no lack of communication. We could clarify all obscure issues at the status of rallies or at Slack. Vulnerability reports were well documented and also included recommendations for fixing. On the last day of our assessment, all critical, high, as well as some medium and low vulnerabilities were fixed and checked. 

January 31, we received the LOA and sent it to Google representatives.  

February 11 received confirmation of verification from Google.



The most difficult thing for us was the unknown. What to expect? How will everything happen? We felt like pioneers. Nowhere was there any information about how other companies passed this test, which prompted us to share information about Security Checkup with others.

We want to say to those to whom such a check is yet to come, that it is not as scary as it might seem. Yes, the process is time-consuming, but there will be a good margin of time to fix all vulnerabilities. Despite the fact that it took us a year to go through Google Security Checkup, this time was not wasted. We can continue to use the Google API, which is vital for us, and also have closed vulnerabilities that could subsequently come out sideways for us or our customers.

There are companies, such as Context.io, that have decided not to pass the audit and have closed. There are those who continue to work without access to the API, but at the same time lose their reputation in the eyes of users. Every business that needs to be tested, of course, will have to independently weigh the pros and cons. The hardest thing will be for very young companies that do not yet have a profit. But if the business has the resources to pass the test, then it is definitely worth doing.

We hope that our experience will help you with this!

More articles:


All Articles