Imperva
CDN and WAF
Also known as: Incapsula, Distil Networks, Imperva Advanced Bot Protection
Identifiable by an incident ID in the block page and by its incap cookies, and notable for serving challenges and blocks on a 200 as readily as on a 403.
Imperva's cloud WAF was Incapsula, and its bot management absorbed Distil Networks after the 2019 acquisition, so a single Imperva deployment can present several generations of block page and challenge. The one constant is the incident ID, a long numeric reference in the block page that the site operator can look up.
The most operationally important thing about Imperva is that it does not reserve error status codes for refusals. A challenge page and a block page are routinely served on a 200, which means a client that only reads status codes will record a successful fetch of a page that contains no content. The incident ID string in the body is a far more reliable detector than the status line.
Imperva's product documentation moved to the Thales documentation portal after the acquisition and renders client-side, so the entries below reflect observable wire behaviour rather than published response specifications.
How to identify it
- A body containing Request unsuccessful. Incapsula incident ID followed by a long numeric reference.
- Cookies named visid_incap_<siteid>, incap_ses_<n>_<siteid>, or nlbi_<siteid>.
- An X-Iinfo response header, or X-CDN: Imperva.
- Requests to a path under /_Incapsula_Resource, which is the challenge script endpoint.
- A reese84 cookie, which belongs to the Advanced Bot Protection layer that came from Distil.
Headers
- X-Iinfo: Imperva diagnostic header carrying edge routing information. A strong positive marker for attribution.
- X-CDN: Set to Imperva on some deployments.
Cookies
- visid_incap_<site id>: Long-lived visitor identifier, scoped to a numeric site id. The site id in the cookie name is a useful way to confirm you are looking at Imperva rather than a lookalike.
- incap_ses_<n>_<site id>: Session cookie set once the lightweight challenge has run. Requests without it are treated as unverified.
- reese84: Advanced Bot Protection token, produced by the client-side interrogation script. Its absence on a protected endpoint is itself a signal.
Status codes
403 Access denied with incident ID
Blocked. Observed behaviour.
The WAF or bot protection layer refused the request and issued an incident reference.
What triggers it
- A bot classification or WAF rule match.
- Address reputation, or an absent or invalid reese84 token on a protected endpoint.
How to confirm it
- Request unsuccessful. Incapsula incident ID in the body.
- X-Iinfo on the response.
What to do about it
- Capture the incident ID. It is the only identifier that lets a site operator find your request, and Imperva block pages exist specifically so that a user can quote it to the site owner.
- Do not retry unchanged. The classification is sticky for the session and often for the address.
HTTP/2 403 content-type: text/html x-iinfo: 7-12345678-12345679 NNNN CT(1 1 0) RT(1780000000 12) q(0 0 0 0) r(2 2) <html><head><title>example.com</title></head><body> <iframe src="/_Incapsula_Resource?CWUDNSAI=..." frameborder=0 width="100%" height="100%"></iframe> Request unsuccessful. Incapsula incident ID: 7-123456789012345678
200 Challenge or block page on a success status
Deceptive. Observed behaviour.
The status line reports success while the body is an interstitial challenge or a denial. This is routine Imperva behaviour rather than an edge case.
What triggers it
- The lightweight JavaScript challenge, which serves an iframe, sets a session cookie, and reloads.
- Operator configurations that prefer not to signal a block to automated clients.
How to confirm it
- An incident ID string in a 200 response body.
- A tiny body relative to the real page, usually just an iframe or a script tag.
- A reference to /_Incapsula_Resource.
What to do about it
- Detect on the body. Any pipeline in front of an Imperva site that keys success on the status code will store challenge pages as though they were content.
- Treat a response under a few kilobytes on a page that should be large as suspect by default.
429 Rate limited
Rate limited. Observed behaviour.
A rate policy was exceeded.
What triggers it
- Request volume above a configured threshold for the address or session.
How to confirm it
- X-Iinfo present, sometimes with retry-after.
What to do about it
- Back off and reduce concurrency. Unlike the block responses, this one clears with time.
If you run a site behind it
- Keep the incident ID visible on every block page. It is the whole support workflow, and stripping it for aesthetic reasons makes false positives untraceable.
- Serving challenges on a 200 hides failures from your own monitoring as effectively as it hides them from scrapers. Consider whether your uptime checks can tell the difference.
If your traffic is being caught by it
- Status code alone is close to useless here. Detect Imperva by the incident ID string, the incap cookies, or X-Iinfo.
- A response that is suspiciously small is the cheapest reliable heuristic in front of an Imperva site.