About data storage and privacy
Last updated 2025-04-23
We store and make available request and response data via the control panel and API you use to interact with the Next-Gen WAF. 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 control panel you use to access the Next-Gen WAF.
- 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 control panel you use to access the Next-Gen WAF.
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 Fastly control panel 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. |
Storage edge case
Generally, requests are tagged with signals and then storage decisions are made per our storage categories. However, HTTP 4xx and 5xx error signals are applied to requests after storage decisions have been made because we have to wait for responses to be sent to know the applicable HTTP response code. Therefore, some requests may appear to only have HTTP 4xx and 5xx error signals when in reality there were informational signals that were removed.
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.
