Akamai App & API Protector cheat sheet
Akamai App & API Protector · Keep the key ideas within reach.
App and API Security
API security enforcement points: API Gateway (rate limiting, authN/Z, schema validation) vs WAF (signature/behavioral inspection of HTTP traffic) vs API discovery (shadow/zombie API inventory).
OWASP API Top 10 categories to map controls to: BOLA (object-level authZ), broken authentication, excessive data exposure, lack of resource/rate limiting, broken function-level authZ, mass assignment, SSRF, misconfiguration, improper inventory management, unsafe consumption of third-party APIs.
BOLA test: does the endpoint authorize the object ID against the caller's identity, not just authenticate the token? Broken object-level authorization is the top API risk and is not detected by signature WAF alone.
Positive security model: allow only known methods, paths, parameters, and schema-conformant bodies; reject anything outside the declared API contract (schema-based validation).
Negative security model: block known-bad signatures/patterns; effective against known CVEs and generic attack payloads but blind to business-logic abuse.
JWT validation checks: signature (alg must be pinned, reject 'none'), exp/nbf, iss/aud, and scope/role claims; missing alg pinning enables algorithm-confusion attacks.
Sensitive data exposure controls: response filtering/redaction at the gateway, field-level allowlists, and removal of verbose error/debug fields from API responses.
Shadow API risk: undocumented endpoints receive no security review; discovery via traffic analysis and spec comparison (OpenAPI vs observed) is a prerequisite to protection.
Rate limiting dimensions: per-IP, per-token/session, per-endpoint, and per-tenant; token-based limits defeat IP rotation by distributed clients.
Bot & Agent Control
Bot mitigation tiers: allow verified good bots (search engines, monitoring) by validated identity; challenge unknown/neutral traffic; block or tarpit confirmed malicious automation.
Detection signals: TLS/JA3-JA4 fingerprint, HTTP header order and anomalies, IP reputation/ASN, request rate and timing regularity, mouse/keyboard telemetry, and browser environment consistency.
Proof-of-work and JS challenges impose compute cost on automated clients while remaining transparent to real browsers; CAPTCHA is a fallback for high-confidence suspicion.
Verified bot validation requires cryptographic verification of the claimed identity (e.g., reverse DNS plus published IP ranges for that crawler); a spoofed User-Agent alone is not verification.
Credential-stuffing signature: many accounts attempted from few IPs, or one account from many IPs, with low per-IP request rates; detection needs cross-request aggregation, not per-request signatures.
Bot behavior categories: scraping, account takeover/credential stuffing, carding/inventory hoarding, ad fraud, and API abuse; each needs a distinct response policy.
Agent/automation control: distinguish sanctioned automation (partner integrations, RPA with API keys) from unsanctioned agents; apply policy by authenticated identity plus behavioral score.
Rate-based bot defense alone is evadable via distributed low-and-slow traffic; combine behavioral anomaly scoring with device/browser fingerprinting.
Bot challenge response codes and actions: monitor, challenge (JS/PoW), tarpit (slow response), block; choose the least disruptive action meeting the risk tolerance.
Web Application and API Protection (WAAP)
WAAP convergence: WAF + API protection + bot management + DDoS + (often) client-side protection in one control plane, sharing telemetry for correlated detection.
WAF deployment modes: inline reverse proxy (full inspection, can block), out-of-band/connect-only (monitor and alert only), and SDK/agent-based; blocking requires inline placement.
Rule tuning lifecycle: start in alert/monitor, baseline false positives, tune or add exceptions, then enforce; exceptions should be scoped narrowly (path/parameter) rather than global.
Attack coverage layers: network/volumetric (L3/L4), protocol (L7 floods), and application-logic (injection, auth abuse); each layer needs a matching control.
OWASP Core Rule Set concepts: paranoia levels (higher = stricter, more false positives), anomaly scoring thresholds, and per-rule transformations/normalization to defeat encoding evasion.
Virtual patching: deploy WAF signatures for a known CVE before the origin is patched; reduces exposure window but is not a substitute for patching.
Negative vs positive security in WAAP: signatures catch known attack classes; schema/allowlist validation catches unknown and logic abuse; effective WAAP combines both.
False-positive triage data: rule ID, matched parameter, request path, client fingerprint; tune by exception scoped to the specific rule+path, not by disabling the rule class.
API schema enforcement in WAAP: validate method, path, query/body against OpenAPI spec; reject undeclared parameters and malformed content types before reaching origin.
DDoS Protection
DDoS attack layers: volumetric (L3/L4, bandwidth/packet floods like UDP/ICMP amplification), protocol/state-exhaustion (SYN flood, L7 connection floods), and application-layer (HTTP flood, slowloris, API abuse).
SYN flood defense: SYN cookies and SYN-proxy terminate half-open connections at the edge so the origin never holds state for unvalidated clients.
Amplification/reflection: attacker spoofs victim IP and sends to open resolvers/services; mitigation includes rate limiting and blocking spoofed-source traffic (BCP38/ingress filtering).
Anycast scrubbing: route attack traffic to distributed scrubbing centers via BGP/anycast, filter, and forward clean traffic to origin; capacity must exceed peak attack volume.
Always-on vs on-demand: always-on provides instant mitigation with no detection delay; on-demand relies on detection/trigger and risks a ramp-up window.
L7 flood detection: monitor request rate, concurrent connections, and per-client fairness; rate limiting plus behavioral scoring distinguishes floods from legitimate spikes.
Slowloris/slow-read: keep connections open with partial requests to exhaust server threads; mitigation is connection timeouts, minimum data-rate enforcement, and edge buffering.
Origin hiding: DNS obfuscation plus restricting origin to accept traffic only from scrubbing/proxy ranges prevents direct-to-origin attacks that bypass mitigation.
Mitigation efficacy metrics: time-to-mitigate, scrubbing capacity headroom, false-positive drop rate, and origin health during attack; capacity must be provisioned above observed peak.
App and API Security
API security enforcement points: API Gateway (rate limiting, authN/Z, schema validation) vs WAF (signature/behavioral inspection of HTTP traffic) vs API discovery (shadow/zombie API inventory).
OWASP API Top 10 categories to map controls to: BOLA (object-level authZ), broken authentication, excessive data exposure, lack of resource/rate limiting, broken function-level authZ, mass assignment, SSRF, misconfiguration, improper inventory management, unsafe consumption of third-party APIs.
BOLA test: does the endpoint authorize the object ID against the caller's identity, not just authenticate the token? Broken object-level authorization is the top API risk and is not detected by signature WAF alone.
Positive security model: allow only known methods, paths, parameters, and schema-conformant bodies; reject anything outside the declared API contract (schema-based validation).
Negative security model: block known-bad signatures/patterns; effective against known CVEs and generic attack payloads but blind to business-logic abuse.
JWT validation checks: signature (alg must be pinned, reject 'none'), exp/nbf, iss/aud, and scope/role claims; missing alg pinning enables algorithm-confusion attacks.
Sensitive data exposure controls: response filtering/redaction at the gateway, field-level allowlists, and removal of verbose error/debug fields from API responses.
Shadow API risk: undocumented endpoints receive no security review; discovery via traffic analysis and spec comparison (OpenAPI vs observed) is a prerequisite to protection.
Rate limiting dimensions: per-IP, per-token/session, per-endpoint, and per-tenant; token-based limits defeat IP rotation by distributed clients.
Bot & Agent Control
Bot mitigation tiers: allow verified good bots (search engines, monitoring) by validated identity; challenge unknown/neutral traffic; block or tarpit confirmed malicious automation.
Detection signals: TLS/JA3-JA4 fingerprint, HTTP header order and anomalies, IP reputation/ASN, request rate and timing regularity, mouse/keyboard telemetry, and browser environment consistency.
Proof-of-work and JS challenges impose compute cost on automated clients while remaining transparent to real browsers; CAPTCHA is a fallback for high-confidence suspicion.
Verified bot validation requires cryptographic verification of the claimed identity (e.g., reverse DNS plus published IP ranges for that crawler); a spoofed User-Agent alone is not verification.
Credential-stuffing signature: many accounts attempted from few IPs, or one account from many IPs, with low per-IP request rates; detection needs cross-request aggregation, not per-request signatures.
Bot behavior categories: scraping, account takeover/credential stuffing, carding/inventory hoarding, ad fraud, and API abuse; each needs a distinct response policy.
Agent/automation control: distinguish sanctioned automation (partner integrations, RPA with API keys) from unsanctioned agents; apply policy by authenticated identity plus behavioral score.
Rate-based bot defense alone is evadable via distributed low-and-slow traffic; combine behavioral anomaly scoring with device/browser fingerprinting.
Bot challenge response codes and actions: monitor, challenge (JS/PoW), tarpit (slow response), block; choose the least disruptive action meeting the risk tolerance.
Web Application and API Protection (WAAP)
WAAP convergence: WAF + API protection + bot management + DDoS + (often) client-side protection in one control plane, sharing telemetry for correlated detection.
WAF deployment modes: inline reverse proxy (full inspection, can block), out-of-band/connect-only (monitor and alert only), and SDK/agent-based; blocking requires inline placement.
Rule tuning lifecycle: start in alert/monitor, baseline false positives, tune or add exceptions, then enforce; exceptions should be scoped narrowly (path/parameter) rather than global.
Attack coverage layers: network/volumetric (L3/L4), protocol (L7 floods), and application-logic (injection, auth abuse); each layer needs a matching control.
OWASP Core Rule Set concepts: paranoia levels (higher = stricter, more false positives), anomaly scoring thresholds, and per-rule transformations/normalization to defeat encoding evasion.
Virtual patching: deploy WAF signatures for a known CVE before the origin is patched; reduces exposure window but is not a substitute for patching.
Negative vs positive security in WAAP: signatures catch known attack classes; schema/allowlist validation catches unknown and logic abuse; effective WAAP combines both.
False-positive triage data: rule ID, matched parameter, request path, client fingerprint; tune by exception scoped to the specific rule+path, not by disabling the rule class.
API schema enforcement in WAAP: validate method, path, query/body against OpenAPI spec; reject undeclared parameters and malformed content types before reaching origin.
DDoS Protection
DDoS attack layers: volumetric (L3/L4, bandwidth/packet floods like UDP/ICMP amplification), protocol/state-exhaustion (SYN flood, L7 connection floods), and application-layer (HTTP flood, slowloris, API abuse).
SYN flood defense: SYN cookies and SYN-proxy terminate half-open connections at the edge so the origin never holds state for unvalidated clients.
Amplification/reflection: attacker spoofs victim IP and sends to open resolvers/services; mitigation includes rate limiting and blocking spoofed-source traffic (BCP38/ingress filtering).
Anycast scrubbing: route attack traffic to distributed scrubbing centers via BGP/anycast, filter, and forward clean traffic to origin; capacity must exceed peak attack volume.
Always-on vs on-demand: always-on provides instant mitigation with no detection delay; on-demand relies on detection/trigger and risks a ramp-up window.
L7 flood detection: monitor request rate, concurrent connections, and per-client fairness; rate limiting plus behavioral scoring distinguishes floods from legitimate spikes.
Slowloris/slow-read: keep connections open with partial requests to exhaust server threads; mitigation is connection timeouts, minimum data-rate enforcement, and edge buffering.
Origin hiding: DNS obfuscation plus restricting origin to accept traffic only from scrubbing/proxy ranges prevents direct-to-origin attacks that bypass mitigation.
Mitigation efficacy metrics: time-to-mitigate, scrubbing capacity headroom, false-positive drop rate, and origin health during attack; capacity must be provisioned above observed peak.