To save the token in localstorage to avoid logging in every time when launching the app, I found the following link. However, is it secure?
Ionic - How to store session token as globally (for app) accessible variable?
Storing the token simply in local storage may be a secuirty threat you may use Crypto to encrypt data and then decrypt using a secrate key when you need it Something like:-
var secretKey = 'your-secret-key';
var encryptedData = CryptoJS.AES.encrypt(yourtoken, secretKey).toString();
store this encryptedData
and when you need it back
var encryptedValue = valuefrom your local;
var decryptedData= CryptoJS.AES.decrypt(encryptedValue, secretKey)
This may help
No, localStorage alone is not secure enough for the storage of access and/or session keys. You should encrypt the data (and not store the encryption key in your app code).
You can use the Cordova SecureStorage plugin to do this:
https://github.com/Crypho/cordova-plugin-secure-storage
It works pretty much the same as localStorage and lets you simply set and get key/value pairs.
Since the Android implementation of this secure storage uses the KeyStore, the users must have a secure screen-lock set (like fingerprint, pattern or PIN). The plugin provides functions to check this, so you will be able to give a warning (or block login) if this is not the case. Without a locked screen there is no way to save your keys in a secure way on Android.
Related
I am building a react application with firebase integration and the environment variables we are using can be inspected out by taking the page source of the page in a deployed website.
I am interested in knowing some ways to make it safer. the only way I can think is of take values from an API so that its not shown with the code at any point.
To connect to firebase I can use the reserved url method to automatically connect.Firebase remote config allows you to store key value pairs. I was thinking of moving all my env variables out to remove config setup and use it from there. So I can remove my .env file altogether and avoid exposing any hardcoded values.
Have anyone tried this already? what could be the recommended way to make .env values safer?
You should never load any values that you don't want users to be able to access into the browser, period. The browser is an open book and while you may be able to obscure values by changing where and how they are loaded, you cannot prevent a motivated attacker from reading absolutely anything and everything you do on the client.
This is why Firebase is designed to have API keys and configuration that are safe to be publicly readable -- when you write security rules you are essentially drawing boundaries around what clients can do.
Firebase Remote Config can and should be used for values that are safe for clients to have -- things like feature flags or environment-specific URLs for APIs. It should not be used for sensitive things like private API keys and secrets.
I want to clear this issue. I'm new to react js. but I need to store some sensitive data in frontend. just like database name, database password, and database username. I have used universal-cookie and local storage also. but it seems like not secure. because anyone can edit that data if they inspect the page and open the cookie tab. I just want to know if there is a way to make these cookies uneditable or suggest to me if there is a better way to keep this data in frontend?
Thanks in advance
Normally sensitive data are not saving on frontend.
best way is you can call this from server using http request.
Or you can use local storage,cookies,session storage etc.
env setup is another way.
Or you can use thirdparty storge for this, many free & trusted resources are available
Ideally you do not want to, you should always send it encrypted from your BE> But if you must you can create a .env.local file at the root of your react project and put all your variables there. The variable names should start REACT_APP. there should be NO space/quotations around your values in this file
REACT_APP_DB_PASS=your_pass
REACT_APP_DB_ID=your_id
and then you can access them from the process.env object like this
process.env.REACT_APP_DB_PASS
Sorry if this might be a bit of a trivial question, but I wanna be sure and couldn't exactly find a definitive answer online.
I am writing a small app that uses Mapbox, and I am using react-map-gl for it. They require the access token on the client side, so they suggest using an environment variable. My question is would it be okay to simply create a .env file in the front-end folder and put the variable there?
Thanks!
You can't get away from revealing API keys on the front end. If someone wants to dig around in your source code, they will find them.
However, you should always configure any API key that is visible on the Internet to be restricted to specific referrers, i.e. the domain of your website.
Usually this is done during creation of an API key through your provider's dashboard.
For Mapbox, you can read the documentation on restricting API tokens here. It states:
You can make your access tokens for web maps more secure by adding URL restrictions. When you add a URL restriction to a token, that token will only work for requests that originate from the URLs you specify. Tokens without restrictions will work for requests originating from any URL.
(emphasis my own)
They require the access token on the client side, so they suggest using an environment variable. My question is would it be okay to simply create a .env file in the front-end folder and put the variable there?
There are two reasons one uses environment variables in front-end development:
As a convenience, to keep environment-specific configuration removed from source code.
To keep sensitive information out of source code. You shouldn't commit API tokens or other similarly sensitive details to your version control.
Using environment variables in front-end code will not to keep their values secret from the end user. Whatever the value of an environment variable is at build time will be visible in the compiled output.
I am working on an assignment for a dummy phonebook app, which is an "extra points" part of a test for a local frontend job opening. I did some basic apps with angular before, but I always used it along with php and mysql. For this project the requirements state that I can't communicate with a server, so I need to store, edit, delete and search through data without a real database.
I don't even know what options are out there to achieve something like that, neither which one should I choose. I am looking for a simplest tool that could help me achieve those requirements, preferably one that has decent documentation that can help me get up and running as soon as possible.
You can use simple local filesystem and store objects as JSON using JSON.stringify() and parse them back using JSON.parse(jsonstring)
to write phonebook to your server's file
var phonebook = {
'name1' : 234283409,
'name2' : 234253453,
'name3' : 234234236
};
var jsonStr = JSON.stringify(phonebook);
/*
__________________
contents of jsonStr
{"name1":234283409,"name2":234253453,"name3":234234236}
__________________
write a logic here to save this JSON on a file in your server.
*/
to read phonebook to your server's file
//write a logic here to read JSON back from your server's file
var jsonStr = getJSONDataFromServer();
var phonebook = JSON.parse(jsonStr);
//now you can use your phonebook as a usual js object
You can use csv file to store your data.
To store data on the client you can use any local storage methods:
WebStorage: Web Storage API (provides both sessionStorage and localStorage)
gears: Google Gears-based persistent storage
whatwg db: HTML database storage standard
cookie: Cookie-based persistent storage RFC
The best choice depends on the kind of data you need to store, and the usage of that data. The most common choice is WebStorage.
If you use Angular, the great module ngStorage is available, that makes Web Storage working in the Angular Way.
Be warned that:
you'll be able to store only data per user, of course (i.e., you'll not be able to store any global status of the application).
any client storage solution poses strict space limits, which often differ from browser to browser.
If instead you simply don't want to use any local server solution, you could try some cloud platform, like, for example, firebase (just acquired by Google), or others.
you can use Google's Firebase. If firebase is complicated to you then use simple localstorage.
User makes HTTP-request to the server. This request is processed with an object of some class, let's call it "Processor". Then the same user in two minutes makes another HTTP request. And I want it to be processed with the same instance of Processor as the first one. So basically I want to keep the state of some object among several requests.
I know that I can save it each time to the datastore and then load back, but this approach seems to be very slow. Is there a way to store objects in some RAM place?
How about using memcache?
You can't ensure that consecutive requests to your app will go to the same instance, but memcache can help reduce or eliminate the overhead of accessing the datastore for each request.
It sounds like you are describing is a session.
I am not sure which language runtime and web framework you are using, but it is sure to include support for a sessions. (If you are using Java you will need to enable it.)
The standard session mechanism puts a small ID in a cookie that is stored in the user's browser. On every request, each of which could be go to a different application server, this ID is used as a key to read and write persistent information from the data store.
If the datastore accesses are too slow for you I would suggest not using memcache for this session storage, because memcache is by design unreliable, so the user's session information could disappear at any time, which would be a bad experience for them.
If the amount of data you want to store is less than about a few kilobytes, then I recommend doing what Play Framework does, which is to encrypt your session data and store it directly in a cookie stored in the user's browser. This is fast and truly stateless.
If you have more data than can be stored in a cookie, and you don't want to use the data store, you could could use JavaScript local storage on the browser, and use AJAX calls to communicate with the server. (If you want to support older browsers you may need to use the jStorage wrapper library.)
If memcache isn't enough, you could use backends to maintain state. Use a resident backend (or a set of them) and route incoming requests from the frontend to the backend machine that has the state.
Docs: Python Java