
Ask HN: Securing third-party API keys within frontend in 2019 - somada141
Hi all,<p>I&#x27;ve only been working with frontend for a few months and one thing that has me stumped is handling third-party secrets required by the app, e.g. access-tokens or API keys required for interaction with MapBox [0] or Sentry [1]. I&#x27;m only referring to client-side JS, where to my understanding any bundled secret is effectively compromised, as opposed to server-side rendered websites<p>While the most secure solution I&#x27;ve come across seems to be about having the frontend communicate with these services via a proxy, e.g., Nginx proxying requests to those services after validating the JWT token Auth0 [2] issues to the frontend client, this solution seems to be poorly supported. For example only Nginx Plus appears to support JWT validation.<p>Thus I&#x27;m truly curious, how do you secure your third-party secrets needed by your frontend in 2019?<p>[0] https:&#x2F;&#x2F;www.mapbox.com&#x2F;
[1] https:&#x2F;&#x2F;sentry.io
[2] https:&#x2F;&#x2F;auth0.com&#x2F;
======
phillipseamore
Usually an API key that is supposed to be used on the frontend would be locked
down to a domain (checking the Origin or referrer header). Otherwise you are
expected to either have your own service that communicates with the API or
proxy it. IIRC there are some modules for nginx for JWT validation though
that's not something you would need, you could check the headers as above.

~~~
somada141
On the first point what’s stopping a bad actor that found the key in the
source code from faking those headers?

As for having to ‘wrap’ third-party services that seems like a cumbersome
solution.

I guess one way to go would be to use an API gateway like Kong [0] which
supports JWT validation out of the box but performance-wise I always found
Nginx to be superior.

[0] [https://konghq.com/kong](https://konghq.com/kong)

