I’m currently building a web application that utilises Open Banking through Plaid. This means that it pulls a users banking details through a generated ‘access token’.
I’ve been toying with the concept of how to persist this user data. My reasoning for this is that the Plaid API gets pulled on every web page that requires it, and so it causes a several second ‘loading’ to process – which if you’re navigating round my app is frustrating.
This is a poor user experience in my opinion, and so I’d prefer to somehow persist this data without having to make a server call.
To do this, I’ve initially gone for session storage. I know many people say this is vulnerable to things such as XSS etc, but it’s convenient and works well.
I’m a little uneasy with storing the results of a server call locally though, for obvious reasons.
Currently, the data which is pulled and therefore stored locally is:
- Firebase user ID
- Account id
- Balance
- Type of account
- Last four digits of account number
- Account provider
- Consent expiration time
- Transactions
- Database ID
And a bunch of other status codes.
The actual data itself isn’t personally identifiable, or usable for anything malicious to my knowledge. No passwords are stored locally, the access token is only ever exchanged via my server, and it is encrypted so not publicly visible as plain text should my database ever get hacked.
So I guess my question is, how secure is this? Is it actually a security problem considering the data can’t be explicitly used for malicious purposes? The only time it would be a problem (in my opinion) would be if my server / database was accessed with the encryption key.
Other alternatives are..
- Encrypt the data that is stored in session storage, but is this pointless?
- Not use session storage at all
Or can anybody suggest any other alternatives?
I know people on here will be much more experienced than me with this – so open to any suggestions. Please let me know, it’d be appreciated.
