Best practices for hiding or obfuscating a production API Key in your code

General JUCE discussion
1

I need to use a production API Key for my analytics. Naturally, I don’t want to hardcode the full API Key as a string in the application.

However, I’m unsure of the best practices for handling this. Could you provide some guidance? Here are the approaches I’ve considered so far:

  1. Since the analytics feature requires an internet connection to work, I could assume that if the app is offline, there’s no need to retrieve the API Key. With that in mind, I could store the API Key in the cloud and fetch it during the initialization process. However, the URL for retrieving the key would still be hardcoded in the application, so if a hacker discovers this URL, they could easily access the API Key as well.

  2. Use an encryption method. JUCE offers encryption classes and this tutorial about Unlock your plugins through online registration.
    However, I’m not sure if this approach would be suitable for my use case.

Any insights, recommendations, or tutorials would be greatly appreciated.

Thanks

2

Don’t contact the API directly from your plugin/app.

Create a simple HTTP endpoint using something like Google Cloud Run, cloud functions, AWS lambda, etc. And have the API key embedded in that.

1 Like
3

Thanks for the insight @eyalamir.
But wouldn’t it be dangerous too? I mean, if someone manages to find the endpoint, they will be able to get the key themselves, as I explained in my first point. Did I miss something?

4

No, that would be extremely difficult/close to impossible. Can you hack into an http server and find out what API keys are used in it?

Pretty much every website you’re visiting during the day is using some API keys when responding to your http requests.

5

@eyalamir My apologies! I just realized what you meant.

Your suggestion is to:

  • Create a server that will be the only one to know the API Key
  • Send the analytics data to this server
  • Have the server contact my analytics API to forward the data

I’m sorry, I misunderstood and thought you were suggesting fetching the API Key from a server. :man_facepalming:

It’s a great idea, and I will definitely explore it!

Also, since this is an app for a client, I’m considering if there are other possibilities that might be easier to implement.
I want to avoid increasing the costs for him too much.

So, if there are any other robust solutions that don’t require setting up a server, I’d definitely be interested :slight_smile:

6

You don’t need to set up a server.
Google Cloud/AWS/Azure etc all let you run cloud functions which are serverless functions that answer an http request.

7

Yes, I definitely agree.
I was considering using Edge Functions (with Supabase). When I mentioned ‘server’ I meant that I would need to create and maintain a Backend-as-a-Service, which could also incur some costs to run.

I guess that I would need to use an online solution instead of an offline one.

8

All edge functions are serverless but not all serverless solutions are edge functions.

Correct me if I’m wrong, but I think using AWS Lambda might be cheaper since it does not need to store copies in all different regions (which edge functions do to keep latency very low).

With supabase you are stuck with 25 dollar per month after your free quota, while AWS lambda is too cheap to be true.

And if there is some cool startup with a generous free plan, wait one year and watch the free plan disappear when they need cash or need to make their investors happy :slight_smile:

9

As mentioned, aws lambda is your friend. Better than having it in the code in the lambda, embed it as an environment variable on the lambda for best safety.

Authenticate users with whatever method you wish, oauth / aws cognito / whatever; use jwt tokens to ensure authorization to use the endpoint and then access it. If you want to really save costs, add aws api gateway infront of the lambda with an authorizer and you wont pay for the requests unless they get through authentication first.

Again thats all just best practise and for 99% of use cases this is all overkill, but just incase your app/plugin suddenly gets huge, you won’t run into any surprises with aws billing.

1 Like
10

You don’t want an API key in your code, surely you want a user authentication system and then you get a session cookie of somekind that’s per user? Having a shared key of any kind sounds like a recipe for trouble?