About data storage and privacy
Last updated 2024-04-02
We store and make available request and response data via the web interface and API. Due to our redaction process, only non-sensitive or benign portions of the request are ever sent to the platform backend.
Limitations and considerations
Keep these things in mind:
- Data can only be extracted within 24 hours of its creation.
- We store request and response data for 30 days and then delete it.
- We use the collected request data to help identify and block attacks to your web application. We never attribute any data back to your organization or end users.
Response data storage
We only collect metadata (e.g., response codes and response headers) from response records.
Request data storage
From request records, we collect and store two types of data:
- Time series data: the number of signals (e.g., XSS, SQLi, 404s) observed per minute. All time series data is available via graphs in the web interface.
- Individual request data: detailed information about requests (e.g., originating IP address and request parameters). We store individual request data based on storage categories, site alerts (also known as workspace alerts), and the value of the Request logging setting for request rules.
How request data storage works
When requests are made to your web application, the Next-Gen WAF agent tags the requests with the appropriate signals and sends the signals to our cloud engine. The cloud engine then counts the number of requests that were tagged with a particular signal during one minute periods and makes this data available via time series graphs in the web interface.
The Next-Gen WAF agent also determines which incoming requests we should store individual request data for. Individual request data is detailed information about a request record (e.g., originating IP address and parameters). To identify the requests that need capturing, the agent uses:
- the value of the Request logging menu from request rules. Specifically, we log requests that meet the criteria of a request rule with a Request logging value of
Sampled. - site alerts (workspace alerts) when the agent mode (also known as protection mode) is
BlockingorNot blocking(also known asLogging). Specifically, when a system site alert (system workspace alert) flags an IP address, we log a sample of subsequent requests that are tagged with an attack signal and that are from that IP address. - storage categories, which are based on signal type. For example, we store the individual request data for all requests that are tagged with the
SQLIattack signal because requests that are tagged with an attack signal fall into the all storage category.
After identifying the requests that need capturing, the agent redacts sensitive data from the selected requests. By default, the agent redacts certain data (e.g., passwords, session tokens, and tracking cookies). The agent also redacts custom fields that you identify. For example, if your password field is named foobar instead of password, you can create a custom redaction for the foobar field.
Next, the agent sends the redacted requests to our cloud engine and the cloud engine makes the individual request data available via the web interface and API.
We store both the time series data and the individual request data for 30 days and then delete it.
Storage categories
Storage categories help determine which request records we store individual request data for. They are based on the type of signals that requests are tagged with.
| Storage category | Category applies to | What data is stored |
|---|---|---|
| All | Requests that contain at least one attack signal (e.g., SQLi and XSS) or one CVE signal applied by a virtual patching rule | We store individual request data and time series data from all requests that fit into this storage category. |
| Sampled | Requests that don't fit into the all storage category and that contain at least one custom signal, anomaly signal (e.g., HTTP 404 Errors and Tor traffic), or bot signal. | We store individual request data from a random sample of requests that fit into this storage category. We also store time series data from all requests that fit into this storage category. |
| Time series only | Requests that only contain informational signals or signals from API or ATO templated rules | We don't store individual request data from requests that fit into this storage category. However, we store time series data from all requests that fit into this storage category. |
| Not stored | Requests that aren't tagged with a signal | We don't store individual request data from requests that fit into this storage category. |
Deleting stored data
If you find information in the raw data that you want to delete, submit a support request with the date range that you want us to scrub.
Do not use this form to send sensitive information. If you need assistance, contact support. This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
