Ключ API, скорее всего, является односторонним хешем домена, с которым связан ключ, и секретом, о котором знает только сервер API Google. Он может содержать некоторые другие части хорошо известной (для Google, конечно) информации. Когда вы делаете запрос из этого домена, сервер API берет домен, из которого поступил запрос, и выполняет те же однонаправленные вычисления хеша и сравнивает два значения.
Для вызовов Ajax они, скорее всего, используют реферер для получения домена узла документа. Несмотря на то, что реферер может быть подделан, в конечном счете, чтобы использовать API, вам нужно заставить Google javascript выполнить в документе. На этом этапе этот javascript может проверить, что действительно документ, который вызвал вызов API Ajax, возник с целевого сервера. Конечно, это также можно подделать, если у вас есть собственная реализация DOM или модификация скрипта на лету. Однако такая подделка должна происходить на стороне клиента, и вероятность того, что веб-сайт, который хочет использовать Google API, сможет подделать клиентское программное обеспечение, весьма мала.
Обратите внимание, что, поскольку API по сути бесплатен, они могли бы также предложить анонимный доступ к своему API. Очевидно, что целью Google является не защита от несанкционированного доступа к нему, а обеспечение того, чтобы они могли собирать как можно больше данных об использовании этих данных и иметь возможность связать это использование с другими данными, которые они собрали о целевом домене. Таким образом, я не ожидал бы, что проверка ключа API будет намного более сложной, чем та, что я описал выше - рентабельность инвестиций при более продвинутом подходе слишком низкая.
И, конечно же, существует проблема возможных XSS-атак через их API. Но я не верю, что их ключ API слишком сильно связан с любым кодом анти-XSS, который у них есть.