Simple API key auth

[Maxtremee]

Is your feature request related to a problem? Please describe. My team decided to rewrite our emails in mjml and use 'mailing' as preview and rendering engine that we'll self host. We do not plan to use any of the features requiring DB as we don't do mailing lists so we will be calling /api/render exclusively (also because we sometimes need to attach some files). We do, however, need an authentication system. One option is to deploy app inside AWS VPC, but that would prevent us from easily accessing preview frontend (I guess this is doable but would require filtering out /api calls at route table level and that's not easy). Other option is to use some simple auth we can control through API key in env or some API call.

Describe the solution you'd like When calling /api/render or /api/sendMail API key in header or query is checked against value stored in env variable.

Describe alternatives you've considered Best alternative would be to allow for modification of all api calls, some kind of middleware or something without the need for contributing to Your repo for changes.

Additional context I'm aware of existence of 'mailing-standalone-app' but that has the same problem - it's impossible to directly modify api routes.

I prepared simple fix for this here (I don't know how to attach it to the issue)

[psugihara]

Hey @Maxtremee that setup seems good, thanks for making the issue and sharing your code. I like this idea and your env variable solution in validateApiKey seems nice and simple.

One question... what's your reason to protect the render route?

We left it open on purpose because we thought:

• it leaks the same level of sensitive info as previews, which are convenient to keep public
• render is super fast so an attacker trying to drain your bank account by incurring serverless function calls is going to do the same damage with or without the key
• given the above, leaving it open makes it easier to get started

Do you guys have sensitive info in the templates you need to protect? I'd like to understand the use case and general threat model.

[Maxtremee]

I've created this issue after conversation with our BE developer. I guess the most important thing for him was to just have it protected in some way as it will be exposed to the internet. Biggest issue I can think of is impersonation. If someone figured out the props he needs to pass he could easily render templates, for example replace some links and send emails to users. Obviusly he could do the same with just one example of our emails, but this way would be way easier and would automatically reflect any changes we make to our templates. Now that I think about all this solution with CORS-like domain restrictions would be better but I'm not sure if this something that would have to be defined in code or somewhere in the architecture/deployment.

[alexfarrill]

@Maxtremee I just release 0.9.2 which includes this option! To use: set REQUIRE_API_KEY to "true" in your environment and then set MAILING_API_KEY to the api key / shared secret you'd like to use. render will require that api key to be passed as a query string param or header. See docs here: https://www.mailing.run/docs/rest-api#api-keys

[Maxtremee]

@Maxtremee I just release 0.9.2 which includes this option! To use: set REQUIRE_API_KEY to "true" in your environment and then set MAILING_API_KEY to the api key / shared secret you'd like to use. render will require that api key to be passed as a query string param or header. See docs here: https://www.mailing.run/docs/rest-api#api-keys

Thank you so much!