App & API Protector (AAP)

What AAP actually contains

The configuration model

Security Configuration
  |- Match Targets            (WHICH traffic: hostnames, paths, file extensions, APIs)
  |    -> binds traffic to ->  Security Policy
  |- Security Policy A                (production, blocking)
  |     |- Attack Groups + risk thresholds
  |     |- Rate policies (associated + action)
  |     |- Slow POST settings
  |     |- Client Reputation profiles
  |     |- Custom rules
  |     |- Exceptions / conditions / advanced overrides
  |- Security Policy B                (staging, alert only)
  |- Network lists, reusable across policies
  |- Versions -> activate to STAGING -> activate to PRODUCTION

Two rules save most teams from outages. First, match target order matters: the most specific match target that applies wins, so a broad /* target placed above a narrow /api/* target will swallow API traffic into the wrong policy. Second, always activate on staging first and replay representative traffic; the staging network uses the same code path as production.

Evaluation order within a request

1. Network list allow/deny and geo controls
2. Client Reputation evaluation
3. Rate controls / Slow POST / Behavioral DDoS
4. Custom rules
5. Adaptive Security Engine attack groups (WAF)
6. API constraints and specification validation
7. Bot detections and their actions

The practical consequence: a bypass at an earlier stage prevents later inspection. Putting an over-broad partner CIDR in an allow list disables the WAF for that partner — a common and painful finding in security reviews.

The Adaptive Security Engine

Traditional WAFs match a request against a list of regular expressions and block on the first hit, which produces both false positives and trivial bypasses. The ASE instead scores: each rule that fires contributes a weighted amount of risk to an attack group, and the action is taken when the accumulated score for that group crosses the configured threshold.

Attack groups

Risk levels and actions

Each group is set to a sensitivity or risk tolerance and an action — Alert, Deny, or a custom deny page. Start every group in Alert, run for one to two weeks, then promote group by group. Promote the low-noise, high-confidence groups (CMD, LFI, RFI) first; SQL and XSS on rich, user-generated content applications generate the most tuning work.

Tuning without disabling protection

• Exceptions at the finest granularity available: exclude a specific rule for a specific parameter on a specific path. Never disable an entire attack group to silence one endpoint.
• Use the “selected elements” exception so the rule still inspects other parts of the request.
• Validate with WSA: pivot on the triggering rule, then on the sample requests, before deciding whether a trigger is a false positive.
• Document each exception with a reason and an owner; unexplained exceptions accumulate and become permanent holes.

Rate Controls

Rate policies count requests from a client identifier within a scope and act when a threshold is exceeded.

• Average threshold — requests per second sustained over a two-minute window; catches steady abuse.
• Burst threshold — requests per second over a five-second sliding window; catches sudden spikes.
• Client identifier — IP, IP + User-Agent, or a session/bot cookie. IP alone over-blocks NATed corporate and mobile users; IP + User-Agent is a reasonable default.
• Penalty box — once triggered, the identifier is denied for 10 minutes.
• Bypass network lists — exclude monitoring, partners and known-good automation.

Rate Controls remain the correct tool for high-volume URL fuzzing and scraping, and for endpoints too volatile for behavioural baselining. They are a blunt instrument: the counting scope is usually shared across hostnames at the policy level, so a trigger can affect more traffic than intended. Where possible, pair them with BDE, which narrows counting and mitigation to method + hostname + path.

Slow POST protection

Configure a minimum acceptable body transfer rate and a grace period. Requests that fall below the rate after the grace period are aborted or denied. This is the specific defence against R-U-Dead-Yet and slowloris-style body attacks, which bandwidth-based monitoring never sees.

Client Reputation

Client Reputation scores IP addresses 1–10 based on behaviour observed across the entire Akamai platform, in categories such as Web Attackers, DoS Attackers, Scanning Tools, and Web Scrapers. Scores of 9–10 indicate very high confidence of malicious intent.

Recommended pattern: deny at 9–10 for the Web Attackers and DoS Attackers categories, alert at 7–8 and use those alerts to inform custom rules or bot actions. Reputation runs early in evaluation, so it removes obvious noise before the WAF spends CPU on it — and, importantly, before behavioural baselines learn from it.

API protections in AAP

• API definitions — register your APIs (base path, resources, methods) so traffic is classified as API rather than web.
• Specification validation — upload an OpenAPI/Swagger file and reject requests that violate the contract: unknown parameters, wrong types, out-of-range values, missing required fields.
• API request constraints — cap request body size, number of elements, and JSON/XML nesting depth. This is the direct defence against parser-exhaustion and billion-laughs style attacks.
• Positive security by default — where a spec exists, allow-listing the contract is strictly stronger than blocklisting attack patterns.

For discovery of undocumented APIs, sensitive-data classification and runtime behavioural incidents, AAP is complemented by API Security.

Operating model

1. Onboard in alert mode across all engines; nothing blocks on day one.
2. Baseline for 1–2 weeks and build a WSA dashboard per attack group and per rate policy.
3. Enable blocking progressively: reputation → high-confidence attack groups → remaining groups → rate controls → behavioural mitigation.
4. Review weekly: top triggering rules, top offending paths, top false-positive candidates, and any exception older than its justification.
5. Rehearse: keep a pre-built emergency policy version that raises sensitivity and enables aggressive rate limits, tested in staging, ready to activate.