Coraza → Imperva
Coraza ↔ Imperva: integration to migration path.
Imperva stays in front, in block, while Coraza deploys behind it at the origin in detection-only, scoring real traffic without ever degrading Imperva's posture. Only once Coraza has tuned to parity and proved itself in dual-WAF do Imperva's signature categories move to Monitor — one reversible phase at a time, no cutover day and no full-app regression test.
This is a signature-WAF migration, not a full one. Account-takeover, Client-Side Protection, Advanced Bot Protection, and DDoS have no honest OSS parity and stay on Imperva — we say so up front because the rest only matters if you can trust it.
The idea
Take the signature tier. Keep the network-effect tiers.
The topology that makes this zero-outage: Imperva Cloud WAF keeps owning the PoP, TLS, DDoS, and its bot and ATO stack at the edge, while Caddy or Envoy with Coraza runs at the origin behind the Imperva-to-origin CIDR allowlist. Coraza scores every request and logs it CRS-tagged in your SIEM, under your retention, in detection-only — so we build tuning confidence on real traffic without touching Imperva's blocking. Once Coraza matches Imperva's signature coverage, we invert the signature tier to Monitor and, if bundling allows, drop that SKU. Everything that is genuinely network-effect — bot fingerprints, the breach corpus, Magecart reputation, the scrubbing network — stays on Imperva by design.
The phases
Six steps. Each one reversible.
Baseline & inventory
We export each site's Imperva policy via UI and Terraform, capture enabled signatures, per-category sensitivity, IncapRule intent, and ATO/CSP/ABP enrollment, plus the largest legitimate POST per route. SecureSphere policy XML is hand-ported, not Cloud-WAF-importable. Read-only.
Coraza goes live at origin in DETECT
Caddy or Envoy with Coraza stands up on every origin host in a canary site's pool, running CRS at paranoia level 1 in detection-only. The origin security group is restricted to Imperva PoP CIDRs; Imperva still blocks at the edge.
Tune Coraza exclusions; align to Imperva coverage
We pull 30 days of Imperva incidents, map each signature to a CRS range, hand-write SecRules for Imperva-specific signatures with no CRS analogue, and merge per-route exclusions until under 1 percent of legitimate traffic crosses the block threshold. Still detection-only.
Coraza to BLOCK; dual-WAF defence in depth
SecRuleEngine turns On per site — canary first at the lowest blast radius, then 10, 50, 100 percent via graceful reload. Both WAFs block; Coraza is authoritative as the bottom tier, correlated to Imperva incidents via X-Iinfo.
Invert: Imperva signatures to Monitor, Coraza authoritative
Imperva's attack-signature categories move to Monitor while ATO, Client-Side Protection, Advanced Bot Protection, DDoS, and Threat Radar stay in block. Coraza is the sole signature-WAF; business-logic IncapRules stay on Imperva as virtual-patching.
Retire the Imperva signature-WAF SKU tier
If bundling permits, the contract is renegotiated to drop the signature-WAF tier while ATO, Client-Side Protection, Advanced Bot Protection, and DDoS Premium are retained, along with the PoP, TLS, and CDN. Imperva has historically resisted unbundling this — the outcome may be no SKU reduction, with Coraza simply treated as redundant defence in depth.
Feature parity
Where Coraza matches Imperva, and where it does not.
| Capability | Coraza | Imperva | Parity |
|---|---|---|---|
| Rule engine | Coraza SecRules (ModSecurity v3 grammar, ~95%) | Imperva attack-signature engine plus IncapRules | Partial |
| Managed ruleset | OWASP CRS PL1-PL4 (community-paced) | Imperva ADC signature library plus managed updates | At parity |
| Anomaly scoring | OWASP CRS inbound >=5 / outbound >=4 | Per-category sensitivity (Low/Med/High) | Partial |
| Bot detection / ML | None at parity (JA3/JA4 via proxy header only) | Imperva Advanced Bot Protection (incl. mobile SDK) | SaaS only |
| Account-takeover | App-layer rate-limit plus HIBP substitute | Imperva ATO (cross-customer breach corpus plus ML) | SaaS only |
| Client-side protection | Self-hosted CSP report-uri (no JS reputation feed) | Imperva Client-Side Protection (Magecart) | SaaS only |
| DDoS absorption | None (needs Shield Advanced / Cloudflare) | Imperva DDoS L3/L4/L7 scrubbing network | SaaS only |
| Rate limiting | Caddy rate_limit / Envoy local_rate_limit (no SecRule counter) | IncapRules rate-limit primitives | SaaS only |
| IP reputation | CrowdSec bouncer / cron CIDR list | Imperva Threat Radar reputation | Partial |
| Body inspection | SecRequestBodyLimit 13 MB at origin | Imperva PoP inspection, plan-dependent cap | At parity |
| Logging / SIEM | SecAuditLogFormat JSON, full per-rule chain | Imperva SIEM connector / syslog, partial body | At parity |
| Cost model | Compute plus ops on existing origin | Per-site / per-bandwidth SKU bundle | Partial |
| Compliance (PCI 6.4.2 / SOC 2) | Self-owned config-in-git plus log custody | Vendor SOC backstop plus brand attestation | Partial |
What we're honest about
The caveats most vendors leave out.
Account-takeover and Magecart stay on Imperva
Imperva's ATO is backed by a cross-customer breach corpus and ML trained on attacker-tool fingerprints; its Client-Side Protection carries cross-customer reputation of malicious third-party JS in checkout flows. The mechanisms are reproducible — HIBP k-anonymity, CSP report-uri, a JS allowlist — but the network-effect data feed is not. These stay on Imperva. A migration claiming Coraza replaces them is being dishonest.
Advanced Bot Protection and DDoS are SaaS-only
The iOS/Android bot SDK with attestation and cross-customer attacker-tool fingerprints has no OSS equivalent, and Imperva's scrubbing network absorbs attacks larger than a typical origin's transit. CrowdSec and JA3/JA4 catch script-kiddies; AWS Shield Advanced or Cloudflare are SaaS alternatives, not OSS. We keep the bot and DDoS tiers on Imperva and scope the gap plainly.
There is no full retirement — and we say so
This plan has no Phase 6. The exit posture is Coraza authoritative for the signature-WAF plus IncapRules for virtual-patching business logic, with Imperva authoritative for everything else. Any plan claiming full Imperva retirement while you still carry customer credentials, payment data, or B2C bot pressure is misrepresenting the parity gap.
Rate-limiting, IP reputation, and SKU economics
Stateful rate-limiting and IP-reputation are not SecRule constructs — they layer at the proxy (Caddy rate_limit, Envoy local_rate_limit) or CrowdSec, as a separate workstream. And the Phase 5 SKU drop is a commercial negotiation, not a technical step: Imperva re-bundles every renewal, so we have the account-team conversation before you commit Phase 1 spend rather than promising savings the contract may not allow.
Why this beats a flag day
Reversible per phase. Soaked before the SKU drops.
Through Phase 4 every change rolls back inside the documented window — under 5 minutes to stop Coraza or revert to detection-only, under 10 minutes to flip Imperva signatures back to block via Terraform. We never drop the SKU on optimism: Imperva's signature categories must sit in Monitor for at least 30 consecutive days with Coraza-missed blocks under an agreed budget before the contract is renegotiated. Phase 5 is the honest exception — re-enabling Imperva is technical and fast, but re-adding a cancelled SKU is a commercial step, so that is the last reversible point and we treat it as one.
See whether your signature-WAF migrates off Imperva cleanly.
A call with a senior security engineer. We export your Imperva policy, map every signature and IncapRule to CRS or virtual-patching, draw the hard line around ATO, Client-Side Protection, bot, and DDoS that stay on Imperva, and tell you honestly whether the SKU bundling even allows a cost reduction.
Map my migration →