# Sensitive Data Management

## Overview

This section contains recommendations for secure processing of sensitive data.

## What is sensitive data?

A list of sensitive data is determined individually for each application. The sensitivity of data is determined during the risk assessment, in which existing assets are evaluated against the CIA triad (Confidentiality, Integrity, Availability). The risk assessment sets the importance of a particular asset for a business.

The following list contains examples of data that are considered sensitive in most cases:

* Password.
* One-time password.
* Session ID.
* Access tokens.
* Personal Identifiable Information or PII (any set of data that could potentially identify a particular person):
  * Name.
  * Surname.
  * Address.
  * Identity document details.
  * Photos and videos by which a person can be identified.
  * Phone number.
  * etc.
* Financial data:
  * Transaction details.
  * Card details. Payment cardholder data.
  * Bank account details.
  * etc.
* Code words.
* Secret values that allow users to perform some operation, for example, money transferring.
* Database connection strings.
* Encryption keys and other master secrets.
* Commercially-sensitive information:
  * Financial reports.
  * Information about unreleased products or services.
  * etc.
* Information whose collection is illegal in a particular jurisdiction.

## Data storage

<div align="left"><img src="/files/QJuMWI21M60ZKzo0mFAN" alt=""></div>

* Do **not** send sensitive data to analytics.
* Store sensitive data in plain text **only** in a database. Exceptions:
  * Passwords, store passwords according to the [Authentication: Password Storage](/application-security-handbook/web-application/authentication/password-storage.md) page.
  * `cvv2/cvc2` and `PIN` codes of payment cards. This data can not be stored in a database in any form if an application is not PCI DSS compliant.

## Data logging

<div align="left"><img src="/files/QJuMWI21M60ZKzo0mFAN" alt=""></div>

* Write identifiers of sensitive data, by which they are available in a database, to logs instead of their plain text values.
* Otherwise, mask all logged sensitive data, check out the [Data masking](#data-masking) section below.

## Data masking

<div align="left"><img src="/files/QJuMWI21M60ZKzo0mFAN" alt=""></div>

* Replace actual values with `n` `"*"` when masking data
* n must be fixed and not depend on the length of the input data.
* You can leave part of the data open if this part is open data or does not allow restoring the actual value. For example, the first 6 and last 4 digits of a card number are public data that can be left unmasked.

### Example of masking policy

* The card number is masked as `*1234`, where `1234` is the last 4 digits of the card number.
* `cvv2/cvc2` are masqueraded as `***`
* Passwords, tokens, and session IDs are masked with `n` `"*"` characters, e.g. password `****`. `n` must be fixed and independent of the length of an input.
* Name and surname are masked as a minimum in the form `Name S`.
* Phone number is masked as `+1(***)****1234`
* Passport ID is masked as `*12`, where `12` is the last 2 digits of the passport ID.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xn3va.gitbook.io/application-security-handbook/web-application/sensitive-data-management.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.