1

I will implement a chat bot web app that can be used on other websites. I plan to to host this app in www.mysite.com and customers will be able display this chat bot inside an iframe on their sites. Website owners that want to use my chat bot will have their accounts on my site.

First, I plan to get the domain which the chat bot will run from customers and bind it to their customer ids. When they open the iframe with something similar to www.mysite.com?customerId=12345 I will validate if the domain matches to the id on my side. It looks like the method being used by other chat bot apps (intercom, etc).

But I'm not sure what kind of authorization method I should use. My customers can have their own users. And each user can have their own chat bot. None of the users should be able to access to other users' bots. What could be the best way to use the authorization provided by my customer, securely?

Customers can handle part of the security issue by assigning chat bots to their users. And prevent users from seeing others' bots. But I cannot have a URL like this; www.mysite.com?customerId=12345&botId=321 because it would allow all users to access to that bot when its id is compromised.

1

2 Answers 2

2

There are a few ways to pass data between a parent and a child (framed or popup) page, but the best in general is the window messaging API which allows secure cross-domain communication if both sides coordinate to enable it.

Note that you obviously still can't put any data into the messaging - in either direction - that a user isn't allowed to know. There is no way to do this safely on the web and it should not ever be attempted.

It is essential that your iframed page verify that the messages are coming from the expected parent page domain (as determined by the URL of the frame). Otherwise any page could embed yours and send messages claiming to be some other (legitimate) parent domain. Obviously you don't want this. Fortunately, the window messaging API supports only sending messages to, and accepting messages from, a specific other domain.

0

This is the flow that we implemented.

  1. Generate API ID and API Key for the customer
  2. Whenever the iframe is opened, the client generates a signature using the api key in backend . Timestamp + client_id+ customer_id.
  3. Passes all these to the iframe in url, timestamp, client_id, customer_id. You can add more parameters if required.
  4. Every endpoint on backend validates the signature.

Unless the api key is lost, this works. Looks ugly but works

2
  • 1
    Welcome to the community. Isn't it vulnerable to replay attacks, token stealing and IDOR attacks then? Feb 28 at 10:32
  • Yes, It's not perfect but we had hard time finding alternatives. We did implement One Time token for these issues. Once it's verified, it's discarded by server for lifetime (30 mins) ensuring same signature cannot be used again + API key rotation. Not sure how we could have made it better. I have to implement this again for my new org so I'm open to suggestions.
    – AbhiKB
    Feb 29 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .