What security concerns are there regarding website users inputting personal financial data without putting in personally identifying data?

Question

I am a web developer, but I have only a rudimentary grasp of security, e.g., be careful to sanitize inputs, store as little user data as possible, encrypt passwords, keep up with security issues of libraries and packages, etc.

Today, I was approached by a client who does financial planning about replacing a spreadsheet he gives clients with a web-based form. The spreadsheet asks users to input certain financial data - e.g., current value of various investment accounts, business interests, etc. These numbers are put into a formula and a value is generated which is supposed to help the user decide whether the consulting could be useful to them.

The phone call was very short, and my questions focused on more mundane matters about user experience, desired UI elements, etc. No commitments have been made, and I'm analyzing the project to see if it's something I can do. I began to think about potential security issues, and I realized I really don't know where to start. So far it seems that client wants the form to be accessed via a magic link, and that the user would not enter any personally-identifying information. I do not know yet whether my potential client wants to store the value generated, a simple dollar amount which is the 'benefit' the user could get by using the service. The impression I got is that my potential client simply wants to use this value as a motivator for clients to inquire further about his services.

In this scenario, what security-related matters should I consider?

Answer 1

It's the details that are confidential, but the outcome as the amount of dollars alone doesn't tell much to anyone. Before rushing to details like UX and UI one should define the desired use cases and functionality first. I see two possibilities, and both are good from your perspective:

1. The tool is intented for personal use of the user alone, and the profit your client gets is bound to the impression it leaves to the user i.e. the user desides to use the services based on the results. In this case the user experience of the form is highlighted, as it's purely for advertisement. However, it also makes it possible to do everything client-side and the application doesn't need to save any of the information on the server. Regarding PII this is the easiest solution.

2. If the application saves any possible PII, it's your client's responsibility to deside what information is collected and how it's stored and used. Depending on the jurisdiction there might be special requirements for that, e.g. EU GDPR, national privacy acts or even PCI DSS. You should have them to define their needs, and while you can give some advice, after you have finished with the project it's their data on their responsibility.

Answer 2

You are asking yourself the right question. Security should not be an afterthought but integrated early in the design phase.

A magic link (à la Google Drive ?) may be convenient but inevitably they will be shared (or leaked), even inadvertently by forwarding E-mails for instance. Then there is no accountability: if you want to to know who made a change the only information you have is the IP address. Anybody you knows the URL can see information that they are not entitled to see.

So I think I would build a list of users and assign them usernames and passwords if possible. The inconvenience is not that great and there is more control over who can connect. The link could also be made short-lived/single-use only to minimize long-term exposure.

I am also assuming that we are not talking about prospective (new) clients, but clients with whom there is an existing relationship and that you already know them.

It all depends on the value of the data, how confidential it is and can you afford to have a stranger messing with it. The way I understand it, in terms of functionality it's almost like requesting an insurance quote or a house appraisal. But there is still PII involved and financial data is somewhat sensitive/private by definition. On the other hand, companies have to publish accounts, so it's possible that some of the information they will submit to you is in fact already public.

Before you reinvent the wheel: unless the client has specific requirements there may be solutions already available on the market. Then your job will be more integration than development. If your client uses an ERP or CRM it's possible that a plugin exists, or that you can build one (= better integration).

At this point the issue is not even security. It is more a question of data integrity and confidentiality (and accountability). As mentioned in comments, an IP address is PII and can reveal the end user outright (some companies have their own IP address blocks).

Things I would clarify with the client:

• what kind of data will you exactly store and process
• for how long
• what is the long-term aim
• is it possible that the project evolves and grows over time (think about function creep...)
• applicable regulations to observe (eg GDPR)

Answer 3

The main issue you have here is even though there may not be any personally identifiable information being entered into the form, there is a lot of personally identifiable information being transmitted simply by the user connecting to the website.

IP address, which leads to geo-location, and could trackback to a person's phone if that connection data was in the hands of a person that had a high level of skill with hacking IP addresses back to the individual.

In that scenario then the bad actor would have certain financial details coupled with their identity which could leave that person exposed.

I do not think a project like that should be deployed without an experienced web security professional auditing the project to ensure that the level of data being exposed could not create a vulnerability for the end web user. May even be more of a financial security analysis that is needed, as web security and financial security are not the same areas of expertise.

I'm not saying a full-blown PCI audit is warranted, but at least enough review to ensure that the process is not creating a vulnerability.