Alternative way to protect your Application Insights “Instrumentation Key” in JavaScript
Pam Lahoud
This post on Application Insights and protecting your instrumentation key comes to us from Premier Developer consultant Adel Ghabboun.
Application Insights instrumentation key can be used in both Server and client side. Using the instrumentation key in the server side is secured and no one can see it. The opposite happens on the client side “JavaScript” where the instrumentation key is exposed, and anyone could see the key whenever they use fiddler to trace the calls. Knowing that, the instrumentation key doesn’t allow anyone to read anything from anywhere, it can only be used to write data to a resource.
Currently, there is no way to protect an instrumentation key in JavaScript. Every JavaScript based analytics tool has this issue so anything you do to protect it in the browser would be visible at debug time in the browser anyway.
At this point the risk is minimal since the most that could happen is unwanted data gets sent to your Application Insights resource, but to recognize whether the incoming data is real or not, you can enrich the data with properties that can be included in the queries and proves it is real.
Alternatively, the most secure way would be to send data from the browser to your custom API on your server then forward to Application Insights resource with the correct instrumentation key (see diagram below).
Light
Dark
3 comments
This seems to be the only documentation I can find that indicates the iKey provides Write only access to application insights, and it was written in 2017. Is the iKey still write only and are there any new ways to protect the iKey that Microsoft has implemented?
For what it’s worth, it does look like App Insights now supports adding a VNET which lets you limit read/write operations coming from your VNET/Internal network. Of course for public sites’ front end code, that won’t work.
Any further update on this it’s 2020?
It is of great concern to me that a bad actor would get it’s hands on the intrumentation key and starts pushing ‘bad data’ into the logs. It has been suggested here and there that you should expose the instrumentation key only to authenticated users is not really a solution to the problem as that prohibits the ability to collect telemetry on unauthenticated users.
I would like to see some official documentation on https://docs.microsoft.com/ as to what you would need to do in both the frontend JS library to specify an alternate domain for the queries to go to so they can be redirected to your backend custom api. Also I would like to know what needs to be done in the backend to be able to achieve this.
The alternative I see is that you use a split instrumentation key for the backend and the frontend but that isn’t really a solution as it will split up the collection and you lose many of the benefits (ex. drilling down from frontend to backend) that you would have when you would collect both the backend and the frontend to the same application insights instance so that is not really an option. Most of the benefits lost are actually features we would like to be using insights for.
Another alternative is to offer a secondary instrumentation key for the instance that can be rotated so when a bad actor appears and steals the key the old key can be invalidated. Moving to a new insights instance is way more work than rotating a key for a bigger application and you lose important historic/smart detection training data.
What would be even nicer is that there could be a new endpoint that can be called in the backend that allows for the creation of temporary tokens that can be used by the frontend and are unique per connection so the key does not leak to the frontend.