I am not sure that it is wise to do this from the front end. Aren't you exposing your emailJS credentials to everybody? My guess would be yes and it being a third party service everybody could send emails with your account and at your cost / limit. This should not be used from the frontend imho.
Indeed, someone could copy your code, but they will only be able to send your templates, with your content, and will not be able to send a custom email with their own content (spam). Which is absolutely not interesting for spammers. A better way to think of EmailJS in terms of security is not as a service that allows you to send email from Javascript, but rather as a service that allows you to create a predefined set of emails via the dashboard, and then just trigger the emails from the Javascript. This is quite similar to how emails are usually sent via a proprietary server code, and also to the way products like Intercom or customer.io are working.
Additionally, we've also developed various tools to prevent abuse – for instance, we have IP based rate limits to prevent bots from spamming, a whitelist of origin, and also support reCAPTCHA tests to make sure that a human is sending the email (although it's up to the developer to turn this feature on).
Please note, EmailJS send endpoints don't require authentication, so you can make the call to our API without worrying about security. The keys in the network tab are public keys.
These are issues of absolutely any public API. The same public API from Google Maps is no exception, as well as someone's own development. Unfortunately. Therefore, we do our best to make the price of hacking more expensive than the profit.
your credentials will not be exposed as they will be kept in .env which will not be exposed anytime and will be added to the platform you are hosting your frontend.
Sorry not really firm with react. But your frontend then makes a call to somewhere right? Either it is your backend (where react is hosted) or to the emailJS service directly both of which can be viewed in the network tab. I'd assume if the backend is actually where you host your react app you are off a bit more secure because you can implement rate limiting etc. that way but I assumed the latter one because your use case was "not worry about backend".
~Cheers
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am not sure that it is wise to do this from the front end. Aren't you exposing your emailJS credentials to everybody? My guess would be yes and it being a third party service everybody could send emails with your account and at your cost / limit. This should not be used from the frontend imho.
~Cheers
Indeed, someone could copy your code, but they will only be able to send your templates, with your content, and will not be able to send a custom email with their own content (spam). Which is absolutely not interesting for spammers. A better way to think of EmailJS in terms of security is not as a service that allows you to send email from Javascript, but rather as a service that allows you to create a predefined set of emails via the dashboard, and then just trigger the emails from the Javascript. This is quite similar to how emails are usually sent via a proprietary server code, and also to the way products like Intercom or customer.io are working.
Additionally, we've also developed various tools to prevent abuse – for instance, we have IP based rate limits to prevent bots from spamming, a whitelist of origin, and also support reCAPTCHA tests to make sure that a human is sending the email (although it's up to the developer to turn this feature on).
Please note, EmailJS send endpoints don't require authentication, so you can make the call to our API without worrying about security. The keys in the network tab are public keys.
it supports only reCAPTCHA v2 not v3 why ? @xr0master
In order not to go deep into the reasons, I will simply answer that there are several problems.
As a result, our customers will contact our support team instead of Google support, which is why we decided not to add it yet.
ok
I see! Thanks for chiming in. Good to see even the devs of the service care enough to address possible issues! Kudos!
These are issues of absolutely any public API. The same public API from Google Maps is no exception, as well as someone's own development. Unfortunately. Therefore, we do our best to make the price of hacking more expensive than the profit.
your credentials will not be exposed as they will be kept in .env which will not be exposed anytime and will be added to the platform you are hosting your frontend.
Sorry not really firm with react. But your frontend then makes a call to somewhere right? Either it is your backend (where react is hosted) or to the emailJS service directly both of which can be viewed in the network tab. I'd assume if the backend is actually where you host your react app you are off a bit more secure because you can implement rate limiting etc. that way but I assumed the latter one because your use case was "not worry about backend".
~Cheers