How to Securely Store an Azure API Secret in an ArcGIS Experience Builder Custom Widget?

[Fendley]

Hi everyone,

I’m developing a custom widget in ArcGIS Experience Builder Developer Edition and need to integrate it with Azure APIs. However, I want to ensure that the API secret remains secure and is not exposed in frontend JavaScript code.

Since Experience Builder runs in the browser, I know that storing secrets directly in the frontend is a security risk. I’m looking for best practices to handle API authentication securely within this environment.

My main questions:

What is the recommended approach for securely handling API secrets in Experience Builder?
How have others implemented secure API authentication in their custom widgets?
Are there any Esri-recommended methods or existing solutions for this?

I’d appreciate any insights from those who have tackled this issue before.

Thanks!

[PartyPelican · Accepted solution]

I don't know if there is a way to hide it within the frontend. I'm curious what methods are out there too.

Another approach would be to set up a custom backend to serve as your proxy. Your backend server can have your API key, and your frontend widget queries your backend server. You can lock down communication to your backend with cors or other methods. 

[JeffreyThompson2]

I don't have a good solution for your question, but I will say that the deployed version of your code has been complied and minified so there is a certain amount of security through obscurity built-in.

The best advise I can give is to use general best practices with an API Key. It should created only for this application and authorized with a minimum number of functions needed and only to work on the correct URL. It would also be good if you could set up alerts for unusual activity on the server side. 

[TimWestern]

So I reread this a couple of times.

You do not want the API Key in client code.  What you may need to do is create a middle 'hosted' backend method somewhere that has access to those keys and can make calls (only calls it is setup to do) to funnel data to Azure APIs.

If you were building a pure react app, in theory you could bake that into the backend built that serves everything else where its hosted, but because the custom widget whether its in enterprise or AGOL would technically run inside of that context, and you may not be able to make changes in EXP's backend directly that could feel challenging.

I wonder if a custom Task could be created and published to the portal that could be called from the Custom Widget and still make use of the token/auth structure that ArcGIS and EXB provide out of the box?