Akamai Security Products — In-Depth Technical Reference

How to read this library

The library is organised in three layers. Products describe what Akamai ships and how the engines actually make decisions. Engines (API Security, Behavioral DDoS) go one level deeper into detection scope, learning windows and tuning levers. Fundamentals cover the protocols and attack classes that the products exist to defend, so that a finding in a report can be traced back to a packet or a request.

Where each product sits in the stack

OSI layer        Threat                                Akamai control
---------------  ------------------------------------  -------------------------------------
L3/L4 network    SYN/UDP/ACK floods, amplification,     Prolexic (BGP/GRE scrubbing),
                 reflection, IP fragmentation           Edge platform absorption
L4 DNS           DNS flood, NXDOMAIN, water torture     Edge DNS (anycast), DNS Shield,
                                                        Protective/Recursive DNS
L7 web           HTTP flood, injection, RCE, LFI        App & API Protector (ASE + WAF)
L7 behavioural   Low-and-slow DDoS, brute force,        Behavioral DDoS Engine, Rate Controls,
                 parameter fuzzing                      Slow POST protection
L7 automation    Credential stuffing, scraping,         Bot Manager, Account Protector,
                 inventory hoarding, AI crawlers        Content Protector
L7 API           Shadow APIs, BOLA/BFLA, data leakage   API Security (Discovery/Posture/
                                                        Runtime/Testing)
Browser          Magecart, formjacking, skimming        Client-Side Protection & Compliance

Cross-cutting design principles

1. Detect at the edge, decide with context

Every Akamai security product runs on the same distributed edge platform, so decisions are made in the first millisecond of the request, close to the client, before the origin ever sees traffic. What differs between products is the context each engine adds: reputation history (Client Reputation), behavioural baselines (BDE), API schema knowledge (API Security), or population-level identity signals (Account Protector).

2. Scope your counting narrowly, scope your mitigation narrowly

The single largest cause of false-positive pain is a mitigation scope that is wider than the detection scope. Rate Controls historically counted per client identifier across an entire security policy; BDE deliberately narrows both counting and mitigation to HTTP method + hostname + path. Narrow scope means a misclassification affects one endpoint for ten minutes rather than an entire property.

3. Learn before you enforce

Behavioural systems — BDE, API Security Learning, Account Protector user risk — all require a clean traffic window before their output is trustworthy. Enabling mitigation during learning produces noise and destroys stakeholder confidence. The consistent guidance across products is: alert mode first, 7–14 days of clean traffic, review reports, tune, then enforce.

4. Feed the models clean data

Baselines learn from what reaches them. If bot traffic, scrapers and credential-stuffing noise are merely monitored rather than blocked, the baseline absorbs that noise as “normal”. Tuning Bot Manager, Client Reputation and the WAF into blocking mode is therefore not optional hygiene — it is a prerequisite for accurate behavioural detection.

5. Obfuscate sensitive data at capture time

API Security hashes sensitive values with a salt before they are stored, so investigators can correlate the same value across incidents without ever seeing it. The same philosophy shows up in Account Protector (identity signals are hashed) and Client-Side Protection (script behaviour is recorded, not user data).

Quick glossary