Logs Enrichment Integration
DataDome Bot Protect analyzes your traffic in real time. We can provide insights about your traffic by enriching your logs for all the requests that we analyze.
Our modules include a powerful feature that adds headers on each request before they reach your backend or CDN.
Our customers use it for a deeper integration of DataDome in their infrastructure and applications for the following use cases:
- Enriching server logs with bot information from DataDome for log analytics, SIEM or SOC (e.g. Elasticsearch, Sumo Logic, Splunk)
- Providing insights about bot traffic on your client-side analytics (e.g. Google Analytics, Adobe Analytics)
Header behavior when detection or protection is disabled
When this feature is enabled, DataDome adds headers to all requests, even if detection and protection are disabled.
- If detection is disabled, all headers that can return
NA
(as seen in this section below) will be set toNA
.- If protection is disabled, the headers (including
X-DataDome-Traffic-Rule-Response
) will reflect what would have occurred if protection was enabled, but the request will still be allowed through with a200
status.
Available enriched headers
Default enriched headers
Header name | Description | Possible values |
---|---|---|
X-DataDome-botname | The bot name | Examples: curl , googlebot , etc.This header can be empty if the request was made by a human. |
X-DataDome-isbot | Is it a bot? | - 0 : Human user- 1 : Bot- NA : Detection disabled on this segment |
X-DataDome-captchapassed | Was a CAPTCHA passed? | - 0 : This request was challenged with CAPTCHA (or it would have been challenged with CAPTCHA if protection were enabled), and the session has not passed CAPTCHA yet.- 1 : This request matched a model triggering a CAPTCHA challenge, but the session recently passed a CAPTCHA and hence the request was authorized.- NA : This request has not matched any model triggering a CAPTCHA challenge. |
X-DataDome-devicecheckpassed | Was a Device Check passed? | - 0 : The session has been challenged with Device Check but it hasn't passed it yet- 1 : The session has previously passed Device Check- NA : The session has not been challenged with Device Check |
X-DataDome-requestid | A unique identifier for the current request | A standard UUID with alphanumeric characters, e.g. 123e4567-e89b-12d3-a456-426614174000 .This header can be empty if the request was part of a DDoS attack. |
X-DataDome-ruletype | The traffic category | - Humans - AI Threats Detection - Verified Bots - Custom Rules |
Advanced enriched headers
How to enable advanced enriched headers?
Please contact our support team to enable enriched headers that are not enabled by default.
They will review your requirements and provide you the best recommendations.
Header name | Description | Possible values |
---|---|---|
X-DataDome-matchedmodels | Names of bot models that were triggered (max: 10) | Examples: Credential Stuffing , Unusual traffic volume , Recent CVE-xxxx-xxxxx activity , etc.This header can be empty if no model was matched. |
X-DataDome-score | The level of confidence when identifying a request as coming from a bot | A float number between 0 and 1:0 : Lowest level of confidence1 : Highest level of confidenceThis header will be empty if: - the traffic rule response is either authorize or interstitial ,- or the request matched a Custom Rule |
X-DataDome-sessionid | The DataDome session ID to track the user's journey | The session ID. Example: AHrlqAAAAAMA9DfoAKMDOgIAlEibGw== This header can be empty if the request was part of a DDoS attack. |
X-DataDome-Traffic-Rule-Response | The response type applied by DataDome or the type that would have been applied if DataDome protection was enabled | - authorize - block (CAPTCHA response)- hard_block (Block response)- interstitial (Device Check) |
X-DataDome-protection | Whether DataDome protection was enabled or disabled to process the request | - 0 : protection disabled- 1 : protection enabled |
X-DataDome-endpointname | The name of the endpoint targeted by the request (as defined in DataDome set-up) | Examples: Website login , Android App Cart etc. |
X-DataDome-endpointid | The unique identifier of the endpoint targeted by the request. | An integer number, ex. 12343 |
X-DataDome-clientside-executed | Whether DataDome client-side detection was executed at least once during the session, running DataDome JSTag or mobile SDK. | - 0 : client-side detection not executed yet- 1 : client-side detection executed |
X-DataDome-session-duration | Duration in seconds of the session, since its very beginning and without resetting it in case of inactivity. | An integer number, ex. 12343 |
X-DataDome-activesession-duration | Duration in seconds of the current active session. The active session is reset in case of inactivity. | An integer number, ex. 12343 |
X-DataDome-activesession-requestnumber | The incremental request number of the current active session, starting from 1. The active session is reset in case of inactivity. | An integer number, ex. 12 |
X-DataDome-previousrequest-elapsed | The delay in seconds since the previous request of the session. | An integer number, ex. 2 |
Logs integration
Please refer to the documentation pages below to configure your server-side integrations in order to benefit from these enriched headers in your own logs:
- Apache
- Cloudflare Worker (Cloudflare Apps is not supported)
- CloudFront
- Fastly
- HAProxy18/HAPEE
- IIS
- Nginx
- OpenResty
- Varnish
Export to SIEM/SOC tools
You can find more information about how to export these logs and headers to an SIEM/SOC Tools.
Updated about 7 hours ago