At the moment variables are PUBLIC due to their position inside FORM, which is a client component.
According to email.js it's not an issue
Indeed, someone could copy your keys (a well-known issue of any public API), but they will only be able to send your templates with your content, and they will not be able to send a custom email with their content (spam), which is 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 emails from your code, 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 code. This is quite similar to how emails are usually sent via a proprietary server code and how products like Intercom or customer.io are working.
At the moment variables are PUBLIC due to their position inside FORM, which is a client component. According to email.js it's not an issue
Indeed, someone could copy your keys (a well-known issue of any public API), but they will only be able to send your templates with your content, and they will not be able to send a custom email with their content (spam), which is 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 emails from your code, 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 code. This is quite similar to how emails are usually sent via a proprietary server code and how products like Intercom or customer.io are working.