The injection attempt, seen in the trace.
Blocked before the query runs.
Datadog App and API Protection, formerly Application Security Monitoring, is the product most people still call ASM. It detects attacks inside the traces the APM tracer already produces, blocks them in the service, and inventories every API endpoint the services expose. We implement it on the tracer you already run, decide with you where detection becomes blocking, and under Critical Support our engineers take the signal, 24x7.
Quick facts
Related
- APM, the tracer this runs on
- Runtime Code Analysis, the vulnerability the attack is aiming at
- Cloud SIEM, the same attacker seen in the logs
The attack, the request that carried it, the query it became, and the service that ran it
The edge WAF sees a suspicious string in a request and either blocks it or lets it through. It never finds out what happened next. App and API Protection lives in the tracer, so it sees the request become a database query, a file read or an outbound call, and can stop the exploit at that point. The whole trace is kept as the record of what was attempted.
Detection from the tracer you already run. With APM in place, protection is one environment variable away on a host. Injection attempts, account takeover and application abuse are matched against Datadog's rules inside the trace, and the attack flow is drawn across the services it touched.
Blocking inside the application. The In-App WAF blocks a request by IP address, user agent or header before the application code runs. Exploit Prevention catches what the WAF missed by watching the SQL query, the file path or the outbound request the application builds, and stopping it there.
The API inventory nobody had. Every endpoint the traced services expose, discovered from live traffic. Posture rules from the OWASP API Top 10 flag the unauthenticated, the undocumented and the overly permissive. Endpoint Scanning confirms what is reachable from outside.
A signal with a trace attached. Each security signal carries the requests, the attacker attributes and the services involved, in the same explorer the engineers use for incidents. The question "did it get anywhere" has an answer in the trace.
A tracer with protection off, scanner noise on the login endpoint, and a block list with the office in it
How it bills. App and API Protection runs in the Datadog tracer and is metered per host it is enabled on, with AWS Fargate tasks on their own meter and serverless functions metered on traced invocations. Where APM already traces the service, the APM host is a separate meter the service already counts against. Datadog publishes the meters and rates. The lever is which services it is enabled on: the ones that face the internet or sit behind an API gateway. Not every service that happens to carry a tracer, and not the internal batch service that nobody outside can reach.
The configuration traps. APM rolled out everywhere and protection assumed to come with it, when it is a separate flag that is off by default. Blocking enabled on day one, so the first false positive takes down a legitimate customer and blocking is switched off everywhere rather than narrowed. Rules left at the default on an endpoint that scanners probe every night, so the signal is muted and the week it matters the mute is still there. The API inventory generated once and never reviewed, so the endpoint that appeared in last month's release is on nobody's list.
Field noteThe most common gap we see is the flag. The tracer is on every service, the licence covers protection, and protection was never enabled, neither by the environment variable nor from the Datadog UI. The service map looks complete and nothing is being protected.
Field noteThe login endpoint is probed by scanners every night and the signal fires every night. After a fortnight the signal is muted. The credential stuffing run that arrives later matches the same rule, and the mute covers it.
Field noteThe pattern we keep finding is the block list with the office in it. An IP was blocked during a penetration test and never removed. Months later the office NAT address changes to it, and the first symptom is the support team unable to log in.
Field noteThe API inventory shows more endpoints than the documentation, and the extra ones belong to a service whose team was reorganised. The posture finding is real, the endpoint is unauthenticated, and the routing sends it to a channel that no longer has members.
The services that face outward. Detection first. Blocking where a false positive costs nothing.
App and API Protection is delivered inside the Code Security Accelerator, four weeks and fixed scope, alongside Software Composition Analysis and the findings baseline. We deliver it on services with APM in place. If APM is not there yet, LaunchPad runs that rollout first, and the APM page describes the sequence.
- List the services that face outward. Internet-facing services, anything behind the API gateway, and the services they call with user input. Internal batch services stay out of scope until there is a reason.
- Enable protection through your deployment tooling. The environment variable on each service in scope, and Remote Configuration confirmed so rules and blocking decisions reach the tracer. Serverless functions in scope are instrumented the same way.
- Run detection only for a fortnight. Every signal reviewed against real traffic: the scanners, the penetration tester, the mobile app that sends an odd header. Rules narrowed to exclude legitimate behaviour without muting the technique.
- Review the API inventory with the owning teams. Discovered endpoints against documented ones. Unauthenticated, undocumented and overly permissive endpoints get an owner and a decision: fix, document or retire.
- Enable blocking where a false positive cannot hurt. Exploit Prevention on the injection techniques first, because a blocked SQL injection has no legitimate twin. IP and header blocking with an expiry on every entry. Account takeover rules in detect mode until the login flow is understood.
- Route the signals and hand over, in writing. Attack signals page the on-call engineer. Posture findings go to the owning team. The handover lists the services in scope, every rule in force with its narrowing and the reason, and each blocking decision. It includes the inventory review and the signals seen during the watch period.
Access is admin on the Datadog organisation and the ability to set an environment variable through your deployment tooling. Blocking decisions under Critical Support are made within the rules agreed at handover, and anything outside them is a call to you before it is a change.
New endpoints ship every release. New attacks arrive without one.
A release adds three endpoints and documents one. A new service goes live with a tracer and without protection. A block list entry from last quarter's test is still in force. Managed Observability keeps the scope, the rules and the inventory matching the application every month. Critical Support answers the signal.
Every month, the signals are reviewed. What fired, what was legitimate, what was blocked. Rules that matched real traffic are narrowed with the reason recorded. Block list entries past their expiry are removed.
Scope follows the deployments. New services that face outward are found in the service map and get protection enabled before they are the service everyone is looking at. Serverless functions in scope are checked after each redeploy.
The inventory is kept honest. Endpoints that appeared since last month are compared with the documentation and the posture rules, and the unauthenticated ones are routed to an owner the same week, not the next audit.
The attack is stopped, not reported. Under Critical Support an attack signal pages our engineers, 24x7. They block the source, confirm from the trace whether anything got through, tell the owner and keep the evidence, in that order.
We operate the stack. You own the product.
We are not a security company, and we do not pretend to be. We are a managed runtime operator. App and API Protection runs on the tracer we already operate for APM, so the people who tune the sampling are the people who tune the rules, and the engineer who answers the latency page answers the attack page. We operate the detection runtime, decide blocking with you, and take the signal. Penetration testing, application security review and the decision about what to tell your customers stay with you. We operate and evidence the runtime controls that support your compliance obligations.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog App and API Protection, answered plainly
Is Datadog ASM the same as App and API Protection?
Yes. Datadog renamed Application Security Monitoring, which most people still call ASM, to App and API Protection, and widened it at the same time. The product now covers runtime threat detection in traces, the In-App WAF, Exploit Prevention and API discovery and posture under one name. Anything configured as ASM carries over. If a licence or an accelerator scope says ASM, it means this.
How is Datadog App and API Protection billed?
App and API Protection runs in the Datadog tracer and is metered per host it is enabled on, with AWS Fargate tasks on their own meter and serverless functions metered on traced invocations. Where APM already traces the service, the APM host is a separate meter the service already counts against. Datadog publishes the current meters and rates. We do not publish prices. The lever is which services it is enabled on, and the answer is the ones that face the internet or sit behind an API gateway, not every service with a tracer.
Does App and API Protection block attacks or only detect them?
Both, and the choice is per rule. Detection comes from the tracer, which sees every request as a trace and matches it against Datadog's rules for injection, account takeover and application abuse. The In-App WAF can block a request inside the service by IP address, user agent or header before the application code runs. Exploit Prevention goes further and blocks an exploit that passed the WAF by watching what the application does with the request, such as the SQL query it builds or the file it opens. We enable detection everywhere in scope and blocking where a false positive cannot take down a legitimate customer.
What does the API inventory in App and API Protection show?
Every API endpoint the traced services expose, discovered from live traffic rather than from the documentation. Each endpoint is checked against posture rules drawn from the OWASP API Top 10, so an endpoint that is unauthenticated, undocumented or overly permissive is flagged, and Endpoint Scanning confirms whether it is reachable from outside and whether it demands authentication. It is usually the first time the list of real endpoints and the list of documented endpoints have been compared.
What does Critical Cloud do with App and API Protection every month?
Managed Observability reviews the signals that fired and narrows the rules that matched legitimate traffic without muting the technique. It checks that new services with a tracer have protection enabled where they face the internet. It reviews the API inventory for endpoints that appeared since last month, and reports what was seen, blocked and routed. Under Critical Support an attack signal pages our engineers, 24x7, and they block the source and contain the service before the owner is woken.
- Datadog products: every product, and how we implement and run each one
- APM and Runtime Code Analysis: the tracer this runs on, and the vulnerability in the running code that the attack is aiming at
- Cloud SIEM: the same attacker, seen in the logs the estate already sends
- Code Security Accelerator: ASM and Software Composition Analysis configured, with a findings baseline and a triage model, in four weeks
Seen in the trace. Blocked in the service. Answered by a person.
Tell us which services face the internet and whether APM is already on them. We will show you what App and API Protection would see today, which rules belong in blocking, and what it takes to have an engineer on the signal.