Datadog ASM vs a Separate WAF: Which One Actually Blocks Attacks?
Datadog Application Security Monitoring detects attacks. It does not block them. Here's where the gap matters and what to do about it.
Datadog ASM vs a Separate WAF: Which One Actually Blocks Attacks?
If you've shopped for Datadog Application Security Monitoring (ASM), you've seen the marketing: "real-time attack detection," "blocks SQL injection," "prevents account takeover." It's all technically true and also misleading.
ASM is a detection product. By default it does not block anything — it observes traffic that already reached your application, classifies it as suspicious, and shows you the results in a dashboard. Blocking is a separate concern and a separate set of products.
This post is the part the marketing leaves out. If you're evaluating whether ASM is worth the line item, the answer depends on what you're actually trying to do, and whether you already have a WAF.
For a comparison of the broader observability + security stack, see the SecureNow vs Datadog page and the APM + security combined approach.
What ASM is actually doing
Datadog ASM is built on top of Datadog APM. It uses the same trace pipeline — every span your APM already collects — and runs pattern detection against the request bodies, headers, and parameters. The detection rules are based on:
- Known attack signatures (SQL injection patterns, XSS payloads, command injection)
- Known-bad user agents (sqlmap, nikto, masscan)
- Suspicious IP reputation (via Datadog's threat intelligence partners)
- Anomalous request patterns (rate, sequence, error rate)
When a match fires, ASM creates a security signal. The signal is visible in the ASM dashboard, can trigger alerts, and links to the originating trace for forensic depth.
This is genuinely useful. Knowing that someone is probing your app with SQL injection payloads is the first step. The catch is that "knowing" and "preventing" are different products.
The blocking gap
By default, an ASM detection means a Slack notification 5 seconds after the malicious request returned a response to the attacker. If the attack succeeded — say it dumped a database column via a SQL injection — ASM tells you the attack happened. It does not undo the breach.
To actually block, you have three options:
Option 1: An upstream WAF. Cloudflare WAF, AWS WAF, Imperva, or similar. The WAF inspects requests before they reach your app and drops or challenges them. ASM still runs in your app and catches anything the WAF missed. Cost: ASM + WAF subscriptions. For a 30-host SaaS, expect $510/month for ASM plus $200–$2,000/month for the WAF.
Option 2: ASM Protect (Datadog's in-app blocking). Released in late 2024 as an opt-in for specific frameworks (Java, .NET, Python, Node Express). It instruments the app to block requests that match a rule. The rule set is limited to ~80 patterns at the moment, framework support is partial, and the latency cost is real (~10–20ms per blocked request). It's promising but not yet a full WAF replacement.
Option 3: A separate IP-level firewall. Block at the network layer based on IP reputation, behavior, or explicit lists. This catches a different class of threats than ASM — bots, scrapers, credential-stuffing rings. The free SecureNow firewall is in this category, blocking 500k+ known-bad IPs at the HTTP layer (with optional TCP and iptables layers).
Most enterprise teams run all three. Most startups run option 3 only and skip ASM entirely until traffic justifies it.
When ASM is worth it
ASM earns its keep when:
- You already have a WAF doing the bulk blocking, and you want the long tail of detection
- You have a SOC team that actually responds to security signals (not "the on-call engineer hopes for the best")
- Your application handles regulated data (healthcare, financial, government) where post-hoc detection has compliance value
- You're already on Datadog APM and the marginal cost of adding ASM is low
ASM is overkill when:
- You don't have a WAF (you're paying for detection of attacks that aren't being blocked)
- Your team is small and there's no one to triage signals
- Your bigger problem is bots and scrapers (ASM is not designed for that)
The bot problem ASM doesn't solve
ASM detects attacks that exploit application logic. It does not, in any meaningful way, address bot traffic, scraping, credential stuffing, or AI-training crawlers. These categories require:
- Rate limiting at the IP / ASN level
- Bot fingerprinting (TLS, JA3, behavioral)
- Real-time blocklists from threat-intelligence feeds
- Allowlist for legitimate crawlers (Googlebot, GPTBot, ClaudeBot)
This is a different product category — sometimes called "bot management" — sold separately by Cloudflare ($25–$200/month per zone), DataDome, PerimeterX, and others. Datadog has limited capabilities here.
The effect is that a typical mid-sized SaaS ends up running:
- Datadog APM ($600–$5,000/month)
- Datadog ASM ($510/month for 30 hosts)
- Cloudflare WAF ($20–$200/month)
- A bot management product ($100–$2,000/month)
Total: $1,200–$8,000/month for what is, conceptually, "I want to know about and block bad traffic to my app."
The collapsed alternative
The case for tools that combine these into one product is mostly about the operational cost of stitching them together, not the licensing cost. Three separate dashboards mean three separate forensic flows during an incident. Three separate billing cycles, three separate vendor relationships, three separate authentication systems.
Tools like SecureNow collapse the four into one: APM + ASM-like detection + IP firewall + bot blocking, in a single product with one dashboard and one bill. The tradeoff: less depth on each individual feature than the best-of-breed point solution. For most SaaS teams under 200 engineers, the depth isn't worth the operational cost. For very large enterprise teams with dedicated platform engineering, it might be.
Practical recommendation
If you're deciding right now:
- Already have ASM and a WAF, dashboards work, team responds: keep what you have.
- Have ASM but no WAF: enable ASM Protect on your most-exposed services if your framework supports it. Otherwise, your detection-without-blocking posture is mostly theatre.
- Have neither, evaluating: start with a free IP firewall (SecureNow Firewall takes 5 minutes), add detection from your existing observability stack, and revisit ASM only if your business model justifies the line item.
- Tired of stitching products: look at consolidated tools — the APM + security in one tool approach.
The marketing-question version of this post would tell you ASM is essential. The honest version is that ASM is a luxury good for teams that already have the foundation. Build the foundation first.
Related
Frequently Asked Questions
Does Datadog ASM block attacks?
Datadog ASM detects attack patterns in production traces and surfaces them in the dashboard. It does not, by default, block requests inline. Blocking requires a separate WAF (Cloudflare, AWS WAF, etc.) or Datadog's newer in-app blocking feature, which is opt-in and limited to a subset of frameworks.
What's the difference between ASM and a WAF?
A WAF (web application firewall) sits in the request path and drops or challenges traffic before it reaches your app. ASM observes traffic that already reached your app and classifies it. ASM gives forensic depth; a WAF prevents the request from happening at all.
Can I use both?
Yes, and most enterprise teams do. The WAF blocks the obvious bad traffic; ASM catches the long tail (business-logic abuse, slow-rolling credential stuffing) the WAF can't see. The cost adds up — typically $17/host/month for ASM plus a separate WAF subscription.
Is there an alternative that does both?
Yes — tools that combine an IP-level firewall with span-based detection in the same product. SecureNow ships both as one package; the firewall blocks traffic inline using a 500k-IP blocklist plus per-app rules, and the same trace data feeds AI-powered detection.
Recommended reading
Aggregated, anonymized data from 1.2B requests across the SecureNow customer fleet. Top anomaly types, peak hours, and the day-of-week patterns nobody publishes.
May 9An honest, side-by-side comparison of the ten most-deployed application security monitoring tools — from enterprise platforms to free open-source options.
May 9A quarterly tally of malicious npm packages, the major incidents, and detection patterns. April 2026 set a new record at 847 confirmed malicious packages — here's what they did and how to detect them.
May 9