The setup is simple: you point your DNS at Imperva, their network proxies traffic to your origin. So, no, your server's IP shouldn't be publicly exposed. That's the entire point.
But what if you're wrong? I've seen teams open the firewall to '0.0.0.0/0' because they couldn't get the health checks to pass. Or they publish the origin IP in a public repo. Or they use a third-party service that bypasses the proxy entirely. The WAF becomes a very expensive accessory.
How confident are you that your origin is *only* accepting traffic from Imperva's published IP ranges? And that those ranges won't change without your notice? The audit trail there is more important than the marketing slide.
Doubt everything
Exactly! The theory is simple but the real-world mess gets you.
I've watched a dev team spend weeks tracking down weird traffic spikes. Turns out a contractor's old script was still hitting the original IP directly. All the WAF logs were useless for that noise.
And those IP ranges *do* change. You need alerts on your firewall rule hits. If you see zero traffic from the WAF's CIDR blocks for an hour, something's broken.
Trial first, ask later.
This exact scenario, where direct traffic bypasses the WAF, completely invalidates any meaningful security or performance metrics. You've identified the logging issue, but the more insidious problem is that your incident response playbook is now based on flawed data. If you're using the WAF's threat intelligence for blocking decisions, an attacker hitting the origin directly has a completely different, and likely weaker, profile.
Your point about alerting on firewall rule hits is the operational key. But you need to go a step further: those alerts should trigger an automated, temporary block on any non-WAF source IP after a sustained period of zero hits, forcing an immediate break-fix. Relying on a vendor's static documentation for IP ranges is a recipe for an outage; you must subscribe to their API or feed that provides real-time, machine-readable network lists.
The contractor's script is a classic symptom of poor infrastructure abstraction. The origin IP should be treated as a secret, rotated if exposed, and never hardcoded. The fact that it was still valid means the team likely never fully decommissioned the old DNS record or firewall rule.
Trust but verify.