Question: How to keep your application insights connection string secret?

[paalandreassen]

I'm new to application insights in frontend SPA applications. But I don't feel comfortable putting the application insights connection string for all to see in the react code as the samples suggests.

What's to prevent anyone from taking the connection string and use it to drive up my hosting costs or log lots of false errors and exceptions?

Is there another way to do this? Or am I overthinking things?

[timtucker-dte]

Haven't dug into it myself, but it does look like there's an authenticated option:

"If you want to protect your Application Insights resource from misuse, the ingestion endpoint provides authenticated telemetry ingestion options based on Microsoft Entra ID."

https://learn.microsoft.com/en-us/azure/azure-monitor/app/connection-strings

You could also set custom endpoints for ingestion and set up a proxy that filters things before passing them on.

[MSNev]

What's to prevent anyone from taking the connection string and use it to drive up my hosting costs or log lots of false errors and exceptions?

This is a known issue, but generally as the connection string only grants any potential "bad actor" the ability to "submit" telemetry, it's generally not considered to be (specifically) a security issue.

And while cost based attacks are possible they are rarely (even for huge internal Microsoft sites) performed as there are several ways to control costs if this scenario occurs

• You can enable server side "Sampling" which can limit the amount of events that are ingested (ie. all requests are sent to the Azure Monitor endpoint, but it drops them on the floor)
• You can create a proxy and use the "Microsoft Entra ID" is part of the solution, but this is really just "shifting" the problem as
  • While this endpoint can obfuscate the connection string, you still need to tell the SDK on your application where to send the events
  • So now this endpoint needs to "verify" that the sender is a valid sender before passing onto Azure Monitor (using the Entra ID), and if you don't perform any validation then you would be not only incurring the cost of the ingested events but also the CPU and network traffic of this service.

Other potential options (not fully supported) exist around the usage of an Entra Id, but this introduces a timing and/or security issue related to

• When is the token available (any events collected and sent before this authentication completes will get rejected (because the endpoint doesn't receive any token))
• The "Authentication" token gets immediately exposed once it's present on the web page / client, and any bad actor can now use it directly

Additionally, when ingestion traffic is authenticated, and the sender (the client) is not (doesn't have any token), then you won't receive any telemetry about what going on (because it's all rejected), so you actually wouldn't know if

• a bad actor is using your system to do stuff they should not (depends on what events you are collecting if this is a valid option anyway)
• You have a bug in your code (around the authentication) and your usage drops to the floor (or a race condition so you still get some data) but no JS errors to help with the "failed" case.
• If any part of you site is "anonymous" (like before the user logs in), you may lose telemetry (unless you are using a Proxy like mentioned above -- but then you have the same "Authentication" issue for yourself)

I've worked on many front end systems and implemented many "verification" steps (simple CSRF to full authentication) and the anonymous flows are the trickiest to "restrict" as any determined bad actor can always work around anything you put in place, especially it they just want to spam you with some bogus / overloaded events -- ie. they don't have to use a browser and therefore they are not restricted to CORS or any other browser imposed constraints, they can just fire up a simple app that uses HTTP(S) requests to obtain your details and then send them at whatever endpoint exists as all "client" traffic should always be considered as untrusted.