Our consumers are requesting us to log credentials when there’s a Spike Arrest trigger.
But our Spike arrest policy is currently set to execute before authentication policy, which we think is the right order, so that in the case of a ddos attack we don’t overload the resources by checking for authentication for every spam request. Is this a right assumption or having Advanced API security and Cloud Armor WAF controls should prevent this from ahppening automatically?
Or in other words, is it safe to keep the spike arrest policy after the authentication policy?
I think there’s a bit of a misunderstanding here. At the moment your proxy is effectively open to a denial-of-service issue because SpikeArrest only works sensibly if it has a trustworthy identifier to group requests by. If you don’t configure a trusted identifier it falls back to a single bucket for every request, so an attacker can easily exhaust that bucket and take legitimate users offline. For that reason, SpikeArrest needs to be applied after authentication so the policy can enforce limits per authenticated client, and critically so it can key those limits to an identifier that actually represents the authenticated consumer (for example, the client_id associated with the application).
Controls like Advanced API Security or Cloud Armor can help against large volumetric attacks, but they don’t remove the need to scope SpikeArrest correctly inside the proxy - those controls are complementary, not a replacement for per-client rate limiting.
One more important note: please don’t log credentials. Storing raw secrets or passwords in logs is dangerous and unnecessary. If you need telemetry for debugging or abuse investigation, log only non-sensitive identifiers - for example a client_id or a hashed/anonymised identifier - and ensure logs are redacted, encrypted at rest, and accessible only to authorised people for a limited retention period. That gives you the visibility you need without creating a new data-leak risk.
One thing to clarify is - we’re not logging credentials in clear text. The masked api key with the first few chars is all we log, in order to group the calls by client for logging dashboards.