How do applications which are integrated using a javascript client side sdk, secure their data?



  • Take an example of google maps. google maps provides a javascript client SDK, which means any web app running javascript can access the google maps sdk. You need to use an API_KEY so that google can rate limit your requests, and apply some quota on the requests coming from your api key. If you exceed the quota you would be charged more.

    The API_KEY has to be specified in the client side javascript, so it would be visible to anyone who uses your application, and then anyone can abuse your quota. To get around this, google suggests to add referrer based security while setting up your sdk on the google app console. You can specify a list of origins that google would accept requests from, based on the referrer header. So if someone gets your api key and tries to use that from another web application running on another domain, either google would not respond to those requests, or, the request wouldn't be added in your quota. This acts as a basic level of security, BUT, the referrer header can be easily spoofed.

    Now google maps does not have any user specific data, so may be API_KEY abuse is not that big an issue.

    Consider an application like sentry, which allows a javascript client to send events to a sentry server. Sentry can also impose similar restrictions based on the referrer or origin header, and only allow events to your sentry server from certain domains. But wouldn't it be easy for someone to directly send events to your sentry and spam your sentry server? Sentry suggests to not send any PII in the events anyway, so in case it was possible to get data somehow, at least the guidelines are clear.

    But what about products like Intercom, where the primary functionality is collecting user data in some form or the other. If someone knows the unique id of another user in intercom, they can basically see all the data from the other user, their chats , their messages etc. Intercom is a completely frontend setup, where the request to the intercom script and the intercom server happen through the front end, so if the front end can get user's data through intercom, then any other user can get another user's data by initiating intercom with the other user's id on their browser or directly using curl. There is no auth as such, there is an app key which is also completely frontend.

    I am just trying to understand how do such applications secure themselves?

    Some points about intercom:

    • it opens in an iframe, with intercom.com domain
    • possibly the api has CORS restrictions, so only requests from intercom.com domain are allowed, but these restrictions are not applicable for curl
    • it exposes some javascript methods to initialize with a app secret and you can pass a unique id for the user. The app key is frontend only so can easily be seen in any integration, and the user id can be leaked through other ways. Once leaked, I can just use this user id and the secret key from anywhere to get messages for the user.


  • Nevermind. Turns out intercom allows enabling something called Identity Verification, where everytime you initialize intercom with a user id, you need to also send a user_hash, which is generated using a secret shared between you and intercom and is an HMAC created using the user_id.

    This acts as a password that you have created for the user to log in to intercom. The unique id is comparable to your user Id, and the user_hash is comparable to your password. So your id might be easy to guess or be used in different places, the password (although being sent over the wire for initial login) would be more secure, and wouldn't be used directly at other places.

    This would make it impossible for one user to impersonate another user, as the secret can't be leaked, and if you try logging with another user_id using your user_hash, intercom would disallow.

    https://developers.intercom.com/installing-intercom/docs/enable-identity-verification-on-your-web-product



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2