All things software & product, honestly - FrontEnd, BackEnd, DevOps, ML - as long as we're solving massive problems.
My code is used by millions of users globally - Potatoes make me happy
I believe a solution like this would work due to domain restrictions. I.e you can take the keys and user ID, but can only send/activate the service if the domain matches
Yeah that's somewhat a relief 😅. As a bad actor, I could still send thousands of messages, potentially causing increased cost or worse, the email account getting blocked.
This service seems convenient at first, but with today's serverless solutions it's worth building a backend solution that is properly secured.
Hi, at first I want to thank you all for taking part in discussion.
In my project I have used webpack and gulp thanks to what finished JS code is bundled and minified, which makes searching IDs harder.
Problems with visible of API is not a problem of this package, but of the entire front-end. Even when you want to fetch f.e Pizza API, you might be obliged to pass your private key, which later will be visible in dev tools.
In my article I have bundled and minified code which is in seperated file. It is still more safer than keeping everything in HTML file, what was shown on this documentation part
I'm curious to understand the security of this solution. If I visit your site, could I not take your
USER_IDand send emails on your behalf?I believe a solution like this would work due to domain restrictions. I.e you can take the keys and user ID, but can only send/activate the service if the domain matches
You could probably use that USER_ID from the devtools console of the appropriate domain and send whatever you want, impersonating the domain owner.
Edit: the FAQ of the service indicates you can only send predefined template emails, but template variable injection could be abused.
Yeah that's somewhat a relief 😅. As a bad actor, I could still send thousands of messages, potentially causing increased cost or worse, the email account getting blocked.
This service seems convenient at first, but with today's serverless solutions it's worth building a backend solution that is properly secured.
There is no way you can solve this problem by creating your solution. As a bad guy, I can just as well call your API for your form.
Hi, at first I want to thank you all for taking part in discussion.
In my project I have used webpack and gulp thanks to what finished JS code is bundled and minified, which makes searching IDs harder.
Problems with visible of API is not a problem of this package, but of the entire front-end. Even when you want to fetch f.e Pizza API, you might be obliged to pass your private key, which later will be visible in dev tools.
In my article I have bundled and minified code which is in seperated file. It is still more safer than keeping everything in HTML file, what was shown on this documentation part
Very true. An OAuth token should always be used in these API scenarios which does more than only being used for a getter.
What prevents from calling the API using an access token (from OAuth)?