There was a bug in your application's code. An attacker uses it to get the database credentials and extracts the data from every table.

The user table contain passwords, emails and names. Other tables contain DOB, addresses, and tax numbers.

The impact of this data breach depends a lot on your application's approach to data security.

Data security (the confidence that your data is safe from unauthorised viewers and remains uncorrupted) requires a layered approach. This spans from physical access, to disk encryption, through to how individual data fields are managed.

Most web frameworks handle common sensitive fields such as passwords properly, but there will be times where you need to secure sensitive data that is specific to your application.

Examples may include personal details such as DOB, address, phone number; API keys; or confidential messages. This type of data is known as "sensitive".

This is a big topic but the basic rules to implement best practices around storing sensitive data are:

1. Data that needs to be stored for future comparison but never retrieved should be hashed using a one-way hashing algorithm.

This includes passwords or API secrets.

Hashing involves generating a fixed length string of characters from a variable length string, which is related to the original string. The hash can be recalculated to verify a subsequent input matches the original string.

For example, when the user enters the password, the application will generate the hash and compare it to what is stored in the user table.

2. Data that needs to be stored for retrieval should be encrypted.

This includes data that can be viewed or edited within the application or associated components.

Encryption involves using an encryption key to generate a cipher from the input characters. The cipher can be decrypted by using the same key.

Obviously the key needs to be adequately protected.

Why not hash everything?

There is a computational cost involved with calculating the hash, which is why it should only be used when necessary. In other words, your application performance could be negatively impacted.

Include the above rules in any requirements using sensitive data and you will be saving yourself from many potential headaches in the case of unauthorised data access.