I am building a frontend application using react and I am wondering whether it is risky to expose API endpoint URLs (ex: https://myapi.com/v1/getitems) on GitHub, assuming that the endpoint has several security measures that are not exposed such as CORS and JWT Token Bearer Authentication. I would assume not, since, if someone were to take the endpoint and send requests, they would need a token and be allowed to do so by CORS.
Is there any security risk in doing so?
Yes. Don't add the base url of your api on github in plain view. Even though you might have CORS and Authorization, that doesn't stop a malicious actor to keep spamming your back-end.
What you do is create a .env file in your root folder. You can use a library like #beam-australia/react-env and there are others as well.
You add in the .env file the values that are important for your environment and that are usually secrets, and you want them to not be visible in your code. You do it like so:
API_URL="https://myapi.com/v1"
And then you access this variable in your code with env("API-URL") ( in the #beam-australia/react-env case, but others libraries work the same). Keep in mind that you need to add .env in .gitignore so that the .env file is not pushed to github.
Regarding requests, you can make one like so:
fetch(`${env("API_URL}/getitems`)
This way your code will be stripped of the API's base url and if someone sees your code it will see only the endpoint, not the full url.
Publishing the code of the API is risky on its own. Somebody can find a vulnerability in it and instantly hack it. If you add the address of the API to the code you help this kind of attacks. They can get the address with some investigation; OSINT and social engineering too, but better to reduce the attack surface.
As of the secrets, they must never be near to the code, because you or another developer can accidentally publish it. It happened too many times with many developers, so better to take this seriously. If you want to keep the address in secret, then you must extract it from the code and put it in the configuration of the production environment which is imported from a totally different location than your code. Using environment variables like Alex suggested is a good idea for this. Nowadays it is common to use docker, which has a way to manage secrets, so you don't need to reinvent the wheel: https://docs.docker.com/engine/swarm/secrets/ Another aspect that the configuration belongs to the actual instance. In OOP terms you want to describe the injected properties of an object in its class or in a global variable, which is an antipattern.
As of client side REST clients like javascript applications running in the browser or Android/iOS apps, you must not publish your secrets along with the REST client, otherwise it is not a secret anymore. In that case you need a server side part for the REST client and for example sign and encrypt JWT there with a secret key. It is your decision whether this server side part of the REST client sends the HTTP request to the REST API and in that case you can hide the URI of the REST API or it just manages the JWT and the client side part of the REST client sends it. If the server side part of the REST client sends the HTTP request to the REST API, then you can even use traditional sessions with session cookies between the client side and the server side parts of the REST client, but you cannot use them between the server side part of the REST client and the REST API where the communication must be stateless. Though it does not make much sense to have a separate REST API if you don't have multiple different REST clients in this scenario e.g. browser clients for JS and JSless browsers, Android and iOS clients, fully automated clients running on servers, etc. So don't confuse the REST client - REST API relationship with the browser - HTTP server relationship, because they are not necessarily the same. Most of the REST clients run on servers, not in the browser.
Related
When chunking client code with webpack, i.e. using React lazy loading, is there any way to restrict access to a particular chunk by gating it behind some sort of authorization credentials?
All approaches I've seen so far have involved client-side code that only renders a given component when certain conditions are met on the client side (e.g. something along the lines of this as a simple example). This does not strike me as particularly secure, more "security by obscurity" than anything: a motivated attacker could modify either the client code they do have, or perhaps their own memory, to force the browser to request the additional chunks - or just send requests to the server using some other agent.
Is there any way to enforce this on the server side, in the CDN that serves the client code? Perhaps some way to attach credentials to the requests to obtain additional chunks such that the CDN could verify that the client is indeed authorized to be sent the code? (The server side authorization would be trivial enough to implement myself, but I don't know of a way to have the requests actually attach the credentials - that whole mechanism is opaque and I can't find any documentation.)
Alternatively, is there some justification for the client-side-only approach actually being secure?
What's the best practices to hide or prevent the user see the credentials (implemented in WebService calls). The development is ReactJS and use Heroku to deploy the WebApp.
I have this code:
I want to prevent the user can see the credentials and some security details.
I started using the node module dotenv recently and really like how easy it is to use. All you need to do is install it and create a .env file with your environment variables like this:
.env
SECRET_KEY=123456
ANOTHER_KEY=78901
Then, require it as early as possible in your application:
require('dotenv').config().
I do this inside my server.js file (or whatever you name it).
That's it! Anything stored in the file can now be accessed by doing process.env.{name}
For example:
let secret = process.env.SECRET_KEY;
console.log(secret); // 123456
This is not really possible to do in a client side because all the HTTP calls can be easily visible in Network tab in Chrome Inspect Elements(or any web browser).
I would suggest you work on the security so you don't care if a user will see your HTTP endpoints or not.
You can also consider making your HTTP request on a server which will act as a bridge between your client and an API.
Contemplating building an Angular 2 front-end to my website. My question is not necessarily related to Angular but I want to provide full context.
Application logic that displays content to user would shift to the client. So on the server side, I would need to expose data via a RESTful JSON feed. What worries me, is that someone can completely bypass my front-end and execute requests to the service with various parameters, effectively scraping my database. I realize some of this is possible by scraping HTML but exposing a service with nicely formatted data is just a no-brainer.
Is there a way to protect the RESTful service from this? In other words, is there a way to ensure such service would only respond to my Angular 2 application call? Authentication certainly isn't a solution here - I don't want to force visitors to authenticate and the scraper could very well authenticate and get access, anyway.
I would recommend JWT Authorization. One such implementation is OAuth. Basically you get a json web token ( JWT ) that has been signed by an authority you trust that tells about the user and what resources they can access on your api.
If the request doesn't include an Authorization token - your API rejects it.
If the token has been tampered with by someone trying to grant themselves privledges after the token is signed by the authorization authority - your API rejects it.
It is a pretty cool piece of kit.
This site has information about OAuth implementations in different languages, hopefully your favorite is listed.
Some light bed time reading.
There is no obvious way to do it that I know of, but a lot of people seem to be looking at Amazon S3 as a model. If you put credentials in your client code, then anyone getting the client code can see them. I might suggest that you could write the server to pass a time limited token back to the browser with the client code. The client code would be required to pass it back to the server for access. This would prevent anyone from writing their own client code, as only client code sent by the server would work, though only for some period of time. The user might occasionally get timeouts, but that depends on how strict you want to make the token timeouts. Of course, even this kind of thing could be hacked by someone making a client request to get a copy of the token to use with their own client API, but at that point you should be proud that someone is trying so hard to use your API! I have not tried to write such a thing, so I don't have any practical experience with the issue. I myself have wondered about it, but also don't have enough experience with this architecture to see what, if anything, others have been doing. What do angularJS forums suggest?
Additional References: Best Practices for securing a REST API / web service
I believe the answer is "No".
You could do some security by obscurity type stuff. Your rest API could expose garbled data and you could have some function that was "hidden" in your code un-garble it. Though obviously this isn't fool proof, but if you expose data on a public site it's out there regardless of server or client rendering.
I am trying to use Play 2.x with backbone.js for a project. My intention is to create RESTful APIs at the server end (all response bodies are in JSON and all request bodies are in JSON also).
I would like to use Facebook OAuth (server side) to authenticate my requests. For this purpose I'm using play-authorize for OAuth. The issue I am having is that the user session information is stored in the Session Object in Play. I don't really want to use play-templates in my HTML code, how can I use the Session Object on the client side without the play-templates.
Also what measures can I use to prevent CSRF/XSS attacks while using Play.
Maybe I'm misunderstanding your question, but be aware that Play is stateless. That means that the "Session" is stored in a cookie that gets sent to the server. You can store string values to that cookie and access them from the browser.
Now, you don't want to store critical values in there, but something that the server side code recognizes and lets you work with to solve your problem.
i've just read a few posts on hiding Silverlight code in some way.
Main conclusion was that you can obfuscate it, but you can't realy hide it, so secure things must be done at the server.
But then, anyone can see via Fiddler what kind of data is posted to a particular webservice. For instance, they can see that i'm calling UpdateCustomer.asmx.
And if they do, what can i do to stop them from calling that asmx too?
Is there a way to allow only 'my silverlight app' to call that method?
Nope. Someone can always reverse engineer your Silverlight application to steal whatever authentication credential you use. You can make this reverse engineering process more tedious than it would be otherwise, but you can't make it impossible.
Why is it a problem if someone accesses your URL from a custom client? You're authenticating the user, right?
I suppose if you wanted to be really paranoid, you could marshal all calls from your client application through one web service endpoint and encrypt the payload...something like:
Client application hits endpoint "givemeatoken.asmx"
Server generates some key token
Client encrypts all calls using said token, passing them to single endpoint "onlyservice.asmx"
Server decrypts payload of calls using token, and routes calls to "real" web services.
Server retrieves results of call, re-encrypts using token, and passes back to client
Client decrypts results and does what it needs to do.
But that's just crazy talk....and kind of pointless, since you could reverse engineer the Silverlight code itself to figure out what the "real" services would be. If you really want to secure your app, use authentication; both on the client side and the server side (i.e., calls to the services require an authentication ticket of some sort)