implementing-api-threat-protection-with-apigee

name	implementing-api-threat-protection-with-apigee
description	Implement API threat protection using Google Apigee policies including JSON/XML threat protection, OAuth 2.0, SpikeArrest, and Advanced API Security for OWASP Top 10 defense.
domain	cybersecurity
subdomain	api-security
tags	["apigee","api-gateway","threat-protection","json-threat-protection","xml-threat-protection","spike-arrest","oauth2","google-cloud","owasp-api-top-10"]
version	1.0
author	mahipal
license	Apache-2.0
nist_csf	["PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01"]

Implementing API Threat Protection with Apigee

Overview

Google Apigee is an enterprise API management platform that provides native security policies for threat protection, including JSON and XML content validation, OAuth 2.0 enforcement, SpikeArrest rate limiting, regular expression threat protection, and Advanced API Security for detecting malicious clients and API abuse patterns. Apigee operates as a reverse proxy that intercepts all API traffic, applying security policies before requests reach backend services, effectively shielding APIs against the OWASP API Security Top 10 threats.

When to Use

• When deploying or configuring implementing api threat protection with apigee capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Common Misconfigurations & Verification

• Policy attached but not in the flow: a JSONThreatProtection/SpikeArrest that isn't wired into the PreFlow (or sits behind a Condition that never matches) silently does nothing - verify proxy step placement.
• SpikeArrest vs Quota confusion: SpikeArrest smooths bursts; it is not a usage quota - use Quota for per-app limits and choose the right Identifier.
• Regex protection false sense of safety: signature regex misses encoded/obfuscated injection; pair it with schema validation and backend parameterization.
• OAuth without alg/scope checks: VerifyAccessToken without scope enforcement or with a weak token store allows over-broad access.
• Threat limits too loose: ContainerDepth/StringValueLength set high enough to still allow XML-bomb/DoS payloads.
• Conditions on Content-Type: a threat policy gated on Content-Type lets attackers skip it by changing the header.

How to verify it works: send a deeply nested/oversized JSON and an XML bomb and confirm a Fault before the backend; exceed the SpikeArrest rate and confirm a spike-arrest fault/429; replay injection payloads and confirm the RegEx policy blocks them; present expired/insufficient-scope tokens and confirm rejection; flip the Content-Type header to confirm threat policies still apply.

Prerequisites

• Google Cloud Platform account with Apigee organization provisioned
• Apigee X or Apigee hybrid environment configured
• Backend API services deployed and accessible from Apigee