Skip to main content
Interactive Application Security Testing (IAST) detects code-level vulnerabilities in your running application. Unlike SAST (static analysis) or DAST (external scanning), IAST instruments the application at runtime using taint tracking — following untrusted data from its entry point through your code to detect when it reaches a sensitive sink without proper sanitisation.

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

1

Set the environment variable

DD_IAST_ENABLED=true node server.js
2

Or enable programmatically

const tracer = require('dd-trace').init({
  iast: true,
})
Or with detailed options:
const tracer = require('dd-trace').init({
  iast: {
    enabled: true,
    requestSampling: 30,    // percentage of requests to analyse (default: 30)
    maxConcurrentRequests: 2, // max concurrent analyses (default: 2)
  },
})
3

Check Datadog for results

Detected vulnerabilities appear in Security > Code Security in Datadog, grouped by vulnerability type and file location.
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

OptionEnvironment variableDefaultDescription
enabledDD_IAST_ENABLEDfalseEnable IAST
requestSamplingDD_IAST_REQUEST_SAMPLING30Percentage of requests to analyse (0–100)
maxConcurrentRequestsDD_IAST_MAX_CONCURRENT_REQUESTS2Maximum concurrent IAST analyses
maxContextOperationsDD_IAST_MAX_CONTEXT_OPERATIONS2Max vulnerabilities detected per request
deduplicationEnabledDD_IAST_DEDUPLICATION_ENABLEDtrueDeduplicate identical vulnerability reports
redactionEnabledDD_IAST_REDACTION_ENABLEDtrueRedact sensitive values in vulnerability reports
redactionNamePatternDD_IAST_REDACTION_NAME_PATTERNRegex to redact sensitive source names
redactionValuePatternDD_IAST_REDACTION_VALUE_PATTERNRegex to redact sensitive source values
dbRowsToTaintDD_IAST_DB_ROWS_TO_TAINT1Number of database rows to taint per query
stackTrace.enabledDD_IAST_STACK_TRACE_ENABLEDtrueInclude stack traces in vulnerability reports
telemetryVerbosityDD_IAST_TELEMETRY_VERBOSITYINFORMATIONTelemetry 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:
DD_IAST_SECURITY_CONTROLS_CONFIGURATION="SANITIZER:SQL:my-module:sanitizeSql;INPUT_VALIDATOR:COMMAND_INJECTION:my-module:validateInput"
The format is: CONTROL_TYPE:VULNERABILITY_TYPE:module:function. Valid control types are SANITIZER and INPUT_VALIDATOR.
The securityControlsConfiguration programmatic option is not supported when your application uses ES Modules (ESM). Use the DD_IAST_SECURITY_CONTROLS_CONFIGURATION environment variable instead.

Performance impact

IAST adds overhead proportional to the requestSampling 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%.

Build docs developers (and LLMs) love