We handle security in a few ways;
- Clients are initialised with Key & ID - We advocate for keys to not be hardcoded
- The key is used for request encryption and are never sent to the server. Request hashes are also used to make sure Man In the Middle Attacks are avoided
- Custom Auth Tokens can be sent with requests - On the server side we use your provided auth callback to ensure it is valid
What do you think about the steps we take? Tokens are really important because they offer another layer of protection
They're public facing (used by clients), so it doesn't really matter if they're hardcoded or not. I can rip them out of the dom/api calls/whatever.
For the second part, https covers you alone.
Auth tokens may start to pick at the puzzle, but at that point it's not obvious what I'm gaining if I have to bake custom authorization and authentication somewhere in any case?
You have a tough battle here - the security risk is huge. I don't personally see a value add yet, especially with Twilio/Stripe who have some of the lowest cost integration in the industry.
Not impossible to succeed in the arena, but the level of abstraction doesn't feel like the right fit yet
We want to help new startups, who are both looking to get their MVP build faster and are looking for no code/ low code options.
It will take time to build out a product for the larger community but for now we are looking to small a problem.
Thanks for your feedback
Kinda the same deal on Stripe - if someone can guess / find out customer identifiers, which is a lot more likely when you're shipping them to frontends to use with your library (XSS...), they can create charges on your behalf? That's definitely a big risk fanout