[hashamali]

Quick question regarding frontend integration. I see that you can embed a widget that requires an API key and the currently authenticated user's email. Does this mean that if I'm a malicious user, and I edited my local Javascript to swap the email with another user's email, I could view the other user's notifications?

[unamashana]

There are two ways to handle that. One is to use your external ID, if they are UUID or something random. That's security by obscurity.

The other (and better way) is to initialize the embed with an HMAC generated on your backend using the API Secret. You can do this with both email and external_id - https://developer.magicbell.io/docs/turn-on-hmac-authenticat....

[thrwaway2020aug]

Hello! Great product and congrats on the launch!

I wanted to pile on a little bit here and say this paragraph isn't really comforting to me:

> While unlikely to happen, it is possible for a savvy user to open their browser's developer console, obtain your MagicBell project's API key from your website's source, initialize the widget on their own website with your API key but with a different user's email (if its feasible for them to guess one) and start viewing notifications of that user.

I suspect this was done for developer experience reasons? You seem to know it's not secure to pass in an email directly, especially if anything sensitive is coming across in notifications.

For me at least, allowing the non-HMAC configuration makes me wonder what other security corners have been cut. I'd rather that option didn't exist and the company took a more security-forward stance.

[unamashana]

Edited the doc to remove the bit about this scenario being unlikely. We take security very seriously and would be happy to get feedback on the new copy (or any other aspect of MagicBell).

[thrwaway2020aug]

I see your point with Intercom, but it feels like you're arguing that two wrongs make a right. It doesn't make me think MagicBell takes security very seriously, but perhaps I'm just paranoid.

Regardless, the copy on the website is improved. You may also want to add a warning and link anywhere your website documents the "userEmail" option.

On another note, in terms of the implementation here, I'm surprised you're asking users to use HMAC and base64 manually, instead of using standardized JWTs. Did anything in particular motivate that decision?

I quite like the product overall - I think it's very clever how you componentized everything. The security decisions just have me concerned.

[josuemontano]

Hi thrwaway2020aug, indeed we could have made a better choice in that regard. Actually we plan to move to JWT in the coming months.

Be asured that we take security very seriously. We are in conversations with banking platforms, and with that in view, we are planning to get a SOC 2 certification very soon.

[unamashana]

I agree that this can be worded better and we will certainly do so. Thank you for your feedback. It's fairly common to see this pattern of HMAC off by default (ex: Intercom) to help people test their embed. Atleast at the moment we are in touch with everyone going live and make sure this is communicated to them (doing things that don't scale).