The Datadog library supports Java JRE 1.8 and higher of both Oracle JDK and OpenJDK, on the following architectures:
Datadog does not officially support any early-access versions of Java.
You can monitor application security for Java apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
| Framework Web Server | Minimum Framework Version |
|---|---|
| Servlet Compatible | 2.3+, 3.0+ |
| Spring | 3.1 |
Note: Many application servers are Servlet compatible and are supported by ASM, such as WebSphere, WebLogic, and JBoss. Also, frameworks like Spring Boot are supported by virtue of using a supported embedded application server (such as Tomcat, Jetty, or Netty).
The following .NET versions are supported:
These are supported on the following architectures:
You can monitor application security for .NET apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
The .NET Tracer supports all .NET-based languages (for example, C#, F#, Visual Basic).
| Framework Web Server | Minimum Framework Version |
|---|---|
| ASP.NET | 4.6 |
| ASP.NET Core | 2.1 |
The Datadog Go tracing library supports Go version 1.14 and greater, on the following architectures:
You can monitor application security for Go apps running in Docker, Kubernetes, and AWS ECS.
Integrate the Go tracer with the following list of web frameworks using one of the corresponding APM tracer integration. Click to see the integrations documentation, which provides a detailed overview of the supported packages and their APIs, along with usage examples.
Compiling your code with ASM enabled involves CGO and therefore requires:
gcc compiler for the target GOOS and GOARCH.CGO_ENABLED environment variable which is enabled by default when compiling natively.To install the above requirements:
| Operating system | Console command |
|---|---|
| Debian, Ubuntu | $ apt install gcc libc6-dev |
| Alpine | $ apk add gcc musl-dev |
| RHEL, CentOS, Fedora | $ yum install gcc glibc-devel |
| macOS | $ xcode-select --install |
Note: The Go toolchain disables CGO when cross-compiling and so, CGO needs to be explicitly enabled.
The Datadog Ruby library supports the latest gem for the following Ruby interpreters:
These are supported on the following architectures:
You can monitor application security for Ruby apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
| Framework Web Server | Minimum Framework Version |
|---|---|
| Rack | 1.1 |
| Rails | 3.2 (also depends on Ruby version) |
| Sinatra | 1.4 |
The Datadog PHP library supports PHP version 7.0 and above on the following architectures:
You can monitor application security for PHP apps running in Docker, Kubernetes, and AWS ECS.
It supports the use of all PHP frameworks, and also the use no framework.
The Datadog Node.js library supports the following Node.js versions:
These are supported on the following architectures:
You can monitor application security for Node.js apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
| Framework Web Server | Minimum Framework Version |
|---|---|
| Express | 4.0 |
The Datadog Python library supports the following Python versions:
These are supported on the following architectures:
You can monitor application security for Python apps running in Docker, Kubernetes, AWS ECS, and AWS Fargate.
| Framework Web Server | Minimum Framework Version |
|---|---|
| Django | 1.8 |
| Flask | 0.10 |
Support for query strings is not available for Flask.
395.20.0java8.al2) or Java 11 (java11) runtimes with at least 1024MB of memory.dd-trace-java:4 (or older) and Datadog-Extension:24 (or older), follow the instructions in Upgrade Instrumentation for Java Lambda Functions.The following ASM capabilities are not supported for Lambda functions:
ASM automatically attempts to resolve http.client_ip from several well-known headers, such as X-Forwarded-For. If you use a custom header for this field, or want to bypass the resolution algorithm, set the DD_TRACE_CLIENT_IP_HEADER environment variable and the library only checks the specified header for the client IP.
Many critical attacks are performed by authenticated users who can access your most sensitive endpoints. To identify bad actors that are generating suspicious security activity, add user information to traces by instrumenting your services with the standardized user tags. You can add custom tags to your root span, or use instrumentation functions. Read Tracking User Activity for more information.
There may be a time when an ASM signal, or a suspicious request, is a false positive. For example, ASM repeatedly detects the same suspicious request and a signal is generated, but the signal has been reviewed and is not a threat.
You can add an entry to the passlist, which ignore events from a rule, to eliminate noisy signal patterns and focus on legitimately suspicious requests.
To add a passlist entry, do one of the following:
Note: Requests (traces) that match a passlist entry are not billed.
The data that you collect with Datadog can contain sensitive information that you want to filter out, obfuscate, scrub, filter, modify, or just not collect. Additionally, it may contain synthetic traffic that might cause your threat detection be inaccurate, or cause Datadog to not accurately indicate the security of your services.
By default, ASM collects information from suspicious requests to help you understand why the request was flagged as suspicious. Before sending the data, ASM scans it for patterns and keywords that indicate that the data is sensitive. If the data is deemed sensitive, it is replaced with a <redacted> flag, so you observe that although the request was suspicious, the request data could not be collected because of data security concerns.
To protect users’ data, sensitive data scanning is activated by default in ASM. You can customize the configuration by using the following environment variables. The scanning is based on the RE2 syntax, so to customize scanning, set the value of these environment variables to a valid RE2 pattern:
DD_APPSEC_OBFUSCATION_PARAMETER_KEY_REGEXP - Pattern for scanning for keys whose values commonly contain sensitive data. If found, the values and any child nodes associated with the key are redacted.DD_APPSEC_OBFUSCATION_PARAMETER_VALUE_REGEXP - Pattern for scanning for values that could indicate sensitive data. If found, the value and all its child nodes are redacted.ddtrace version 1.1.0You can also configure scanning patterns in code:
Datadog.configure do |c|
# ...
# Set custom RE2 regexes
c.appsec.obfuscator_key_regex = '...'
c.appsec.obfuscator_value_regex = '...'
end
The following are examples of data that are flagged as sensitive by default:
pwd, password, ipassword, pass_phrasesecretkey, api_key, private_key, public_keytokenconsumer_id, consumer_key, consumer_secretsign, signed, signaturebearerauthorizationBEGIN PRIVATE KEYssh-rsaSee APM Data Security for information about other mechanisms in the Datadog Agent and libraries that can also be used to remove sensitive data.
To disable ASM, remove the DD_APPSEC_ENABLED=true environment variable from your application configuration. Once it’s removed, restart your service.
If you need additional help, contact Datadog support.
The blocked requests feature JSON or HTML content. If the Accept HTTP header is pointing to HTML, like text/html, the HTML content is used. Otherwise, the JSON one is used.
Both sets of content is embedded in the Datadog Tracer library package and loaded locally. See examples of the templates for HTML and JSON in the Datadog Java tracer source code on GitHub.
The HTML and JSON content can both be changed using the DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML and DD_APPSEC_HTTP_BLOCKED_TEMPLATE_JSON environment variables. Alternatively, you can use the dd.appsec.http.blocked.template.html or dd.appsec.http.blocked.template.json configuration entries.
By default, the page shown in response to a blocked action looks like this:
Additional helpful documentation, links, and articles:
