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 to NA.
  • 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 a 200 status.

Available enriched headers

Default enriched headers

Header nameDescriptionPossible values
X-DataDome-botnameThe bot nameExamples: curl, googlebot, etc.
This header can be empty if the request was made by a human.
X-DataDome-isbotIs it a bot?- 0: Human user
- 1: Bot
- NA: Detection disabled on this segment
X-DataDome-captchapassedWas 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-devicecheckpassedWas 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-requestidA unique identifier for the current requestA 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-ruletypeThe 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 nameDescriptionPossible values
X-DataDome-matchedmodelsNames 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-scoreThe level of confidence when identifying a request as coming from a botA float number between 0 and 1:
0: Lowest level of confidence
1: Highest level of confidence

This header will be empty if:

- the traffic rule response is either authorize or interstitial,
- or the request matched a Custom Rule
X-DataDome-sessionidThe DataDome session ID to track the user's journeyThe session ID.
Example: AHrlqAAAAAMA9DfoAKMDOgIAlEibGw==

This header can be empty if the request was part of a DDoS attack.
X-DataDome-Traffic-Rule-ResponseThe 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-protectionWhether DataDome protection was enabled or disabled to process the request- 0: protection disabled
- 1: protection enabled
X-DataDome-endpointnameThe name of the endpoint targeted by the request (as defined in DataDome set-up)Examples: Website login, Android App Cartetc.
X-DataDome-endpointidThe unique identifier of the endpoint targeted by the request.An integer number, ex. 12343
X-DataDome-clientside-executedWhether 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-durationDuration 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-durationDuration in seconds of the current active session. The active session is reset in case of inactivity.An integer number, ex. 12343
X-DataDome-activesession-requestnumberThe 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-elapsedThe 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:

Export to SIEM/SOC tools

You can find more information about how to export these logs and headers to an SIEM/SOC Tools.