The four ways to secure data in a web application are to back it up, encrypt it, secure the encryption keys, and take extra care at every stopping point where data is stored or moved. Encryption is only as strong as the protection around its keys, which is why the third step decides whether the second one actually works.

Why Web App Data Needs Extra Protection

In the modern world, more and more applications move to the cloud, or to be more specific, to somebody else's servers. The common solution today is to make an application a web service, accessible from any modern browser. That has upsides and downsides. One downside is that the way your data is read, modified, and stored is not under your direct control.

Problems with data security, accessibility, integrity, or unauthorized access can lead to huge losses for the data owner, whether financial, reputational, or emotional. A web service provider usually cares about your data up to the price users pay for the service, plus some reputational cost. That is still less than the value users lose when their data is lost or compromised. The risk can be mitigated in several ways.

1. Back Up Your Data

Backing up your data is always a good idea, especially if you make sure it can actually be restored from the backup. This takes some cooperation from the web service, but most services let you download your data in an open format. If you are developing such a service, give your users a way to back up their data.

2. Restrict Unauthorized Access With Encryption

Preventing unauthorized access is a different problem from losing data. The data has to be stored somewhere, at the web service provider or at another provider if storage is outsourced. It has to be parsed and processed by the server software, sent over the internet to authorized clients, then parsed, processed, and displayed by the browser. When the user enters new data, it has to travel all the way back. For anyone trying to steal the data, that is a large attack surface.

The usual answer is data encryption. The actual user can do little about it, which is why web service developers have to get it right. For a closer look at where encryption should happen, see Why Client-Side Encryption Beats Server-Side for Data Security.

3. Secure Your Encryption Keys, Too

Encrypting the data is not enough. The data is no more secure than the keys used to encrypt it, so keeping those keys safe is essential.

Data in transit between computers is usually secured by the Transport Layer Security (TLS) protocol, which uses clever cryptography to exchange one-time session keys between the communicating parties (see NIST's TLS guidance). The connection between a user's browser and a web service is secured by HTTPS, which is simply regular HTTP carried over TLS.

The most important thing for the user is to make sure the connection is secure and that the domain name is not misspelled. Browsers used to show a green padlock for this, but Chrome retired the padlock in version 117 because HTTPS has become the norm, and nearly all phishing sites use it too. HTTPS tells you the connection is encrypted, not that the site is trustworthy, so check the address itself. Even that may not be enough, and there is little a user can do about other vulnerabilities. Software security is hard.

Where to Store the Encryption Key

The second problem is where to store the key. A web service should be accessible from any browser. Storing keys on the server, or alongside the user's data, negates almost all the benefit of client-side encryption.

The only thing that stays consistent between sessions is the user's credentials for authentication. Deriving a strong encryption key from those credentials can be hard, depending on what they are. Weak passwords are a good example. A server can limit the number of authentication attempts, block suspicious activity, or require other factors when someone tries to guess a password. But when someone tries to decrypt the data directly, the number and speed of password guesses is limited only by the available computing power. For one approach to this problem, see Distributed Key Management for Cloud Apps.

4. Take Extra Care at Every Stopping Point

TLS takes care of data in transit. Stored data can and usually should be encrypted as well, especially if it is stored outside the server that uses it. But to use the data, the server needs a key to decrypt it, and if the server is sufficiently compromised, the key is compromised too. To solve this, you can encrypt the data on the client side and have the server handle only encrypted data.

The idea is sound, but implementing it securely is hard. Some of the data is needed on the server, because the essence of the service requires the server to have access to at least part of it. That makes both frontend and backend security harder, because the data becomes fragmented and has to be carefully processed each time it enters or leaves the client side. On top of higher development costs, this adds complexity and significant room for error.

Service providers therefore have to consider each stopping point along the way of data transfer and storage. Encryption is often the answer, but the encryption keys must also be secured in a way that attempts to crack the encryption cannot easily exploit. For a working example of client-side encryption, see PassHub, and for implementation details, see the WWPass developer documentation.

FAQ

What are the four ways to secure web app data?
Back up your data, encrypt it, secure the encryption keys, and take extra care at every point where data is stored or transferred. Each addresses a different failure: loss, theft, key compromise, and implementation error.

Why isn't encrypting data enough?
Because the data is no more secure than the keys used to encrypt it. If the keys sit on the same server as the data, or can be guessed from a weak password, an attacker who gets in can decrypt everything.

Where should encryption keys be stored for a web app?
Not on the server and not alongside the user's data, which negates almost all the benefit of client-side encryption. Deriving a key from a weak password is risky too, since offline guessing is limited only by computing power.

Why is client-side encryption hard to implement?
The server often needs access to some of the data to deliver the service, so the data becomes fragmented and must be carefully processed every time it enters or leaves the client. That raises development cost and creates room for error.

Does HTTPS mean a website is safe?
No. HTTPS means the connection between your browser and the site is encrypted. Google notes that nearly all phishing sites use HTTPS as well, so check the domain name carefully and don't treat a lock icon as proof of trustworthiness.

Learn More

Want to know more about keeping encryption keys secure for your users? Contact the WWPass team.