How taint tracking works
When IAST is enabled, dd-trace marks data entering the application from external sources (HTTP request parameters, headers, cookies, database rows, environment variables, etc.) as tainted. As this data flows through your code, IAST tracks it. If tainted data reaches a security-sensitive operation — such as a SQL query, file path construction, or command execution — without being adequately sanitised, a vulnerability is reported. Because IAST runs inside the real application process with real traffic, it produces low false-positive rates and can pinpoint the exact line of code responsible for a vulnerability.Enabling IAST
IAST uses a sampling mechanism (
requestSampling) to limit performance overhead. Not every request is fully analysed. Increase requestSampling in development or staging for more thorough scanning.Detected vulnerability types
SQL Injection
Tainted input used directly in SQL queries without parameterisation.
Command Injection
Tainted input passed to
child_process.exec, spawn, or similar APIs.Path Traversal
Tainted input used to construct file system paths, enabling directory traversal.
SSRF
Tainted input used as a URL in outbound HTTP calls.
NoSQL Injection
Tainted input in MongoDB or other NoSQL query objects.
LDAP Injection
Tainted input in LDAP query filters.
XSS (Reflected)
Tainted input rendered in HTML responses without escaping.
Code Injection
Tainted input passed to
eval() or Function() constructors.Header Injection
Tainted data set in HTTP response headers.
Unvalidated Redirect
Tainted input used as a redirect URL.
Weak Cipher / Hash
Use of deprecated cryptographic algorithms such as MD5 or DES.
Hardcoded Secrets
API keys, passwords, or tokens detected in source code.
Configuration options
| Option | Environment variable | Default | Description |
|---|---|---|---|
enabled | DD_IAST_ENABLED | false | Enable IAST |
requestSampling | DD_IAST_REQUEST_SAMPLING | 30 | Percentage of requests to analyse (0–100) |
maxConcurrentRequests | DD_IAST_MAX_CONCURRENT_REQUESTS | 2 | Maximum concurrent IAST analyses |
maxContextOperations | DD_IAST_MAX_CONTEXT_OPERATIONS | 2 | Max vulnerabilities detected per request |
deduplicationEnabled | DD_IAST_DEDUPLICATION_ENABLED | true | Deduplicate identical vulnerability reports |
redactionEnabled | DD_IAST_REDACTION_ENABLED | true | Redact sensitive values in vulnerability reports |
redactionNamePattern | DD_IAST_REDACTION_NAME_PATTERN | — | Regex to redact sensitive source names |
redactionValuePattern | DD_IAST_REDACTION_VALUE_PATTERN | — | Regex to redact sensitive source values |
dbRowsToTaint | DD_IAST_DB_ROWS_TO_TAINT | 1 | Number of database rows to taint per query |
stackTrace.enabled | DD_IAST_STACK_TRACE_ENABLED | true | Include stack traces in vulnerability reports |
telemetryVerbosity | DD_IAST_TELEMETRY_VERBOSITY | INFORMATION | Telemetry verbosity level |
Security controls
If your application uses custom sanitisation functions that IAST does not recognise, you can declare them as security controls so that taint tracking stops at those functions:CONTROL_TYPE:VULNERABILITY_TYPE:module:function.
Valid control types are SANITIZER and INPUT_VALIDATOR.
Performance impact
IAST adds overhead proportional to therequestSampling percentage and maxConcurrentRequests value. With the defaults (30% sampling, 2 concurrent), typical overhead in production is under 5% CPU and a few milliseconds of added latency on analysed requests. In development, you can safely raise sampling to 100%.