Custom action API key storage best practices

Get Help External Collections, Custom Actions & Collections
1

What is the group’s recommendation for storing of external API keys (e.g. Authorization headers) for use in custom actions? Where do you put them?

Currently, I’m putting my keys directly in the custom action field, however I think this is bad practice for two reasons:

  1. If it changes, I need to go to all the custom actions and update them one at a time
  2. I can’t use test keys in production (especially for things like Stripe)

So the alternative is to put them in a new collection? But then that collection would have to be linked to every user?

What are folks doing here that works well? @Victor?

@jessehaywood - this is the type of thing that could be a good discussion topic for one of your videos… :slight_smile:

2 Likes
2

When you say that you’re putting the API keys directly in the custom action field, are you saying that you put them in the query parameters in the custom action itself or within a magic text parameter?

It’s best to have the api key within the custom action in the header/query parameter section.

download
download1920×1011 93.8 KB

You wouldn’t need to change the api key anywhere except within the custom action itself.

3

Sorry, no it’s in the magic text area - it’s a variable in the CA.

My issue is I use same API key in many custom actions (for example, for Stripe, it’s one time payment, subscription payment, create customer, create and get Connect accounts, etc). So I use the same key all over the place. I would never “hard code” it into the custom action directly.

I think it would be much better if I kept it in one place which is then used as magic text, but there’s no app-wide variables so it would need to be in it’s own collection I think.

4

I think I figure it out, for anyone else who was wondering… I created a new collection called Keys and a many to one (one Key can have many) relationship to Users collection (in my case it’s actually a different collection, but same concept).

The Keys collection has a name and fields for all the API keys I use.
I manually created two entries, one called prod and one called test and added the relevant API keys.
Then assign each user (again in my case it was a different collection but same thing) to the relevant collection (by using a button in a list to filter the right Key record).

The custom action Auth field uses the relevant user->Keys API magic text.

Voila! Now I can have testing users in a production database by switching the linked Key record.

5

Best practices for API security
For apps and projects that use the Google Maps Platform APIs and SDKs, API keys are necessary. Secure your API keys as you create them for maximum security and little effort.

While it is feasible to secure API keys after they have been created and are in use, different limits may apply depending on how the key is used. Updating or replacing keys in mobile apps (Android and iOS) is the most difficult because all keys will not be replaced until all consumers upgrade their apps. Updating or replacing keys for JavaScript or Web Service apps is much simple, although updating or replacing these keys may still necessitate careful preparation and quick effort.

The security practices that apply to each Google Maps Platform product, such as the Maps JavaScript API, are listed in the More information section.

6

Hi @paulh,

From a security perspective, I would strongly advice not to store keys in DB collections. There are various reasons for that.

Best,
Victor.

7

Victor, could you share why not? And if not in db, would you suggest keeping them in the custom action directly (which would limit being able to use test keys in production) or something else?