<p>I serve a react app using a golang backend built with the http package but I can see that the API endpoints are open for anything to query not just my react app. Is there a way to limit who hits the endpoints to just my react app?</p>
<hr/>**评论：**<br/><br/>Kraigius: <pre><p>If it's a website, CORS? Otherwise probably a token.</p></pre>hobbified: <pre><p>CORS assumes that the client is willing (i.e. it's a browser that wants to protect the user from unwanted cross-domain communication). It's not a reliable way to protect the <em>server</em> from anything.</p></pre>Kraigius: <pre><p>That's true. I think that depending on your infrastructure you could do something to get away with it but if you let the clients communicate directly to the backend, CORS isn't the answer.</p>
<p>Like you said, CORS is more of a minor deterrent than anything.</p></pre>LadyDascalie: <pre><p>A coupe of ideas for you to look into:</p>
<p>1 - Make use of <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">CORS</a> to restrict which domains can access your API.</p>
<p>2 - Make use of <a href="https://jwt.io/introduction/">JSON Web Tokens (JWT)</a> to authenticate your calls if necessary.</p>
<p>3 - Make use of <a href="https://oauth.net/">OAuth</a></p>
<p>4 - Make use of API Tokens</p></pre>shadowh511: <pre><p>number 2 and number 4 are the same thing</p></pre>LadyDascalie: <pre><p>Not so, JWT is a very specific kind of token and protocol, a classic api token or key as I meant it can simply be something like <code>/endpoint?apiKey=123xyz</code>.</p>
<p>Calling it an API Key would have been clearer, though!</p></pre>shadowh511: <pre><p>And then every API key is in your access logs.</p></pre>LadyDascalie: <pre><p>It all depends on what it is you are trying to achieve. Everything has a convenience-to-risk factor you have to take into account.</p>
<p>Some people do it via headers, some people do it via url parameters, but like it or not, it is still a valuable and common way to handle keys.</p>
<p>Example, <a href="https://www.twilio.com/docs/api/rest/keys" rel="nofollow">Twillio</a> does it for some of their API calls.</p></pre>shadowh511: <pre><p>Can't you also check if a JWT is valid in the same way? Or if you are that insistent on API keys why not put that in the JWT?</p></pre>LadyDascalie: <pre><p>Oh, I think you misunderstand, I don't mean to say that you have to use this, I'm just saying it's part of the options (though admittedly a pretty crappy one for authenticating a front-end).</p>
<p>You can indeed use JWT's for this, you are absolutely correct!</p></pre>shadowh511: <pre><p>I think it's a bad idea to suggest putting anything in a Universal Resource Locator (URL) that has nothing to do with the actual location of the resource (exception for interop with old services that still use HTTP basic auth for some reason, my point is don't write new things that do this). This includes things like API keys, which are secrets. Secrets go in the parts of the request designed for secret things, also known as headers.</p></pre>LadyDascalie: <pre><p>Headers are not safe either, and all keys do not have to be secret, they just have to be able to be cancelled and changed easily. This is one of those examples.</p>
<p>If you setup any sort of api key, headers or otherwise, the advantage is that it's incredibly easy for you to change the key on the server side and automatically invalidate any and all calls still using the previous key.</p>
<p>Again, it's a risk vs convenience situation, this setup is extremely simple and easy to manage, but not the best, nor the safest.</p>
<p>It's just food for thought</p>
<p>edit: Headers are safe<strong>ER</strong> over https, of course</p></pre>ugurgungor: <pre><p>You need a authentication mechanism, you could use jwt <a href="https://github.com/dgrijalva/jwt-go" rel="nofollow">https://github.com/dgrijalva/jwt-go</a></p></pre>SeerUD: <pre><p>No matter what you do really, if your React site is completely static, if your React app can access your API, so can anyone else.</p>
<p>If your React app was loaded into a page that was generated dynamically however, you could make it slightly more difficult to use. You could inject some kind of short-lived token into the page that would serve as "authentication" or something. The thing is, not only will this complicate your app, it still won't really stop people from using your API. That token would still have to be sent somehow, and someone could still easily make something that picked that out of page to start making requests. Like I said, it would only make it more difficult for them to.</p>
<p>What is your API doing, out of curiosity? If it's something like a blog, then why does it concern you? If it's something that has a user system, then making users log in would be enough.</p></pre>sacrehubert: <pre><p>Maybe I'm misunderstanding your problem, but you could generate per-user OAuth credentials and then revoke those that are being abused.</p></pre>recurrency: <pre><p>This is sadly the flipside of "fat clients". If it's REALLY critical from a security standpoint, I would dump react and render it server side. That way you are always in full control. </p></pre>semi-: <pre><p>What problem ars you running into with having your api endpoints exposed? Maybe the solution is in factoring that in with designing the API</p></pre>RealJulleNaaiers: <pre><pre><code>if requestIsToOtherEndpoint() {
send 404 response
}
</code></pre></pre>
