Alternative way to protect your Application Insights “Instrumentation Key” in JavaScript

3 comments

Discussion is closed. Login to edit/delete existing comments.

• 

  tim October 12, 2020 0

  Collapse this comment Copy link

  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...

  Read more

  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.

  Read less
• 

  Tushar Singh Bora September 21, 2020 0

  Collapse this comment Copy link

  Any further update on this it’s 2020?

• 

  Dan September 2, 2020 0

  Collapse this comment Copy link

  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...

  Read more

  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.

  Read less