Environment variables are potentially vulnerable to a malicious deploy preview about netlify-faunadb-example HOT 3 CLOSED

yup, thats about it!

i'll be honest that i havent precisely done this myself because i havent needed to but this is exactly how it would work in theory. if you try it and run into any problems (including security concerns), please report here and i'll do my best to help you research/resolve.

we have more on this i can't talk about coming soon - stay tuned

from netlify-faunadb-example.

thanks for your concern!

env vars can have contexts - https://www.netlify.com/docs/continuous-deployment/#deploy-contexts

so just be sure that your prod stuff is in a prod context and your deploy preview stuff is in a different one.

pretty neat huh!

from netlify-faunadb-example.

Thanks, @sw-yx – we figured Netlify had set up some way to avoid this problem, just weren't sure what it was.

It sounds like a good practice for a public project that talks to an API would be to do the following:

• Create a dummy account for whatever service is being used (Airtable in this case)
• Put the access key for that account into netlify.toml in [context.deploy-preview.environment]. This will be exposed in the repo for all to see, but it's only dummy data
• Keep the production access key in the Netlify admin; users who deploy their own copy of the app to their own Netlify instance will have to provide their own production data (their own Airtable account or whatever).

Is there anything I'm overlooking here? Thanks again!

from netlify-faunadb-example.