According to Google, one can add the SHA-1 certificate fingerprint and the name of the package in the Google Developers Console to restrict the usage of his API key to his Android app, so that developers can make sure that their API keys are not being used by other clients than theirs.

According to this and this, programmers should simply add the SHA-1 fingerprint and the package name to their HTTPS-request headers in order for Google to be able to verify that the request comes from the "authorized" app and consequently serve it.

But since the SHA-1 fingerprint and the the package name are publicly known, then anyone else can also very simply add them to his HTTPS-request header and let his program very easily bypass the restriction and verify himself by Google as the "authorized" app!

Therefore, I do not understand the usefulness of this kind of restrictions which are based on infos that are publicly known!

  • 1
    Being a client "secret", it will always be replayable/spoofable. Using the package sha1 would probably prevent other people from simply repackaging your app. Also it might be easier to spot rogue apps this way. – domenukk Jun 24 '19 at 16:41
  • @domenukk the package sha1? So do you mean using the SHA-1 hash of the package name instead of the SHA-1 fingerprint of the certificate signing the app? i.e. if the package name were com.example.stackexchange, then 1d6b033289a9844b24f62c7c1cdf054726debb58 should be used!? – user9514066 Jun 25 '19 at 12:01
  • No, I mean the fingerprint. It will change when the package gets repackaged by somebody else (since the certificate will be different). – domenukk Jun 25 '19 at 21:39

As domenukk stated in his comment, the Google API key restriction prevents other users from packaging your API key in their app. It is simply a way for Google to ensure that the API calls it is receiving are coming from an application that was packaged by the developer who added said key to his Google API account.

However, as you rightly pointed out, it is easy to circumvent. For example, this answer on SO shows how to build a request using any Android Google API key. So the matter of circumventing the restriction is rather trivial.

However, the benefit is in the cost involved for an attacker. A similar question was asked for HTTP referrers, so I will just quote the relevant part to your question (just replace referrer header with SHA1 fingerprint):

So, just because a malicious agent could copy the referrer header, they may not have the time or inclination to do so. Think of a valid referrer header like a concert wristband. Can you forge them, or sneak around the guard checking wristbands? Sure you can, but it doesn't make the band useless.

It raises the cost for the attacker.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.