Akamai App & API Protector study materials
Akamai App & API Protector study resources

Akamai App & API Protector cheat sheet

Akamai App & API Protector · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.