Cloud Application and Network Security 10-12-2022

Cloud Application and Network Security
Cloud Application and Network Security 1

Contents
Contents
Get Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Cloud Application Security Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Cloud Security Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Homepage Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Cloud Security Trial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Onboarding Cloud WAF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Onboarding a Site - Web Protection and CDN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Onboarding and Keeping Your Own CDN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Onboarding FAQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
WebSocket Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Customer Setup Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Cloud Maintenance Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Release Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
October 2, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
September 18, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
September 11, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
September 4, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
August 28, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
August 21, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
August 14, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
August 7, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
July 31, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
July 24, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
July 17, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
July 10, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
July 3, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
June 26, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
June 19, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
June 12, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
June 6, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
May 29, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
May 22, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
May 15, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
May 1, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
April 24, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
April 17, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
April 10, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
April 3, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
March 27, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Contents
March 20, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

March 13, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
March 6, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
February 27, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
February 6, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
January 30, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
January 23, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
January 16, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
January 9, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
January 2, 2022 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
2021. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
December 12, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
December 5, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
November 21, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
November 7, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
October 31, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
October 24, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
October 17, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
October 10, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
October 3, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
September 26, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
September 5, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
August 29, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
August 22, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
August 15, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
August 8, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
August 1, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
July 25, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
July 11, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
July 4, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
June 27, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
June 13, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
June 6, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
May 30, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
May 23, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
May 9, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
May 2, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
April 25, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Contents
April 18, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

April 11, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
March 7, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
February 28, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
February 7, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
January 31, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
January 24, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
January 17, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
January 10, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
January 3, 2021 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
December 13, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
October 25, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
October 18, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
October 11, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
October 4, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
September 6, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
August 30, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
August 23, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
August 16, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
August 2, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
July 26, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
July 19, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
July 12, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
July 5, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
June 28, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
June 21, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
June 14, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
June 7, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
May 31, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
May 24, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
May 17, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Contents
May 10, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

April 26, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
April 5, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
March 29, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
March 15, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
March 8, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
March 1, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
January 26, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
January 19, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
January 12, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
January 5, 2020 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
2019. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
October 27, 2019 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
October 6, 2019 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
2019-09-08 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
2019-09-01 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
2019-08-25 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
2019-08-18 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
2019-08-11 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
2019-08-04 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
2019-07-28 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
2019-07-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
2019-07-14 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
2019-07-07 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
2019-06-23 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
2019-06-16 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
2019-06-02 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
2019-05-26 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
2019-05-19 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
2019-05-05 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
2019-04-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
2019-04-14 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Contents
2019-04-07 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

2019-03-31 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
2019-03-24 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
2019-03-17 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
2019-03-10 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
2019-03-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
2019-02-17 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
2019-02-10 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
2019-02-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
2019-01-27 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
2019-01-13 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
2019-01-06 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
2018. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
2018-12-09 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
2018-12-02 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
2018-11-18 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
2018-11-04 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
2018-10-28 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
2018-10-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
2018-10-14 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
2018-10-07 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
2018-09-16 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
2018-09-02 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
2018-08-19 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
2018-07-30 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
2018-07-22 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
2018-07-15 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
2018-07-01 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
2018-06-24 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
2018-06-17 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
2018-06-10 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
2018-06-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
2018-05-29 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
2018-05-27 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
2018-05-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
2018-05-13 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
2018-04-29 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
2018-03-25 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
2018-03-18 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
2018-03-11 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
2018-03-04 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

Contents
2018-02-18 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

2018-02-11 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
2018-02-04 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
2018-01-28 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
2018-01-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
2018-01-14 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
2018-01-07 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
2017. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
2017-12-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
2017-11-05 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
2017-10-29 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
2017-10-22 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
2017-10-01 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
2017-09-24 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
2017-09-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
2017-08-20 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
2017-08-13 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
2017-08-06 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
2017-07-30 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
2017-07-23 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
2017-07-16 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
2017-07-09 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
2017-06-25 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
2017-06-18 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
2017-06-11 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
2017-06-04 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
2017-05-14 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
2017-05-07 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
2017-04-02 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
2017-03-26 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
2017-03-12 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
2017-03-05 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
2017-02-26 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
2017-02-19 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
2017-02-12 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
2017-01-29 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
2017-01-22 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
2017-01-15 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
2017-01-08 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
2017-01-01 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
2016. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

Contents
2016-11-20 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

2016-11-06 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
2016-10-09 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
2016-10-02 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
2016-09-04 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
2016-08-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
2016-07-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
2016-06-26 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
2016-06-05 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
2016-05-22 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
2016-05-08 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
2016-05-01 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
2016-04-24 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
2016-04-17 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
2016-04-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
2016-03-06 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
2016-02-21 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
2016-02-14 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
2016-01-03 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
2015. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
2015-12-06 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
2015-11-22 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Recently Mitigated CVEs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Account Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Account Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
Manage Account Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Sub Accounts Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Notification Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Notification Settings API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Subscription Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Account Bandwidth Calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Audit Trail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Audit Trail Event Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Audit Trail API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
View Account Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Usage Report API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Attack Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
SIEM Log Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859

Contents
Configure the SIEM Log Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

DDoS Protection - SIEM Log Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
User Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Account Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Manage Account Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Password Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
User Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
My Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
API Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Manage Roles and Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Role Management API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Identity Management API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Single Sign-On (SSO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Web Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Website Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
Websites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Website General Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Website Domain Management API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Website Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
General Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Login Protect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Security Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
WAF Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
DDoS Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Notification Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Error Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Website Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Dashboards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
Security Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Performance Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Real-Time Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Network Traffic Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Security Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
SSL/TLS Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
View SSL Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
Upload a Custom Certificate for Your Website on Imperva. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
ECC Certificate Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Upload a Certificate without a Private Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013

Contents
Upload a Custom Certificate with HSM Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014

Revalidate Your Imperva Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Adding Emails for Ownership Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
CAA Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Supported Cipher Suites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Client Certificate Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Configure Client Certificate Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
Upload a CRL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Certificate Manager API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
Certificate Manager API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Create and Manage Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Policy Management API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
FAQ: WAF Settings Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Bot Mitigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Client Classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Create Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Create Rate Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Create Simplified Redirect Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Create Custom Error Response Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Override WAF Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Syntax Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
Rule Filter Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Manage Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
View Rule Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Delivery Rule Use Case Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166
Security Rule Use Case Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Cloud WAF Log Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
Log Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
Installing a SIEM Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196
Log File Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
Example Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Cloud WAF Error Pages and Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Troubleshoot Website Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Custom Error Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Application Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268
Global CDN and Optimizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
Caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271

Contents
Cache Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1272

Cache Settings API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285
Caching Duration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Cache Shield. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291
XRAY Debug Headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294
Content and Network Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Delivery Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Delivery Settings API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308
Dynamic Content Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Load Balancing and Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Load Balancing Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316
Load Balancing Settings API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Weighted Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327
Load Balancing Monitoring Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Load Balancing Monitoring Settings API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Load Balancing Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Port Forwarding Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1350
Waiting Rooms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Waiting Room API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371
DDoS Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1372
DDoS Protection for Websites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373
DDoS Protection for Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375
On-Demand Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379
Flow Monitoring Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381
Onboarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383
Recommended Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Security Policy and Mitigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388
Direct Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
Equinix Cloud Exchange (ECX) Direct Connect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
BGP Community Support Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Add a GRE tunnel connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Configure Performance Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Flow Monitoring Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1405
Flow Exporter API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409
Connectivity Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410
Connectivity Settings API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414
Connections API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
Maintenance Readiness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416

Contents
Control Network Range Diversions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418

Network Range Diversion API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
DDoS Protection for Individual IPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
Onboarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
Onboarding IP Protection over TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
Onboarding IP Protection over GRE or IP-in-IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
Set up a GRE tunnel on a Cisco router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433
Set up a GRE tunnel on a Juniper router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
Set up a GRE tunnel on an Ubuntu AWS client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Protected IP API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
Protected IP API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
DDoS Protection - Visibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Security Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
Performance Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
Performance Monitoring API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
DDoS Protection - Sub Account Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
Asset Migration API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483
Asset Management API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
DNS Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
DNS Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
Onboard DNS Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
Add/Edit a Primary Managed DNS Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489
Add/Edit a Protected DNS Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
DNS Protection Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
DNS Protection API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1501
API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502
Cloud Application Security API Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503
Cloud Application Security v1/v3 API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507
Account Management API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508
Site Management API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
DDoS Protection for Networks API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
Traffic Statistics and Details API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
Login Protect API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
Integration API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
Infrastructure Protection Test Alerts API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659

Contents
APIv2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
API Version 2/3 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
Cloud WAF v2 API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
More. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
Imperva Data Centers (PoPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
Data Storage Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
Dedicated Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
CNAME Reuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
HTTP/2 FAQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
IPv6 Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
Basic DNS terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
Attack Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
Imperva FlexProtect Pro for Application Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692


Cloud Application Security Overview

The Imperva cloud-based application delivery service protects and accelerates any website or network to provide
maximum security, performance, and availability. The features and services available to you depend on your plan.
Website Security
The Imperva PCI-certified Web Application Firewall , advanced bot detection, and access control technologies
secure any website against known and emerging threats. This includes common web 2.0 threats, such as spammers,
scrapers, and vulnerability scanners, in addition to sophisticated SQL Injection, Cross Site Scripting, and other
application-level attacks. For more details, see Web Protection – Introduction.
DDoS Protection
Combining a robust network backbone and advanced traffic inspection solutions, Imperva protects your organization
against all types of DDoS attacks . Available as an Always-On or On-Demand service, Imperva mitigates network
and application layer DDoS attacks against web servers, DNS servers, and critical infrastructure services, such as UDP/
TCP, SMTP, FTP and so on. Automatic detection and transparent mitigation minimizes false positives, ensuring a
normal user experience even under attack. The service features a dedicated 24/7 operations center and enterprise-
grade uptime SLA. For more details, see Web Protection, Name Server Protection, and Infrastructure Protection.
Content Delivery Network
The Imperva application-aware Content Delivery Network (CDN) delivers full site acceleration and boosts website
performance by using advanced networking, dynamic caching, and content optimization techniques. Websites using
Imperva are, on average, 50% faster and consume 60% less bandwidth. For more details, see Global CDN and
Optimizer – Introduction.
Load Balancer
The Imperva cloud-based Layer 7 Load Balancing service optimizes load distribution based on the actual flow of
traffic to each server. Based on a global content delivery network, this service supports local and global server load
balancing (GSLB), geo-balancing, and data center failover scenarios. Realtime health monitoring and notifications
enable data-driven responses to changes in traffic flow. For more details, see Load Balancing and Failover -
Introduction.
Last updated: 2022-04-26

Cloud Security Console

Log in to your my.imperva.com account to access the Imperva Cloud Security Console.
In this topic:
• Overview
• My Imperva Services
• Account and User Management
• Help
• FAQ
Overview
The homepage dashboard provides an at-a-glance view of all of your protected assets. It opens by default when you
log in to your account. Alternatively, click Home on the top menu bar. For details, see Homepage Dashboard.
The top banner enables you to:
• Select and switch between accounts and sub accounts
• Select a service area: Application, Edge, Data
• Access settings and information for your overall account
• Open the help menu for links to support, documentation, and more

The sidebar displays a drill-down view based on your selections in the top banner, such as Application services.
My Imperva Services
The services displayed in the Cloud Security Console vary based on your subscription.
Application Edge Data
Cloud Application Security

services and analytics, including:
DDoS Protection services
• WAF (Dashboards, Policies)
• DDoS Protection for
• DDoS Protection
Networks Cloud Data Security services
• Advanced Bot Protection
• DDoS Protection for
• Account Takeover Protection
Individual IPs
• Client-Side Protection
• DDoS Protection for DNS
• Attack Analytics
• Reputation Intelligence
Account and User Management

On the banner, select Account > Account Management to access the following:
Account Management User Management SIEM Logs
• Account Settings
• Sub Accounts
• My Profile
• Client CA Certificates
• Users
• Login Protect • Setup
• Roles
• Subscription
• Single Sign-On (SSO)
• Audit Trail
• Usage Report
Help
Click the Help button on the banner to find links to the product documentation, the latest release notes, Imperva
Support, and more.
FAQ
Where are my websites?
When you enter the Application service area, the Website list is displayed by default.
Where can I configure security policies for my account?
Account or sub account level: Application > WAF > WAF Policies
Website level:
1. Select your website from the Website List.

2. On the sidebar, click Security > Policies.
How do I update my password?
You can update your personal details, including name, email address, and password on the User preferences page.
On the banner, click Account > My Profile.
Why was I logged out of my account?
The Cloud Security Console has an idle timeout of 15 minutes. If your connection is idle for more than 15 minutes, you
will be automatically logged out.

Homepage Dashboard
The Home page provides an at-a-glance view of all of your protected assets. Quickly understand the overall account
status and identify what requires your immediate attention or further investigation.
In this topic:
• Overview
• Account snapshot
• Security
• Performance
• Website configuration posture
• Website Traffic
• Reliability
• Sub accounts
Overview
The home page is displayed by default when you log in to your account. Alternatively, click Home on the top menu
bar.
When viewed from a parent account, the dashboard displays an aggregated view of the metrics for the parent account
and all of its sub accounts.
Note: Aggregated data for accounts and sub accounts was implemented on January 17, 2021. Therefore, when
viewing statistics for earlier dates, the view from the parent account displays metrics for the parent account only.
When viewed from a sub account, the dashboard displays metrics for the specific sub account only.
Select and switch between accounts and sub accounts using the drop-down on the top menu banner.
Data on the home page displays metrics for the selected time range and is available for any time range in the previous
90 days.
Tip: You can customize the dashboard layout. The Arrange button enables you to show/hide sections of the
dashboard, or click and drag to change the order that the sections are displayed on the page. The customized view is
saved per user, per account.

Account snapshot
This section provides a quick view of metrics on all of your protected assets, enables you to select a different time
range, or download an image of the displayed dashboard as a PDF.
Security
View a snapshot of security metrics across your account.
The View security events link opens the Security Events page, enabling you to drill down further.

Click the ellipsis next to each metric to view more details.
The links below each metric open the associated website level dashboards, enabling you to drill down into specific
websites.
Section Description
Total number of WAF violations, calculated by

sessions and events.
The session count includes only sessions with

malicious activity.
An event is a single occurrence of a triggered WAF or

WAF violations security rule.
For example, a request that triggered the Illegal

Resource Access rule, or originated from a country
on the denylist of one of your account's websites.
View dashboard: Opens the Website Security

Dashboard.

Section Description
Total number of bot mitigation rules that were

triggered.
Displays the breakdown of attacks mitigated by

Advanced Bot Protection (ABP), Account Takeover
Protection (ATO) or the Cloud WAF's client
classification mechanism.
The ABP, ATO, and Client Classification links open

the corresponding dashboards.
Mitigated bot attacks
Click the ellipsis to view these additional

details for each service:
• CAPTCHA: The number of times a CAPTCHA

challenge was presented.
• Identify: The number of times a JavaScript
challenge was presented.
• Blocked: The number of times a block action
was triggered.
Total number of network level (Layer 3/4) DDoS

attacks.
DDoS attacks disrupt normal traffic by

overwhelming the target of the attack with a flood of
traffic from multiple sources.
Website DDoS: Opens the Network Traffic

Dashboard (Layer 3/4 protection for websites.)
Network DDoS: Opens the Network Protection

Volumetric DDoS attacks
Dashboard (Layer 3/4 protection for networks.)
Click the ellipsis to view these additional

details:
• Asset: The specific asset targeted in the attack

- such as an IP address or website
• Asset type: The category of the asset. Possible

values include: Application, IP, IP Range, DNS
Zone

Section Description
• Peak traffic: The highest value detected during
the selected time period.
• Status: Indicates whether the attack is still

taking place or if it has ended.
The total number of aggregated Attack Analytics

incidents.
Indicates that the Aggregate incidents from the

parent account and all of its sub accounts setting
in Attack Analytics is enabled. With this setting,
Attack Analytics incidents aggregated incidents are created in the parent
account that include attacks on sites in the parent
account and all sub accounts. For more details, see
Attack Analytics Settings.
View dashboard: Opens the Attack Analytics

Dashboard.
The total number of incidents in the parent account

plus all incidents in all of its sub accounts.
Indicates that the Aggregate incidents from the

parent account and all of its sub accounts setting
in Attack Analytics is disabled. With this setting, only
Aggregated Attack Analytics incidents
incidents for sites in the parent account are
displayed in the parent account. For more details,
see Attack Analytics Settings.
View dashboard: Opens the Attack Analytics

Dashboard.
Hover over the graph for more details.
Select or clear items from the legend to filter the

displayed data.
Security events graph
The WAF violations displayed at the top of the page
are displayed in the graph as follows:
• WAF events: Include Cross Site Scripting,

SQL Injection, Illegal Resource Access,
Application Level DDoS, Backdoor Protect,

Section Description
Remote File Inclusion, and custom rules
violation.
• ACL events: Indicates the number of requests

blocked due to ACL policy violations. This
includes requests blocked by country, IP
address, or URL according to your ACL policy
settings. For more details on ACL policies, see
Create and Manage Policies.
The 5 websites in the account with the highest

number of security events.
Filter the websites according to total, blocked, or

Top attacked websites
alerted events.
The Expand button opens a popup that displays up

to the 10 top websites.
Performance
View a snapshot of performance and caching metrics across your account.
The View dashboard link opens the Website Performance Dashboard, enabling you to drill down further into specific
websites.
Hover over a graph to display more details.

Section Description
Total number of requests sent to sites in your
Total requests
account.
The number of requests that generated errors.
The Requests with errors graph displays more

details. Hover over the graph to see the distribution
of errors by type.
Possible values:
Client: Client errors include failed requests that do

not comply with the HTTP RFC, client TCP timeouts,
and clients closing connections.
Requests with errors Server: Server and application errors include failed
requests due to responses that do not comply with
the HTTP RFC, server TCP timeouts, server SSL
errors, and servers closing connections.
Net: Network errors include failed requests due to

origin server TCP timeouts.
Other: Other errors typically indicate issues with the

website configuration and can include requests to
unsupported ports, requests using unsupported
protocols, and requests to websites that have no
valid destination IP addresses.
Total number of requests that received responses

Cached requests from the Imperva cache instead of from your origin
server.
The amount of bandwidth saved because requests
Cached bandwidth were served from the Imperva cache instead of from
your origin server.
The total bandwidth used for responses served from
Total bandwidth
the Imperva cache and from your origin server.
Displays the average of response time for each

region, according to the Imperva data centers that
handled the requests.
Average response time by region
Response time is calculated from the time the
Imperva proxy has decided to send a request to the
origin (before opening a connection to the origin),
until the origin finishes sending the response to the
proxy.

Section Description
Each data point in the graph represents the average
of the last 10 minutes.
Click a region name in the legend below the graph to

view response times for each Imperva data center.
The 5 websites in the account with the highest

number of requests.
You can filter the table to display data for total

Top websites
requests or requests with errors.
The Expand button opens a popup that displays up

to the 10 top websites.
Website configuration posture

View the configuration status of your websites.
For websites requiring attention in order to be fully configured and secured, click the ellipsis next to each section
to view more details.
Name Description
DNS records for the websites listed are not pointing

to Imperva. Traffic for these websites is not being
routed through Imperva's Cloud WAF.
DNS configuration
Make sure to update your DNS records so that they
point to the DNS records provided by Imperva. For
more details, see Step 4: Configure your DNS in
Onboarding a Site – Web Protection and CDN.
DDoS settings for the websites listed do not match

our recommended DDoS Activation Mode settings.
DDoS settings Imperva recommends setting DDoS Activation Mode

to Auto. In the popup window, click the website
name to open the DDoS settings. For more details,
see Web Protection - DDoS Settings.
WAF settings WAF settings for the websites listed do not match
our recommendations.

Name Description
• At least one of the WAF settings for the website
is not set to Block
and/or
• Backdoor Protection is not set to Auto-

quarantine
Imperva recommends setting all actions for

detected WAF threats to Block, and setting
Backdoor Protection to Auto-quarantine.
In the popup window, click the website name to

open the WAF settings. For more details, see Web
Protection - WAF Settings.
SSL/TLS certificates for the websites listed have

expired or have other configuration issues.
If your website supports SSL, Imperva recommends

that you have at least one certificate configured in
Imperva.
Make sure to update your certificates on time and to

complete the certificate uploading process.
For more details, see SSL Support in Web Protection

- General Settings.

SSL certificates
You can click the ellipsis to view additional

status details.
Custom certificates:
• Active: A certificate has been uploaded to

Imperva. Any problems or errors are listed in
the Custom Certificate Issues column.
• Inactive: No certificate has been uploaded to

Imperva.
Imperva certificates:

Name Description
• Active: The Imperva-generated certificate is
valid.
• Inactive: No certificate was generated.
• Pending: The certificate is being processed.

Additional status details are provided in the
tooltip.
Website Traffic
View traffic and performance metrics for your websites.
Name Description
(Sessions.) The number of times the website was
Total visits
accessed.
All bandwidth used for responses served from the
Total bandwidth
Imperva cache and from your origin server.
The average number of bits per second of incoming
Average bits/second and outgoing traffic passing between clients and
Imperva, for the selected time range.
The total number of API calls and the trend over

time.
API calls indicate the number of requests made via

an API.
API calls
Note: The number of total visits is based on
sessions. Therefore, it is possible that the number of
API calls displayed will be higher than the number of
total visits.
The websites in the account with the highest total

Top websites
visits, total bandwidth, bits per second, or API calls.
The map shows traffic distribution by country.

Traffic by Geo Location
You can also view the distribution of API calls.
Reliability
Get an overall picture of website availability based on the status of your origin servers and connections.
Click the ellipsis next to each section to view more details.

Name Description
Overall status of your websites, based on your origin

server availability.
• Operational: All origin servers are available.
• Degraded: One or more of the origin servers

defined for this website are down.
Website status
• Outages: All origin servers defined for this
website are down.
In the popup window, click the website name to

open the Website Performance Dashboard. For
more details, see Website Performance Dashboard.
Status of your Origin Public IP.
In the popup window, click the IP address to open

the IP Protection Settings. For more details, see
IP connections up
Settings: DDoS Protection for Individual IPs.
Available for customers subscribed to

DDoS Protection for Individual IPs only.
Status of the network connection between Imperva

and your origin network.
Indicates the number of connections that are in Up

status out of total connections.
Network connections up In the popup window, click the connection name to

open the Connectivity Settings. For more details,
see Connectivity Settings: DDoS Protection for
Networks.
Available for customers subscribed to

DDoS Protection for Networks only.
Sub accounts
The data reflects Application Security statistics only.
Column Description
Name The name and account ID of the subaccount.

Column Description
The number of visits (sessions) to websites in the
Total Visits
subaccount.
The total number of WAF events.

WAF Events
An event is a single occurrence of a triggered WAF or
security rule.
The total number of bot mitigation rules that were

Mitigated Bots
triggered.
The total bandwidth used for responses served from
Total Bandwidth
the Imperva cache and from your origin server.
Bandwidth usage for the selected time period. Not

Usage (95th percentile)
used for billing purposes.

Imperva Cloud Security Trial

Start the App Protect Professional self-service trial to experience Imperva's cloud services for yourself.
Note: If you are an existing customer interested in a trial for a service you do not currently subscribe to, please contact
an Imperva Sales Representative.
In this topic:
• Before you begin

• How to start the free trial
• What's included with the trial?
• How long will the trial last?
• What happens when the trial ends?
Before you begin
To take advantage of everything Imperva has to offer and best evaluate our services during your trial period, make
sure to prepare your assets and get the relevant stakeholders on board ahead of time.
As one example, to get the most out of our application delivery mechanisms, we recommend you identify a domain or
application with static resources. This will enable you to see the full performance benefit our services can offer. You
will also want to be in touch with your application delivery team so they can help you fine tune your setup and best
evaluate the improvements Imperva brings to their application.
How to start the free trial
To start your trial, visit https://www.imperva.com/free-trial/.
After filling out the form, you will receive a confirmation email. Click the link to verify your email address and choose
an account password. This logs you in to the Imperva Cloud Security Console and you can get started by onboarding
your first website.
What's included with the trial?
The trial includes a wide variety of Imperva features and services. After you begin, you can opt in to additional service
trials directly from the Cloud Security Console.
• Included with trial

• Optional trial add-ons
• Additional trials available separately
Included with trial
These features and services are automatically activated in the trial.

Feature/Service Description
Onboard your websites to get started routing

Cloud WAF website traffic through the Imperva network and
filtering out malicious activity.
Implement two-factor authentication for websites

and specific URLs without making any changes to
your applications or installing any software.
Login Protect
The trial includes the option to define 5 Login
Protect users. To request additional users, contact
your Imperva sales representative.
Secure and accelerate your websites and

CDN
applications.
Website DDoS Protection Protect your websites from DDoS attack.
Protect your websites from malicious bot activity
Bot Protection using Imperva’s built-in advanced client
classification technology.
Implement your own security, delivery, and access
Custom Rules control rules on top of Imperva's existing security
and application delivery logic.
Protect your APIs with an automated positive
API Security security model, detecting vulnerabilities in your
applications, and shielding them from exploitation.
Retrieve your Imperva access and event logs from
SIEM log integration the Imperva cloud repository and archive or push
these events into your SIEM solution.
Protects you from attack, while providing DNS
DNS Protection
acceleration and load reduction benefits.
Speed up the security investigation of WAF alerts.
Attack Analytics detects application attacks by
Attack Analytics applying machine learning and domain expertise
across the application security stack to reveal
patterns in the noise.
Gain visibility into the reputation of the IPs attacking
your sites to make more informed, data-driven
Reputation Intelligence decisions. Leverage reputation data from across the
Imperva customer base and 3rd party providers to
help in incident response.
Detects and mitigates account takeover attempts,

Account Takeover Protection - detection
protecting your web applications against volumetric
and low and slow ATO attacks.

Detection is included. A trial with mitigation is
available as an optional add-on.
Guards your customers’ data from theft through

client-side attacks like digital skimming, supply
chain attacks, and Magecart.
Client-Side Protection - detection
Detection is included. A trial with mitigation is
available as an optional add-on.
Optional trial add-ons
You can start an optional free trial for any of these features and services.
Feature/Service How to enable the trial
Distribute user requests among origin data centers

and/or servers in order to achieve optimal
performance and response time. Help ensure high
availability in the case of a malfunctioning server or
data center by routing traffic to a healthy server.
Load Balancing
On the Origin Servers page, click Start your free
trial.
Where it's located: Application > Websites > <select

your website> > Website Settings > Origin Servers
Protect individual IPs from network layer 3 and 4

DDoS attack.
DDoS Protection for Individual IPs On the IP Protection page, click Start your free
trial.
Where it's located: Edge > IP Protection
Turn on the mitigation trial.

Account Takeover Protection: Mitigation
On the Account Takeover Protection dashboard,
click Configure mitigation on the menu bar to start
the mitigation trial.

Feature/Service How to enable the trial

Where it's located: Application > Advanced Bot
Protection > Account Takeover
Turn on the mitigation trial.
On the Client-Side Protection dashboard, click Block

on the menu bar to start a trial to activate blocking
Client-Side Protection: Mitigation
mode.
Where it's located: Application > Client-Side

Protection
Additional trials available separately
Contact an Imperva sales representative for more information.
On the relevant feature page, click Contact Imperva Sales to Get Started to send an email directly to the Imperva
Sales team. A representative will contact you.
Protect entire networks and subnets from network

(Layer 3 and 4) DDoS attacks.
DDoS Protection for Networks
Where it's located: Edge > Network Protection
Protect your websites, mobile applications, and APIs

from automated attacks without affecting the flow
of business-critical traffic.
Advanced Bot Protection
Where it's located: Application > Advanced Bot
Protection
Protection and compliance for data stores in any

cloud environment.
Cloud Data Security
Where it's located: On the Cloud Security Console
top menu, click Data.
How long will the trial last?

The trial continues for 30 days. If you start an additional add-on trial, it will end on the same date as the base trial.
The top menu bar displays the number of remaining days in your trial.

The account Subscription page provides more information on your trial plan and status, and displays the actual date
on which the trial will end.
To open the Subscription page, navigate to Account > Account Management > Subscription.
What happens when the trial ends?
If you have not already subscribed to Imperva, you can expect the following when the trial ends:
• Your account is locked and you can no longer log in.
• Your websites are reconfigured to bypass Imperva and are no longer protected by the Imperva Cloud WAF.
Important: At this point, Imperva is no longer forwarding traffic to your websites. If you have not changed your
DNS settings to point back to your origin servers, your websites will stop receiving traffic. It is important to
reconfigure your DNS settings before the trial ends to make sure that your websites are always available to
visitors.
• If you choose to subscribe to Imperva services at a later date, your configured sites and settings may still be
available for a short period of time.
To purchase Imperva services or for more information, contact us here: https://www.imperva.com/contact-us/


Onboarding a Site – Web Protection and CDN

Imperva Web Protection and CDN services provide security and acceleration services at the web application
level.
Overview
The first step in protecting and accelerating a web application is to add a “site” to an Imperva account. An Imperva
site may represent a single application or a group of applications that are managed together sharing the same
dashboards and configuration settings.
Each Imperva site carries a unique CNAME record that is used both for pointing traffic to the Imperva network and also
for identifying the Imperva site in cases where multiple applications share the same Imperva site.
Note: Imperva supports the use of the standard HTTP/S ports:
• 80 (HTTP)
• 443 (HTTPS)
In addition, Imperva supports a number of non-standard ports. For the list of these additional ports, see Non-standard
Open Ports.
To use other non-standard ports that are not listed, contact support before onboarding to request a change. Note that
the change can take some time to implement.
To onboard Imperva web protection:
• Step 1: Add your website to Imperva

• Step 2: Configure SSL support for secure sites
• Step 3: Get an Imperva DNS A Record / CNAME Record
• Step 4: Configure your DNS
• Step 5: Allow access to Imperva IPs
• Step 6: Your site is onboard!
Step 1: Add your website to Imperva
1. Log into your my.imperva.com account. The Add Your Website screen appears.
Note: If you have already added a site to your Imperva account and want to add an additional site, go to the
Cloud Security Console Websites page and click Add website.

2. In the Add a website field, enter the full domain name (including the subdomain prefix, such as www) of your
site. For example, www.mydomain.com.
Alternatively, click Advanced configuration to manually set your web server IP/CNAME and skip the automated
DNS check for the origin IP. This enables you to prepare the site but configure DNS at a later time. The options
include:
A free-text field that enables you to add a

Reference ID unique identifier to correlate the site with an
object in your system.
Web server IP/CNAME The IP or CNAME of your web server.
Configures SSL support for your secure site. For
Use SSL more details, see Step 2: Configure SSL support
for secure sites below.
Receive emails about the “add website” process,
Send setup emails
such as DNS and SSL setup instructions.
3. Click Add website. The following is displayed, showing information automatically collected by Imperva about
your site:

If your site has SSL support, then HTTP + HTTPS is displayed in this window. Click the Continue button to
configure SSL support for your site in Imperva, as described in Step 2: Configure SSL support for secure sites.
If your site is not SSL protected, then skip to Step 3: Get an Imperva DNS A Record / CNAME Record.
Step 2: Configure SSL support for secure sites
Imperva acts as an HTTPS proxy and terminates connections in front of the end users. For this reason, a second SSL
certificate (or actually multiple copies of the same certificate) needs to be installed on the Imperva proxy servers, in
addition to the one already installed on the origin servers. This certificate is the one that is visible to the end users.
When onboarding a site on Imperva proxy servers, you can have Imperva generate a certificate for it, use your own
certificate, or skip certificate creation and complete the process in the future.
To begin onboarding your site, choose from one of the following options:
• Option A: Configure SSL for an active site - This default option instructs Imperva to generate a new certificate for
the site. The Certificate Authorities that certify these certificates for Imperva are required to validate the
customer’s ownership of the domain, a process that requires two consecutive changes in the DNS.
• Option B: Configure SSL for a new site - This 1-step option quickly generates an Imperva certificate for your site
and requires only a single change in the DNS. Imperva validates your ownership of the domain, but blocks
access to the site for approximately 5 minutes until the process is completed.
• Option C: No Imperva certificate - This option lets you onboard a new site without any certificate, then configure
a custom or Imperva certificate for it in the future.
Note: At any stage during the registration procedure, you can click the Configure Later button to return to the
Websites page without generating an SSL certificate for the site. The Websites page displays the new site with a status
indicating that configuration is not complete. At a later stage, you can configure a certificate for it directly from the site

settings. In such a case, new DNS instructions will be provided and you will need to configure its DNS records
accordingly.
Option A: Configure SSL for an active site
During configuration and preparation of your Imperva certificate, your site will remain accessible. Once the new
Imperva SSL certificate is ready, you can point the traffic to Imperva.
1. From the Configure SSL for an active site option, select a SANs configuration for your site.
Adds the full domain SAN to the Imperva

Add full domain
SSL certificate.
Add wildcard domain SAN: *.com Adds the wildcard SAN to the Imperva SSL
certificate instead of the full domain SAN.

Example: For www.example.com, the wildcard

SAN is *.example.com and the full domain SAN is
www.example.com.
Using a wildcard SAN enables you to add

subdomains, such as sub.example.com, without
the need for a certificate change and revalidation.
Note: Typically, when your site's Imperva-

generated certificate needs to be renewed, the
process is completed automatically by Imperva. If
you are using a wildcard SAN, automated
validation can only be completed for a
subdomain if the domain (e.g. example.com) is
also protected by Imperva. Otherwise, you will
receive an email notification from Imperva
requiring you to revalidate ownership of your
domain.
For sites with the www prefix, adds the naked

domain SAN to the Imperva SSL certificate.
Add naked domain SAN: <site name>.com
Example: For www.example.com, the SAN
example.com is added to the certificate in
addition to the wildcard or full domain SAN.
2. Click Continue to validate domain ownership.
3. The Certificate Authority is required to validate ownership of the domain. Select one of the following methods
described below:
▪ Validate by adding DNS records (TXT or CNAME)
▪ Validate by e-mail
Validate your website ownership by adding a DNS record
1. Click Validate by adding DNS records (selected by default).
2. Click the Record type dropdown and select one of the following:
▪ CNAME: This option ensures automatic revalidation of the site in the future by Imperva.
▪ TXT: This secondary option is for organizations that do not allow the use of a CNAME for site
validation or do not want Imperva to automatically manage this site's revalidation in the future.

3. Log into your DNS management console and open your DNS Zone file. If you are using a DNS management
service, log into it to make the change.
Note: Field names may vary between different DNS providers.
4. Set the Record type to match what you selected from the dropdown.
5. Copy the Host string into the DNS Record name field:
CNAME example: _delegate_validation.<domain>
This defines your domain's delegation to Imperva.
TXT example:
6. Copy the Value string into the DNS Value field:

CNAME example:
TXT example:
7. On the Activate SSL Support page, click I added the records button (it will match your Record type
selection). Imperva verifies that the value of the new record(s) has been added to your DNS zone file. This
may take a few minutes.
Validating your website ownership by email
1. Click Validate by e-mail.
2. Select an email address from the drop-down menu where you want to receive the validation link. The
drop-down menu is populated with default emails for the domain (e.g. admin@, administrator@, etc.). To
add emails to this list, see Adding Emails for Ownership Validation.

You can test whether these email addresses are correct by clicking the Send a test email to all the
addresses link which sends test emails to all the listed addresses. This enables you to check whether you
receive these emails, thus indicating that the addresses are correct. The test emails sent in this manner do
not contain a validation link.
3. When you have selected an email address from the drop-down menu, click the Send button. Imperva
sends the validation email to the selected address.
4. Open the email you received and click on the validation link.
5. On the Activate SSL Support page, click the I clicked the link button to indicate that you have clicked
the link in the validation email.
Issuing a new SSL certificate for your website
After website ownership has been validated, Imperva starts the process of issuing a new SSL certificate for the site,
which is typically completed after a few minutes. After a message pops up indicating that the certificate was issued
successfully (you do not have to remain in this window), continue to Step 3: Get an Imperva DNS A Record / CNAME
Record.
Note:
While waiting for the certificate to be issued, your site remains available as it was previously. Traffic is not yet being
diverted through Imperva. After the certificate is ready, Imperva sends DNS instructions for onboarding.

If, for any reason, the issuing of this new SSL certificate is not completed promptly, a message is displayed and you
will receive an email notification when the certificate is issued.
Option B: Configure SSL for a new site
Onboard a new HTTPS site that does not have traffic, or one that can go offline temporarily, and configure an Imperva
SSL certificate in one step. Since Imperva validates the domain by HTML after you update the DNS, this option
eliminates the need to validate domain ownership via email or by adding a TXT record to the DNS . During this
process, your site will not be accessible for approximately 5 minutes until Imperva generates the new SSL certificate
for the site.
From the Configure SSL for a new site option, the SANs configuration is automatically set to Add full domain.
Note: Adding a wildcard domain SAN to the certificate is not supported for this option.
1. For sites with the www prefix, you can check the Add naked domain SAN option to include it in the Imperva
SSL certificate.

2. Click Continue for instructions on how to update your DNS records, as explained in Step 3: Get an Imperva DNS
A Record / CNAME Record.
Option C: No Imperva certificate
When you onboard a new HTTPS site with the No Imperva certificate option, it will not receive any SSL traffic until
you upload a custom certificate, which will then be presented only to SNI-supporting clients. For details, see Upload a
Custom Certificate for Your Website on Imperva.
Note: If your site also needs to serve non SNI-supporting clients, it requires an Imperva certificate. Select one of the
following to install an Imperva certificate:
• Option A: Configure SSL for an active site
• Option B: Configure SSL for a new site
Click Continue for instructions on how to update your DNS records, as explained in Step 3: Get an Imperva DNS A
Record / CNAME Record.

Note:
• The certificate's public key must be less than 4096 bits.
• The certificate must include the SAN for the website’s domain.
Step 3: Get an Imperva DNS A Record / CNAME Record
After you click the Continue button, the Change your DNS records screen appears with instructions on how to setup
a DNS A record(s) / CNAME record. The content of this screen varies according to your network and the type of site you
are onboarding:
• If you entered a full domain name, then two IP addresses are provided to which to configure your site’s DNS A
Records for each IP. In addition, the domain name to which to configure your site’s CNAME Record is also
provided.
• If you entered a subdomain name, then a CNAME Record is provided to which to configure your site.
The following step details how to complete the configuration.

Step 4: Configure your DNS
To configure the A Record(s) and CNAME Record of your DNS:
1. Log into your DNS management console.
2. Create or update your site's records, as instructed on the Change your DNS records screen.
1. Update the A Record for your naked domain (for example, mydomain.com) so that it points to the IPs
provided by Imperva for the A Record. Imperva provides you with two different A records for the sake of
redundancy, and you will need to configure both of them for the naked domain. These IPs point to the
Imperva PoPs closest to the location where your application is hosted.
Note: The A records of your non-HTTP/S DNS records (such as ftp.mydomain.com or mail.mydomain.com)
must remain pointing to your origin web server and not to Imperva, which means that you should simply
leave them "as is" in the DNS Zone file.
Imperva provides full support for sites using IPv6. If your DNS records contain an AAAA record, Imperva
will also provide two AAAA records to replace the existing AAAA record.
2. Create or update the CNAME Record of the full domain of your site so that it points to the domain
provided by Imperva. Remember, the full domain includes the subdomain prefix, such as
www.mydomain.com or subdomain.mydomain.com. If an end user types in the subdomain, then Imperva
uses the CNAME Record and provides service from the PoP that is closest to you.
3. On the Change your DNS records screen, click the Validate button to verify that the records were updated
correctly.
4. If you selected the Configure SSL for a new site option, then the Status Check section also appears on the
screen. After your DNS records are successfully validated, click the second Validate button to verify that

SSL configuration was completed successfully.
5. Click Done to view the new site's settings or View all websites to view the current configuration status for your
new site on the Websites page.
For more details on the Websites page, see Web Protection - Websites

Step 5: Allow access to Imperva IPs

Make sure that Imperva IPs are added to the allowlist of your web server firewall and in the firewall deployed in front
of your web server. It is also recommended to restrict access to non-Imperva IPs. For details, see Imperva IP addresses
.
Step 6: Your site is onboard!
Once DNS changes are complete, traffic gradually gets routed through the Imperva network, as the new DNS records
propagate through the Internet. The entire process is TTL-dependent and usually takes a few hours to complete.
Nevertheless, no packet drops should occur at any stage.
Note:
• We strongly recommend that you change the IP address of your origin server. This will render any archived IP
records obsolete, and new searches will display only the Imperva IP address.
• You can disable Imperva web protection at any time. When web protection is disabled, traffic gets routed
directly to the origin and not through the Imperva network.
How To
• Upload a Custom Certificate for Your Website on Imperva

• Web Protection - Website Settings
• Onboarding and Keeping Your Own CDN
• CNAME Reuse
Read More
• Onboarding FAQ
• Web Protection – Introduction
• Web Protection - Websites

Onboarding and Keeping Your Own CDN

You can choose to onboard Imperva’s protection and load balancing services while continuing to use your
current CDN.
The following deployment options are available:

In Front of your CDN
This is achieved by pointing the website domains to Imperva and configuring the other CDN addresses as the origin
servers on Imperva.
Parallel to Your CDN
The traffic is separated by assigning different sub-domains of the different traffic types. This is usually done by adding
a static.domain.com sub-domain for all static resources and pointing that sub-domain to the other CDN, while
pointing all other domains to Imperva.
In Back of Your CDN
This is achieved by pointing the site domains to the other CDN and configuring the Imperva CNAME as the origin
servers in the other CDN.

Note: This configuration requires XFF header support on your existing CDN. For example, X-Forwarded-For, True-
Client-IP, or another header used by your CDN for identifying the originating IP address of the connecting client.

Onboarding FAQ
Answers to some common questions about getting started with Imperva Cloud Application Security.
What happens after I add my domain to Imperva?
Once you have completed the DNS instructions that were provided as part of the “Add Site” wizard, visitors to your
website will be gradually routed through the Imperva network. This process can take anywhere from 5 minutes to 24
hours according to your DNS entries' TTL (Time to Live).
Visitors routed through Imperva will receive an enhanced user experience as pages will load faster when served by our
CDN.
Will Imperva add latency to my web site?
Imperva does not add any latency to your site. In fact, Imperva makes your site load faster and consumes less
computing and bandwidth resources.
How long does it take to add a domain on Imperva?
Adding your domain to Imperva can take as little as 5 minutes. If your website supports SSL, the onboarding process
might take a bit longer, but typically not more than a few hours to complete the entire process.
Will I experience any downtime during or after joining Imperva?
Absolutely not! You will not lose a single visit.
Do I need to add each one of my domains to Imperva?
Yes. Each domain needs to be added to Imperva separately and has its own dashboard and configuration.
Does Imperva support websites hosted in cloud providers such as AWS or Azure?
Yes. In some cases the origin server address will be defined on Imperva as a CNAME rather than an IP.
Can I use Imperva if I am using Cloudflare’s DNS?
Yes. Here's how to add your domain to Imperva while managing your DNS on Cloudflare:
1. Log in to your Cloudflare account and navigate to the DNS management screens.
2. Disable the Cloudflare HTTP service for the domain. (Typically an orange Cloudflare logo indicates that you are
using Cloudflare’s HTTP services.)
3. Add your domain to Imperva.
4. Use the DNS instructions provided by the Imperva Add Site wizard to configure your DNS entries on Cloudflare.
I already have a CDN. Can I use Imperva just for the security service?
Yes. You can add Imperva in front of or behind another CDN. Read more about this setup here: Onboarding and
Keeping Your Own CDN.

What if my website has more than one IP address?
The Imperva service includes a Layer 7 load balancer capable of supporting multiple IPs and multiple data centers.
Why do I need two A records?
Each A record maps a domain name to a different IP address. Having more than one A record enables redundancy,
which ensures continuity of service if one of the servers goes down.
Will I need to change my hosting provider / registrar / name server in order to use Imperva?
No. The only thing you need to change is the setting of your domain DNS record, which needs to point to Imperva.
How does Imperva define a website and a domain?
Website: A destination on the Internet and the SSL certificate, if used, for that destination. A destination is either a
public IP address or a CNAME.
Domain: Enables multiple websites or applications to resolve to a single destination. As long as these websites have
the same destination and SSL certificate (where applicable), they can be combined and routed together through the
system using just one website license. If multiple websites resolve to the same IP address, or CNAME, but have
different SSL certificates, they must be configured on the system separately and require individual licenses in order to
avoid SSL mismatch errors.
Using a single website license and configuring multiple websites together in the Imperva system results in all sites
being combined together into a single unit. These sites are reported and managed (security and acceleration policies)
as a single unit. If you require granular reporting or separate site management for some or all sites, it is important to
configure those sites individually in the Imperva Cloud Security Console.
Does Imperva support WebSocket?
Yes. Imperva supports WebSocket communication by default.
WebSocket requests must be in accordance with RFC 6455 (http://tools.ietf.org/html/rfc6455 ) and in the following
standard format:
Client request:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
Server response:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
Is Google AMP supported?
Yes. Imperva supports AMP pages natively, which means no injections will be made into AMP pages.
In order for an HTML page to be identified as an AMP page it must start with “<html amp” or “<html ▪”. Pages starting
with “<html anyothertext ▪” will not be identified as AMP pages.
Where can I find Imperva's SLA?
You can download a copy of the SLA in pdf format from the Cloud Security Console's subscription page (Management
> Subscription).

WebSocket Support
This topic describes how Imperva handles WebSocket communication.
Imperva supports WebSocket communication by default. WebSocket requests must be in accordance with RFC 6455
(http://tools.ietf.org/html/rfc6455 ).
For compatibility with HTTP, the WebSocket handshake uses the HTTP Upgrade header to change the connection
from HTTP to WebSocket.
Imperva supports this functionality, using the HTTP Upgrade header mechanism, along with a few protocol-specific
headers, to switch the connection from HTTP to the WebSocket protocol.
After the protocol is successfully switched, Imperva passes WebSocket protocol traffic between the client and your
origin server as is, without inspection by the Cloud WAF.
Example
Client request:
GET /chat HTTP/1.1

Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Server response:
HTTP/1.1 101 Switching Protocols

Upgrade: websocket
Connection: Upgrade
Imperva default timeouts
• The idle connection timeout for HTTP is 6 minutes.

• The idle connection timeout for WebSocket/non-HTTP traffic is 30 minutes.
In order to prevent timeouts, you may want to align your application timeouts with the default Imperva timeouts.

Customer Setup Checklist

This document provides enterprise customers with a complete and easy-to-use checklist for handling Imperva Cloud
Application Security configuration and setup.
Overview
It is important that you go through this checklist both before and after your website traffic is routed through the
Imperva cloud.
This document is intended to:
• Provide a series of checks to make sure the customer’s environment is properly aligned with Imperva.
• Provide a series of checks that the customer should perform when setting up the Customer account using
Imperva’s management portal.
• Provide a series of checks that the customer should perform on each of the domain settings using Imperva
services. The domain checklists are divided into two parts:
• Domain settings checks to be performed on the Imperva management portal before activating the
service.
• Checks to be performed after activation of the Imperva service.
Terminology
Imperva Account – This is the entity through which a customer enables website traffic to be handled through the
Imperva solution. The Imperva account is where the customer can configure settings for his domain, review website
performance and monitor traffic statistics.
Domain - A unique name that identifies an internet resource such as a website.
Portal – This refers to the Imperva Cloud Security Console. The customer can login to the portal, change settings and
review statistics and analytics about traffic routed through Imperva.
Top 10 - Quick Setup Checklist
The following checklist can be used for quick setup purposes. It covers the ten most important checks from the full
setup procedure and in most cases is sufficient to get you started.
However, for best results, we recommend performing the full set of checks as detailed in the subsequent sections of
this document.
Item What to check? More details

Check that Imperva IPs
1. Web Server Firewall are whitelisted in your here
web server firewall
Make sure that Imperva
IPs are whitelisted in the
2. Hosting Firewall here
firewall deployed in front
of your web server
Ensure that server
3. IP rate limiting block here
modules that enforce IP

rate limiting are not set to

Imperva IPs
Make sure that the IPs/
CNAME listed in the
4. Origin Server “origin server” is the here
address to which Imperva
should forward the traffic.
If your site support Https

traffic, make sure to:
1. Complete the SSL setup
wizard at the portal.
5. HTTPS enabled? here
2. Ensure that the
certificate is in “Active
“ status. (Websites
> Settings > General
> SSL Support)
Make sure that you add

non-browser clients (such
Bots/Non Browser as monitoring service or
6. here
Applications application API, etc.) to
the “bot access control”
exception list
Make sure to adjust the
DDoS policy trigger based
7. DDOS settings on expected traffic rate here
and your web server’s
capacity.
After you switch the site
DNS records to Imperva,
run a DNS query for the
website and check that:
1. The DNS records of the
HTTP/s services are
pointing to Imperva
8. Confirm the DNS settings here
CNAME /IP’s only.
2. If other services are
hosted on the same
server such as Mail or FTP,
ensure that their A
records are not pointing
to the origin server.
After you switch the site
DNS records to Imperva ,
9. End-to-End Test here
open the Portal real time
dashboard. Generate

HTTP/S request to the

domain protected by
Imperva. Check that the
dashboard displays the
request information and
that the client receives
the content.
Full Website Setup Checklist
Customer Environment Checklist
Item What to check? Explanation

To ensure that traffic to
your website passes
through Imperva only,
you should block access
to it from non Imperva IP
Check that Imperva IPs
1. Web Server Firewall are whitelisted in your addresses . A set of
web server firewall rules should be applied to
your firewall (or to
your .htaccess files) that
will block all traffic
coming from non-
Imperva IP addresses
To ensure that traffic to
Make sure that Imperva your website passes
IPs are whitelisted in the through Imperva only,
2. Hosting Firewall
firewall deployed in front you should block access
of your web server. to it from non Imperva IP
addresses .
When your traffic is being
routed through Imperva,
it appears to the hosting
infrastructure as if all
website traffic is arriving
from a limited number of
IPs (whereas previously
Make sure that server the source IPs were very
modules that enforce IP diverse). If any kind of
3. IP rate limiting block
rate limiting are not set to rate limiting rules are
Imperva IPs being enforced, for
example, to mitigate
DDoS attacks, the
Imperva Proxy Server IPs
might be blacklisted,
leading to availability
issues for certain
locations.

If the Vary header is being

used for such caching,
Make sure the website
Imperva will cache
returns the correct
resource and pages if the
Website caching caching instructions,
4. Vary header is set with
consideration when serving content to
"Accept-Encoding". For
different clients and or
other Vary parameters,
languages
Imperva will not cache
the resource.
Imperva settings checklist
Site Level Checklist
The following checklist items should be verified/ performed for each new domain that is added to the account.

Imperva has an
automated process for
generating SSL
If yes, please complete certificates to support
Does your site support the SSL configuration your HTTPS traffic, as well
1.
SSL (HTTPS) traffic? setup, before routing as the ability to use your
traffic through Imperva. company’s custom SSL
certificate. For further
assistance, please contact
our Support team.
Portal area: Settings >
General > SSL Support
section. Check if the
certificate status is
Please check if the
“Active”. It may take up to
2. HTTPS enabled? Certificate status is
24 hours to create the
“Active “.
certificate using Imperva
CAs. For further
assistance, please contact
our Support team.
Origin Servers. You can
change the “Origin
Make sure that the IPs/
Server” configuration to
CNAME listed in the
reflect the real customer
3. Origin Server “origin server” is the
server topology. To
address to which Imperva
support variant origin
should forward the traffic.
server configurations, see
Load Balancing Use
Cases.
Bots/Non Browser Make sure that you add Portal area: Settings >
4.
Applications the non-browser clients Security > Bot Access

Control section.
If your application serves
non-browser clients (e.g.,
monitoring service,
application API, etc.),
please make sure these
clients are well defined in
(e.g., monitoring service,
your Imperva security
application API, etc.) to
policy.
the “bot access control”
It is possible to add
exception list.
exceptions based on:
URL, Visitor, IP, Country,
User Agent, or a specific
parameter. Exception
rules will override all
other “Bot Access
Control” rules.
You may edit your
security settings in the
case you need to restrict
5. Block Specific Resources Security > Block
access to your site from
Resources
specific countries, IPs or
certain URLs.
Security > Block
Resources. Traffic from
You may edit your these IPs will not be
security settings in the filtered by Imperva
case you need to allow security rules and will
6. Whitelist Specific Sources
access to your site with never be denied access to
no inspection from a your site. You can enter
specific IP. single IPs, IP ranges or
subnets (e.g. 192.168.1.1,
192.168.1.1-192.168.1.100
or 192.168.1.1/24).
WAF. By default, the WAF
rules are set to the Block
Make sure that the default Request option. The only
Web Application Firewall action for detecting WAF exception is the Cross Site
7.
(WAF) threats matches your Scripting rule, which is set
policy to Alert Only. You can
change the threat default
actions to one of the
block options or Ignore.
Make sure to adjust the Portal Area: Settings >
DDoS policy trigger based WAF > DDOS Click
8. DDOS settings
on the expected traffic Advanced settings (pop
rate and your web up page will display). If

the DDoS mode is set to

Automatic, Imperva will
enable the DDoS rules
only when the traffic to
server’s capacity.
the site exceeds a certain
The default value is 1000
threshold. The threshold
requests per second.
should match your web
server’s capacity or be
above your average daily
request rate.
To Improve your site’s
performance, we suggest
that you enable caching Portal area: Settings >
on Imperva’s CDN. By Performance. For more
default, the caching is information on each of
9. Caching settings the options, you can click
enabled for “static and
dynamic” content. Please on the next to the
review the Performance feature.
settings and adjust as
needed.
Portal Area: Settings >
Check which Imperva
Notifications. Imperva
notifications should be
10. Notification will notify you by email
generated on regular
with respect to WAF
basis.
events and PCI reports.
Site Checklist After The Onboarding
Imperva actively protects the site only after the customer switches the site’s DNS settings to Imperva records.

Run a DNS query for the
website and check that:
1. The DNS records of the To check the DNS records,
HTTP/s services are you can use this DNS tool
pointing to Imperva
CNAME /IP’s only. .
1. DNS Records Imperva only serves HTTP
2. If other services are
hosted on the same and HTTPS traffic. Any
server such as Mail or FTP, other protocol would be
ensure that their A blocked.
records are pointing to
the origin server.
Open the Portal real time Portal area: Websites >
2. End-to-End Test dashboard. Generate Dashboard > Real-Time
HTTP/S request to the The Real time dashboard

domain protected by
Imperva. Check that the should reflect samples of
dashboard displays the the current session
request information and connected to the site
that the client receives through the Imperva PoPs
the content.
If you have uploaded your
Make sure the SSL is
own certificate to the
properly configured.
Portal, your certificate
Generate an HTTPS
will be used only for SNI
request to your site using
supporting web clients
3. SSL Test a web browser and check
(e.g., all modern web
that the correct certificate
browsers). Otherwise, the
is displayed (either
Imperva generated
Imperva or your own
certificate will be
custom certificate).
displayed.
Generate real traffic from
It’s important to verify
your API clients and other
that there are no service
non-browser services to
interruptions after
4. Non-browser clients test validate that the site’s
switching to Imperva DNS
security policy for non-
for API clients, bots,
browser clients is well
monitoring services, etc.
defined.
Portal area: Websites >
Dashboard > Security
The Dashboard provides

Review your security
information on security
dashboard and adjust
5. Security Dashboard events that were detected
security policy according
by Imperva. For some
to your needs.
threats, the default action
should be changed to
“Block” to protect the
website.
When working with
In case your application Imperva your server will
requires a real client IP see Imperva IPs instead of
address, please make real client IPs. However,
Original Client IP is sure you have enabled Imperva inserts by default
6.
required retrieval of this value the original client IP
from either: "X- address into two HTTP
Forwarded-For" or headers: "X-Forwarded-
"Incap-Client-IP" header. For" and Imperva header
"Incap-Client-IP".
It’s recommended to visit
Please visit our status
System health and the status page on a
7. page https://
maintenance regular basis for updates
status.imperva.com/ for
on the service.

maintenance information
and system status.
Account Level Check List
Access to the account settings:
1. On the top menu bar, click Account > Account Management.
2. On the sidebar, click Account Management > Account Settings.
When a new account is

created, the default
configuration for the
Make sure that your notification is the Account
notification email admin. If you wish to add
1. Notification addresses are updated in email addresses to the
the” E-mail for notification list, add them
Notifications field” in the” E-mail for
Notifications field” with ‘;’
as a separator between
email addresses.
Imperva’s 2FA provides an

Review the two factor
authentication layer for
Two Factor authentication settings
2. your Imperva portal login.
Authentication and enable per your
Users in your organization
security policy.
who are predefined in the

account user list will login

to the Imperva portal
after going through the
2FA process.
If there are any IP
You can restrict the access
restrictions for login to
3. Login to the portal only from a
the Portal, please add
specific IP.
them.
The information in the
Set the account time zone Portal will display
4. Time Zone
with your location. according to the set time
zone.
Indicate whether a
weekly report should be Enable/display the
5. Weekly Report
generated for the account weekly report.
activity.

Cloud Maintenance Policy

This topic describes the Imperva cloud maintenance policy and how customers are informed of maintenance activity.
Essential Maintenance

Required for a production incident that is currently

Definition
or potentially affecting our customers.
Advance Notice None.
Schedule As needed to stabilize and prevent customer impact.
The Imperva cloud is designed to be a distributed
fault tolerant service. A PoP undergoing
Impact on Service
maintenance should not impact the level of service
as traffic is routed to the nearest available PoP.
Customers are notified as follows:

Communication Method
• Status page notification
• Email to Infrastructure Protection customers
Scheduled Maintenance

Required for:
Definition • Infrastructure hardware/software changes

which may pose a risk
• Infrastructure upgrade
Advance Notice A minimum of two weeks.
We aim to conduct scheduled maintenance as

follows:
Schedule • On Sunday (preferable)

• During office off hours (20:00 – 8:00 according
to PoP local time)
• One PoP at any given time
The Imperva cloud is designed to be a distributed

fault tolerant service. A PoP undergoing
Impact on Service
maintenance should not impact the level of service
as traffic is routed to the nearest available PoP.

Customers are notified as follows:

Communication Method
• Status page notification
• Email to Infrastructure Protection customers
For details on status page notifications, see Notifications.
See also:
• Imperva Data Centers (PoPs)

• Maintenance Readiness: DDoS Protection for Networks

Cloud Application Security Release Notes

Our release notes provide information on changes and enhancements in each release.
• October 2, 2022 Release

• September 18, 2022 Release
• August 28, 2022 Release
Tip: Open the latest release notes directly from the Cloud Security Console's Help menu.
To subscribe to updates about weekly releases, add the following link to your RSS feed reader:
https://docs.imperva.com/bundle/cloud-application-security/page/release-notes.rss

October 2, 2022 Release

Note: Unless otherwise specified, the changes described here are rolled out throughout the week and may not be
immediately available in all accounts.
In this release:
• Account Takeover Protection: Tarpit mitigation

• Near Real-Time SIEM: ARN role-based authentication for S3
• Time range change in Network Protection dashboards
• New version of the Imperva Terraform Provider
• Heads Up: Removal of old Performance and Traffic dashboards
• Recently mitigated CVEs
Account Takeover Protection: Tarpit mitigation
A new type of mitigation action was added to Account Takeover (ATO) Protection.
When configuring a custom mitigation strategy for your website, you can now assign the Tarpit mitigation action in
addition to the existing Block and Captcha actions.
Tarpit mitigation delays the connection for the login request without immediate notification to the client. This leads
to confusion about the request status, causing the attacker to waste more of their time and resources.
For more details on mitigation actions, see Configure Mitigation Rules.

Near Real-Time SIEM: ARN role-based authentication for S3
For enhanced security, you can now define a connection to your S3 bucket using the AWS Amazon Resource Name
(ARN) authentication with an Identity and Access Management (IAM) role.
To enable this method, you define a role in your S3 bucket policy that grants Imperva permission to upload log files to
the destination path/folder you specify.
Availability: The option is currently available via the UI for the Advanced Bot Protection (ABP) and Network Security
(DDoS Protection for Networks/IPs) services using the SIEM integration.
Where it’s located: On the Log Configuration page.
2. On the sidebar, click SIEM Logs > Log Configuration.
For details on configuring this new connection method, see Configure the SIEM Log Integration.
Time range change in Network Protection dashboards
To enhance caching and performance, the following change was made to the Network Protection dashboards.
When selecting a time range of the last 7, 30, or 90 days, the time period is now rounded to the last hour.

What changed: Previously, the time range was based on the exact time that the dashboard was loaded.
For example, for the last 7 days:
• Before: 06 Jul 2022 07:35:00 – 13 Jul 2022 07:35:00
• After: 06 Jul 2022 07:00:00 – 13 Jul 2022 07:00:00
There is no change in the following:
• The time range for the last 24 hours is not rounded. For example: 12 Jul 2022 07:35:00 – 13 Jul 2022 07:35:00.
• The custom range option always spans from 00:00 on the first day to 23:59 on the last day of the range.
New version of the Imperva Terraform Provider
Version 3.8.6 of the Imperva Terraform Provider is now available.
For the list of changes included in this version, see CHANGELOG.md.
For more details on the Imperva resources, see the Terraform Registry.
Heads Up: Removal of old Performance and Traffic dashboards
As of October 23, 2022, the Performance and Traffic tabs of the old Website Dashboard page will no longer be
accessible.
The new website Performance dashboard covers both of these areas and introduces improved usability, faster
investigation time, as well as more actionable data.
Where it's located: To access the new dashboard:
1. On the top menu bar, click Application.
2. On the sidebar, click WAF > Dashboards > Performance.
For more details about the new dashboard, see Website Performance Dashboard.
Recently mitigated CVEs
Mitigation for new Common Vulnerabilities and Exposures (CVEs) is added weekly by Imperva Research Labs.
To view the latest CVEs for which coverage was added, see Recently Mitigated CVEs.

To subscribe to updates about weekly releases, add the following link to your RSS feed reader: https://
docs.imperva.com/bundle/cloud-application-security/page/release-notes.rss

September 18, 2022 Release

In this release:
• Near Real-Time SIEM: Automatic onboarding for CWAF

• DDoS Protection for Networks: Automated confirmation calls for on-demand customers
• New Account Users page with Identity Management
• New My Profile page with Identity Management
• Policies API response has changed
• Adding exceptions to Policies
• Updates to SAN status definitions
• Waiting room visitor page template updated
• Fixed: Inaccurate usage data in the Account Dashboard
Near Real-Time SIEM: Automatic onboarding for CWAF
Onboarding to the Near Real-Time SIEM log integration for Cloud WAF customers has been reduced from one week to
several minutes.
Imperva's Near Real-Time SIEM solution sends security event logs for Imperva's cloud services to your S3 cloud
storage repository.
What changed: Once you configure the integration, your account is automatically onboarded to the new Near Real-
Time SIEM mechanism within several minutes. Previously, the onboarding was performed manually by Imperva.
Where it’s located: Configure the settings on the legacy log integration page and select the S3 method. In the Cloud
Security Console, open the SIEM Logs > WAF Log Setup page. For details on setting up the integration, see Cloud
WAF Log Integration.
For details on Imperva Near Real-Time SIEM, see Near Real-Time SIEM Log Integration.
DDoS Protection for Networks: Automated confirmation calls for on-
demand customers
When a DDoS attack is detected, a member of our Network Operations Center (NOC team) calls customers who are
working in on-demand mode and have requested confirmation before their network ranges are diverted through
Imperva.
What changed: This phone call has now been replaced by an automated call, notifying you more quickly when a
DDoS attack is detected.
During the automated call, you have the option of connection to a Support engineer, if needed.
Availability: We are gradually rolling out this change to the applicable customers over the next several weeks.

For more details on notifications, see Flow Monitoring Settings.

New Account Users page with Identity Management
Over the next several weeks, we are starting to gradually roll out the new Account Users page, under User
Management. It provides usability enhancements that enable account administrators to update user settings more
easily.
What changed:
• Bulk updates: Select multiple users and more quickly update their settings (Lock users, Delete users and Reset
password).
• Account users table:
• Status and Roles columns were added to enhance filtering results.
• Columns that were removed: Creation Date (now appears under a user's name on the Settings panel),
Two Factor Status (reduced performance), and User ID (replaced by email).
• It is no longer possible to search on a User ID.
• Filters: Refine results by specifying definitions from Status, Roles and External users.
• Set as account admin: Update a user directly from the Actions menu (Settings panel).
• Roles: Search the enhanced view of an assigned role with enabled permissions, as well as associated services
and types.
Where it’s located: Account (top menu bar) > Account Management, which opens User Management (side menu
bar) > Users.
For more details, see: Manage Account Users
Rollout and migration: In this release, we are introducing the new Account Users page to selected, direct customers
(not resellers). We will provide updates in future release notes about the continued rollout. To request access to the
new page at an earlier date, contact Support.
New My Profile page with Identity Management
Over the next several weeks, we are starting to gradually roll out the new My Profile page, under User Management. It
provides usability enhancements that enable users to view and update their personal settings more easily.
What changed:
• Multi-factor authentication: Users can now configure additional methods for receiving a passcode: Okta Verify
app and phone call.
• API keys: Users can now create and update API keys (up to 5), which are dependent on their user-defined roles
and permissions, directly from their My Profile page.

Note: Users with limited permissions that have access to the new My Profile page will no longer be able to
access API keys from User Management > API Keys.
For more details, see User with limited permissions, under API Key Management.
• Roles: Users can now view their assigned roles with enabled permissions, as well as associated services and
types.
Where it’s located: Account (top menu bar) > My Profile, which opens User Management (side menu bar) > My
Profile.
For more details, see: My Profile
Rollout and migration: In this release, we are introducing the new My Profile page to selected, direct customers (not
resellers). We will provide updates in future release notes about the continued rollout. To request access to the new
page at an earlier date, contact Support.
Policies API response has changed
To align with our current API standards and conventions, the response for invalid JSON errors is now returned in a
single structure that is more traceable and detailed. Previously, the API response for invalid JSON errors returned
different responses and was harder to track.
Details of the specific error type are provided within the new response structure.
For example:
"headers": {},
"body": {
"errors": [
{
"status": 400,
"id": <trace_id>,
"source": {
"pointer": "<route>"
},
"title": "unexpected value at: …."
}
]
},
"statusCodeValue": 400,
"statusCode": "BAD_REQUEST"
}
Note: This change applies only to invalid JSON errors. The response structure of other errors remains unchanged.
For details on the Policies API, see Policy Management API Definition.

Adding exceptions to Policies
New options were added for setting a URL exception on a policy.

What changed: Previously, you could define an exception on a specific URL. Now you can configure the exception
according to any of the following options:
• URL is/is not
• URL contains/does not contain
• URL starts with/does not start with
• URL ends with/does not end with
For more details on policies and configuring exceptions, see Create and Manage Policies.
Updates to SAN status definitions
The SAN details table (SSL Certificates page) now displays the following updated status definitions:
• SANs that had the Published status now display the Validated status.
• SANs that are set for automatic validation are now tagged Automatic and have the In Process status, instead of
Pending user action.
Where it’s located: From the Cloud Security Console > Application > SSL/TLS (side bar) > SSL Certificates >
Certificates: SAN.
For more details, see SAN details under View SSL Certificates.
Waiting room visitor page template updated
The default HTML template used as the basis for the waiting room page that is displayed to your website visitors has
been updated.
The following placeholder variables used for template validation were added:
• $WAITING_ROOM_LOADER$ - Used to validate the loading of the page. This parameter is mandatory and should
not be modified or deleted.
• $WAITING_ROOM_WRAPPER$ - Used to validate the content of the template. This parameter is mandatory and
should not be modified or deleted.
Where it’s located: On the Add/Edit Waiting Room page, under HTML Customization.
For more details, see Waiting Rooms.

Fixed: Inaccurate usage data in the Account Dashboard
As of August 29, 2022, the Usage (95th percentile) column in the Sub account table of the Account Dashboard
displayed inaccurate data.
The issue is now resolved.
Root cause:

For enhanced data fetching performance and loading of historical data for large accounts, the fetching resolution was
changed. This resulted in a discrepancy between the usage displayed on the Account Dashboard, and the usage
displayed in the Usage Report.
Impact:
There was no impact on billing. The usage displayed on the Account Dashboard is used for informational purposes
only. To view account usage data that is used as the basis for billing your account, see the Usage Report.
The fix:
• The change in fetching that caused the issue was reverted.
• The label and tooltip of the Usage column were updated to remove reference of the 95th percentile and clearly
state that this data is not used for billing purposes. A link to the Usage Report was also added to the tooltip.
• The 95th percentile indicator on the Website Traffic > Bits per second chart was deemed irrelevant and
confusing and was removed.
Where it’s located:
• Account Dashboard: When you log in to the Cloud Security Console, the account dashboard is displayed by
default. Alternatively, click Home on the top menu bar.
• Usage Report:
• On the top menu bar, click Account > Account Management.
• On the sidebar, click Account Management > Usage Report.



In this release:
• DDoS Protection for Networks: Define connectivity in sub accounts

• Advanced Bot Protection: New Mobile SDK versions
• Refactored Security Events page
• Heads Up: API Security Role-Based Access Control
DDoS Protection for Networks: Define connectivity in sub accounts
You can now define origin connectivity in sub accounts, in addition to the parent account. Defining a connection (such
as a GRE tunnel) in a sub account enables you to isolate traffic for ranges in a specific sub account to flow through a
connection dedicated to that sub account.
Previously, connections could be created in the parent account only, and were then shared by the parent and sub
accounts.
Where it’s located: Connections are defined in the Cloud Security Console on the Network > Network Protection >
Connectivity Settings page.
For details on enabling and working with this feature, see Sub Account Support.
Advanced Bot Protection: New Mobile SDK versions
New versions of the ABP mobile SDKs for iOS and Android are now available.
ABP iOS Mobile SDK version 2.2.0
This release adds the collection of additional biometrics information including gyroscope and rotation data. The SDK
module sends the collected data back to ABP, improving bot analysis.
To turn on the new functionality, use the SDK’s Protection object. It is not enabled by default.
ABP Android Mobile SDK version 3.2.1
The SDK code (apart from the API signature classes) is obfuscated using DexGuard to protect intellectual property. If
you do not exclude this code from any subsequent obfuscation of your application, this can cause runtime errors. The
release includes ProGuard rules to prevent double obfuscation and a sample mobile application built with ProGuard
to illustrate this. In addition, the modules obfuscated code is now rationalized under a single well known package
path to simplify exclusion for other obfuscation tools (i.e. other than ProGuard).

Download the new versions
You can download the new versions from ftp://ftp-us.imperva.com or ftp://ftp-eu.imperva.com. For more information,
see Downloading the ABP SDK Software.
For more information on the SDK, see Working with ABP SDK.
Refactored Security Events page
We have made significant backend improvements to the Security Events page and are starting a gradual rollout of
this change.
Availability: We are gradually rolling out this improvement over the next several months. It may not be immediately
available in your account.
What changed: There are currently no major visible changes to the page. We have implemented this change in
preparation for the development of new features in the near future. Minor noticeable changes include:
• Newer events are using the new infrastructure, while older events continue to be based on the previous
infrastructure. When you move from a time range that is using the old infrastructure to one that is using the new
infrastructure or back again, a pop up is displayed indicating that the page has been redirected by Imperva. For
example, if you view data for the last 7 days, and then select the option for the last 30 days, the page is
redirected.
Data for all time ranges will eventually be based on the new infrastructure and available on the current page, so
users will no longer be redirected.
• The URLs of the old and new pages are different:
• Current page: The URL includes events-page in the path. (No change.)
• New page: The URL includes event-page-ng in the path. (Accounts rolled out with new infrastructure
will be temporarily redirected to this new path, depending on the data range selected. After
approximately 90 days of time range data has been collected, the URL redirect will be removed.)
• When viewing an event on the new page, the Policy ID of a triggered policy is now part of the request details.
Previously, it was part of the session details. Similarly, the Edit policy option is now available at the request
level instead of at the session level.
2. On the sidebar, click Security Events.
For more details on the Security Events page, see View Security Events.
Heads Up: API Security Role-Based Access Control
As part of an effort to enhance administrative security, role-based access control will be enforced in API Security
starting October 23, 2022. Two permissions are added:

• View All API Security allows read access to API Security. Users with this ability as part of their role definition
will be limited to viewing API security configurations, inventories, and events.
• Edit All API Security Configs allows the user to edit API Security configurations.
The predefined Reader role will include the View All API Security permission by default.
The predefined Administrator role will include both permissions by default.
Customer admin users can add these permissions to their custom defined roles if users with custom roles need access
to API Security.
Because role-based access control was not enforced on API security in the past, some users will lose access when the
enforcement takes place starting October 23, 2022. For example, users with the default Reader role will lose the
ability to edit API Security configurations. Users with only custom roles will lose all access to API Security if
permissions are not added to the custom roles.
Recommended action: You are encouraged to review all user roles that use API Security before October 23, 2022 to
ensure proper access is enabled, especially for users with custom roles.
Where it’s located: On the Cloud Security Console Roles page.
2. On the sidebar, click User Management > Roles.
For more details, see Manage Roles and Permissions.



In this release:
• Imperva Support Case Creation changes go live

• "Download Bandwidth History" button removed
• API Security: Support for Multiple Data Types
• Enabled: 1-step HTTPS setup in the Website Onboarding Wizard
Imperva Support Case Creation changes go live
Effective September 8, 2022, Support case creation will only be available via the Support Portal (or phone).
What changed: A link to the Support Portal will replace all existing email references throughout all system files,
product UX, email templates and documentation.
For details and to claim your Support Portal access, visit the Imperva Support & Services blog.
"Download Bandwidth History" button removed
The Download Bandwidth History button that enabled you to download bandwidth data for the current and two
previous billing cycles was removed from the Subscription page.
Instead, you can access an extended usage history for your account in the following ways:
• The Usage Report provides an enhanced view of your account’s bandwidth usage per service over time,
enabling you to easily understand usage trends and quickly detect overages in your account. You can also
download the report.
Where it’s located: In the Cloud Security Console, navigate to Account > Account Management > Usage
Report.
• The Usage Report API enables you to retrieve bandwidth usage history for your account.
For details, see View Account Usage.

API Security: Support for Multiple Data Types
Endpoint parameters can now show supported multiple data types in a drill down page.
What changed: When drilling down on an endpoint shown on the Inventory page, multiple data types are now
indicated for each parameter of the endpoint.
Enabled: 1-step HTTPS setup in the Website Onboarding Wizard
The Configure SSL for a new site option is once again enabled and now appears in the Site Onboarding wizard. It lets
you onboard a new site in 5 minutes and eliminates the need to complete validation of domain ownership via txt or

email. This option is suitable for a domain that does not have traffic. It was initially announced in the June 26, 2022
Release.
For more details, see Configure SSL for a new site, under Onboarding a Site – Web Protection and CDN.
For more details on APIs, see Cloud Application Security v1/v3 API Definition.
Where it’s located: Websites > Add website.



August 28, 2022 Release

In this release:
• DDoS Protection for Networks: Manually divert your ranges on demand

DDoS Protection for Networks: Manually divert your ranges on demand
DDoS Protection for Networks customers working in on-demand mode can now manually divert and revert their
network ranges.
What changed: Previously, the divert and revert actions were only performed by Imperva, either automatically or via
Support.
Now, you can divert your ranges directly from the Cloud Security Console as needed. For example, this can be useful
when:
• Imperva has attempted to contact your organization but you could not be reached. You then receive email
and/or SMS notification from Imperva that you are under attack and can immediately divert your ranges.
• You want to divert a range to test performance when your traffic is diverted to Imperva. Previously, this required
a Support Ticket.
• You want to avoid reverting traffic back to your network during peak business hours. You can now choose to
revert traffic before the end of Imperva’s “clean traffic waiting period”, or optionally extend the diversion by an
additional 72 hours during which time you will be able to schedule the revert.
Note: The on-demand divert option applies only to ranges whose diversion is controlled by Imperva. If you are
controlling your ranges, by starting/stopping BGP advertisement or adding/removing the "no-export" community,
you cannot manually divert those ranges.
• On the Network Security Dashboard. In the Cloud Security Console, navigate to Network > Network Protection
> Dashboard and click the Security tab. The On-Demand Diverted Ranges widget is displayed in the banner.
Click Configure to diver/revert your ranges. For details, see Security Dashboard: DDoS Protection for Networks
and IPs.
• Via the API. For details, see Network Range Diversion API Definition.

Availability: We are gradually rolling out this feature to our customers. It may not be immediately available in your
account.
For more details on this feature, see Control Network Range Diversions.


In this release:
• API Security: API Calls section added to the account dashboard

• API Security: Support for HEAD and OPTIONS methods
• New Imperva Data Center in Manilla, Philippines
• Heads Up: Removal of "Download Bandwidth History" button
API Security: API Calls section added to the account dashboard
A new API Calls section was added to the Cloud Security Console’s account dashboard, indicating the total number of
API calls and the trend over time.
1. When you log in to the Cloud Security Console, the account dashboard is displayed by default. Alternatively,
click Home on the top menu bar.
2. The new API Calls section is displayed under Website Traffic.


For more details, see:
• Homepage Dashboard
• Imperva API Security

API Security: Support for HEAD and OPTIONS methods
HEAD and OPTIONS methods are now supported in API Security for API Discovery and Data Classification.
What changed: In the API Security > Inventory page, you can now see HEAD and OPTIONS methods under the APIs
Inventory section.
New Imperva Data Center in Manilla, Philippines
We are starting to roll out a new data center (PoP) in Manilla, Philippines and expect it to be fully functional within the
next few weeks.
The Manilla PoP is the newest addition to our world-wide network of 50 data centers, helping you deliver your
applications securely and optimally across the globe.
For the full list of PoPs, see Imperva Data Centers (PoPs).
Heads Up: Removal of "Download Bandwidth History" button
On August 28, 2022, the Download Bandwidth History button that enables you to download billing date for the
current billing cycle and two previous billing cycles will be removed from the Subscription page.
Report.




In this release:
• API Security: API Calls added to the account dashboard

• ATO/CSP: Easily submit a feature request
API Security: API Calls added to the account dashboard
Statistics on API calls were added to the Cloud Security Console’s account dashboard, providing you with information
on the volume of API traffic to your websites.
What changed:
• In the Website Traffic > Top websites section, an option was added to sort the list of websites according to
their API call count.
• In the Traffic by Geo Location section, an option was added to view the traffic distribution by API calls.
Where it’s located: When you log in to the Cloud Security Console, the account dashboard is displayed by default.
Alternatively, click Home on the top menu bar.


ATO/CSP: Easily submit a feature request
You can now easily submit a request for a feature enhancement directly from the Account Takeover Protection and
Client-Side Protection dashboards.
For example:


Report.




In this release:
• API Security: Data Classification

• Account Takeover Protection: View dashboard data per login endpoint
• Time range change in dashboards
• Certificate Management pages have moved
• DNS Protection menu name changes
API Security: Data Classification
API Security was enhanced, enabling users with the Advanced license to set any of the data labels to Sensitive and
Visible in the Settings page.
What changed: A new section called Data Classification was added to the API Security Settings page. When you set
the data labels to Sensitive and Visible, they are displayed in the API Security > Dashboard and API Security >
Inventory (Discovered APIs and My APIs tabs) pages.
Where it’s located: API Security > Settings
For more details, see: Settings, Discovered APIs Dashboard, Discovered APIs (Inventory) and My APIs (Inventory)
pages.
Account Takeover Protection: View dashboard data per login endpoint
If you have defined multiple login endpoints for a website, you can now display data for an individual endpoint.
What changed: By default, the ATO Dashboard displays data for all endpoints simultaneously. You can now select an
endpoint from the new Endpoint Selection drop-down. The dashboard is then refreshed and displays data for the
selected endpoint only.
Where it’s located: On the Account Takeover Protection dashboard banner.

Note: The User Anomaly section on the Dashboard is not currently refreshed by the endpoint selection and continues
to display data for all endpoints.
For more details on the Account Takeover Protection dashboard, see Explore the Data.
Time range change in dashboards
To enhance caching and performance, dashboard data is now provided as follows:
When selecting a time range of the last 7, 30, or 90 days, the time period is now rounded to the last hour.
What changed: Previously, the time range was based on the exact time that the dashboard was loaded.
For example, for the last 7 days:
• Before: 06 Jul 2022 07:35:00 – 13 Jul 2022 07:35:00
• After: 06 Jul 2022 07:00:00 – 13 Jul 2022 07:00:00
There is no change in the following:
• The time range for the last 24 hours is not rounded. For example: 12 Jul 2022 07:35:00 – 13 Jul 2022 07:35:00.
• The custom range option always spans from 00:00 on the first day to 23:59 on the last day of the range.
Availability:
• The change was implemented for most dashboards in the Cloud Security Console and will be rolled out to the
remaining dashboards at a later date.
• This change does not apply to the Security Events page, which will continue to reflect the exact time period
requested. For example: 06 Jul 2022 07:35:00 – 13 Jul 2022 07:35:00.
Certificate Management pages have moved
In preparation for upcoming enhancements to Imperva’s Certificate Management capabilities, the following changes
were made in the Cloud Security Console:

UI Page Details New location
This page is used for uploading

and managing client CA
certificates for your account.
From: Account Management >

Client CA Certificates
The Client CA Certificates account-
level page has moved. To: Application > SSL/TLS > Client
CA Certificates
Note: The sidebar menu item has

also remained in the previous
location and when clicked, opens
the page in its new location.

This page is used for managing

client CA certificates assigned to
the specific website.
The Client CA Certificates website- From: Website Management >

level page has moved. Origin and Network > Client CA
Certificates
To: Website Management >

SSL/TLS > Client CA Certificates

This page is used to view SSL

server certificate details and status
for all websites in your account.
The SSL Certificates page has
From: Account Management > SSL
moved.
Certificates
To: Application > SSL/TLS > SSL

Certificates
For more details on these feature, see:
• Client Certificate Support
• View SSL Certificates

DNS Protection menu name changes
The DNS menu items on the Cloud Security Console sidebar have changed.
• DNS Protection was renamed DNS.
• Protected DNS Zones was renamed DNS Zones.
Where it’s located: In the Network area.


Report.



July 31, 2022 Release

Deprecation of WAF settings API and Terraform
Following the migration of WAF settings to the new WAF Rules policy, the old WAF setting APIs and Terraform
resources are now deprecated.
The WAF Rules policy type enables you to easily manage your mitigation settings for website WAF rules in a central
policy, while still benefiting from the default out-of-the-box policies. You can define a policy once, and apply it to
multiple websites in your account.
Once your account is migrated, the following changes apply:
You can no longer use the following APIs to

configure WAF settings and exceptions.
• /api/prov/v1/sites/configure/allowlists
• /api/prov/v1/sites/configure/whitelists
• /api/v1/sites/{SiteId}/settings/rules/
SQL_INJECTION/exception
API
CROSS_SITE_SCRIPTING/exception
ILLEGAL_RESOURCE_ACCESS/exception
• /api/v1/sites/{SiteId}/Settings/rules/
REMOTE_FILE_INCLUSION/exception
Instead, use the Policies API to configure WAF Rules.
Details of the WAF settings and exceptions will be

removed from the following Site Management APIs:
API • Get site status
• All other Site Management APIs that return

details of the site’s WAF settings configuration

You can no longer use the

incapsula_waf_security_rule and
incapsula_security_rule_exception Terraform
resources with the following rule_id values to
configure WAF settings and exceptions:
• api.threats.cross_site_scripting
Terraform
• api.threats.illegal_resource_access
• api.threats.remote_file_inclusion
• api.threats.sql_injection
Instead, use the incapsula_policy Terraform

resource.
• Create and Manage Policies
• Policy Management API Definition
• FAQ: WAF Settings Migration


In this release:
• New login page

• New Imperva Data Center in Cape Town, South Africa
• Disabled: 1-step HTTPS setup in the Website Onboarding Wizard
• Near Real-Time SIEM events added to Audit Trail
New login page
In preparation for upcoming enhancements to our login process, a new login page was added.
What changed: When you log in to the Cloud Security Console, this page is now displayed. After entering your email
address, the process continues on to the standard screen, enabling you to enter your password or to log in via SSO.

New Imperva Data Center in Cape Town, South Africa

We are starting to roll out a new data center (PoP) in Cape Town, South Africa and expect it to be fully functional
within the next few weeks.
The Cape Town PoP is the newest addition to our world-wide network of 49 data centers, helping you deliver your
Disabled: 1-step HTTPS setup in the Website Onboarding Wizard
Configure SSL for a new site, the 1-step SSL setup option, has been temporarily turned off. The feature will return
shortly with enhancements.
What changed: There are now two site onboarding options: Configure SSL for an active site and No Imperva
certificate.
For more details, see: Onboarding a Site – Web Protection and CDN.


Near Real-Time SIEM events added to Audit Trail
Changes you make to the Near Real-Time SIEM log integration in your account are now tracked and displayed in the
Audit Trail.
For customers who were using the previous log integration, the new audit events also track migration of your account
to the new Near Real-Time SIEM mechanism.
The new event types include:
• Log configuration created/updated/deleted
• Connection created/updated/deleted
• SIEM log integration migrated
• SIEM log integration rolled back
The Audit Trail displays a log of actions performed in your account by: account users, system processes, and Imperva
system administrators and support.
Where it’s located: In the Cloud Security Console, navigate to Account Management > Audit Trail.
• Audit Trail
• Near Real-Time SIEM Log Integration



In this release:
• New Imperva Data Center in Rio de Janeiro, Brazil

• API Security: Filtering enhancements
• Website Performance Dashboard: Delivery Rules
• Heads Up: Deprecation of WAF settings API and Terraform
• Heads Up: Deprecation of certificate details from Get Site Status API
New Imperva Data Center in Rio de Janeiro, Brazil
We are starting to roll out a new data center (PoP) in Rio de Janeiro, Brazil and expect it to be fully functional within
the next few weeks.
The Rio de Janeiro PoP is the newest addition to our world-wide network of 48 data centers, helping you deliver your
API Security: Filtering enhancements
The API Security Inventory page was enhanced with the following improvements:
My APIs tab > APIs Inventory widget: You can now filter the displayed data.
Discovered APIs tab > APIs Inventory widget. When you click an endpoint to drill down:
• You can now filter the request and response by Type and by Constraint.
• The Copy as JSON feature now takes into account the filters you have set.
Where it’s located: In the Cloud Security Console, navigate to Application > API Security > Inventory.
Website Performance Dashboard: Delivery Rules
Details of Delivery rules and statistics are now presented in the Website Performance Dashboard. This information
was not previously migrated to the new Website Performance Dashboard and had only been available on the old
Website Dashboard.
What's changed:
• Search function was added to find a specific Rule Name or Action.
• Filter function was added to limit the Delivery Rules displayed (up to 5 selected websites).

• Sort functionality was added to view data by Rule Name, Action or Hits columns.
Where it’s located: On the Website Performance Dashboard, click Delivery Rules (next to Visits by country).
• Website Performance Dashboard
• Create Rules
Heads Up: Deprecation of WAF settings API and Terraform
As of August 1, 2022, following the migration of WAF settings for all customer accounts to the new WAF Rules policy,
the old WAF setting APIs and Terraform resources will be deprecated.
Once your account is migrated, the following changes apply:
You can no longer use the following APIs to

configure WAF settings and exceptions.
SQL_INJECTION/exception
API
CROSS_SITE_SCRIPTING/exception
ILLEGAL_RESOURCE_ACCESS/exception
• /api/v1/sites/{SiteId}/Settings/rules/
REMOTE_FILE_INCLUSION/exception
Instead, use the Policies API to configure WAF Rules.
Details of the WAF settings and exceptions will be

API removed from the following Site Management APIs:
• Get site status

• All other Site Management APIs that return

details of the site’s WAF settings configuration
You can no longer use the

incapsula_waf_security_rule and
incapsula_security_rule_exception Terraform
resources with the following rule_id values to
configure WAF settings and exceptions:
Terraform
Instead, use the incapsula_policy Terraform

resource.

Heads Up: Deprecation of certificate details from Get Site Status API
The SSL details of the Get Site Status API (/api/prov/v1/sites/status) have been deprecated and will be removed from
the API response as of October 1, 2022.
You can now retrieve certificate details for your protected websites using the new SSL Certificates API. For details, see
SSL Certificates API Definition.



New rule filter parameters
The following rule filter parameters are now available:
• Response Content-Type: Checks for the value of the HTTP Content-Type header sent by the origin server in the
response. You can use this filter parameter in a Rewrite/Remove Response rule or a custom cache rule.
• Content Datacenter ID: Checks for the Imperva ID of the destination origin data center for the request.
This ID is relevant to your data centers that are defined to support only forward rules (data centers that you
have defined in Website Origin Server Settings with the Support only forward rules option enabled).
• Origin Destination IP: Checks for the IP address of the destination origin server for the request.
Where it’s located: On the Cloud Security Console Rules page (Application > Websites > <select a website> > Security
> Rules).
For more details on creating rules and configuring these parameter, see:
• Create Rules
• Rule Filter Parameters
• Cache Settings


In this release:
• Automatic site revalidation with CNAME

• Contingency DDoS Network Protection
• API Security: Verification
• Override default mitigation settings for slow HTTP attacks
• Near Real-Time SIEM log integration updates
• Waiting Rooms: Rollout Complete
• DDoS Protection for Networks: On-demand mode update
• Website Real-Time Dashboard: Visitor samples
Automatic site revalidation with CNAME
The CNAME option has been added to the procedure for validating domain ownership by DNS record. You can now
generate a unique CNAME value to enter in your DNS provider’s portal when onboarding a new site or revalidating an
Imperva certificate. Imperva then references it to prove domain ownership and uses it to automatically renew the
site’s Imperva certificate when it expires.
What changed:
• UI: During site onboarding or certificate revalidation, a new drop-down menu for Record type offers both
CNAME and TXT options. Selecting the CNAME option generates a unique value that you copy into your DNS
records to complete domain validation of an active site. For more details, see Onboarding a Site – Web
Protection and CDN or Revalidate Your Imperva Certificate.

• API: The API has been updated to include the CNAME value, as follows: Add Site API (/api/prov/v1/sites/add) to
receive the CNAME/A records required for traffic configurations, then the Modify Site Configuration API (/api/
prov/v1/sites/configure) with the parameter domain_validation and value CNAME. In response, you will receive
the value for the CNAME record. For details, see the Site Management section of Cloud Application Security
v1/v3 API Definition.
Contingency DDoS Network Protection
We are introducing a new on-demand service that offers a limited number of network range diversions to redirect
your traffic to Imperva Network Protection when under attack.
Contingency DDoS Network Protection is intended as a backup service in the event of an outage in your primary
protection service.
In the Cloud Security Console, you can independently divert and revert your ranges as needed.
Where it’s located: When the service is enabled in your account, you can manage your ranges as follows:
1. Navigate to the Network Protection Security Dashboard (Network > Network Protection > Dashboard >
Security > Protected Networks tab).
2. The On-Demand Diverted Ranges widget displays the number of currently diverted ranges, and time
remaining until the range is automatically reverted (72 hours after divert, unless still under attack. In that case,
Imperva reverts the range once the attack ends).

3. Click Configure to select a range to divert or revert. You can also see the number of remaining diversions
For more details, see DDoS Protection for Networks as a Contingency Strategy.
To get started, contact your Imperva Sales Representative.

API Security: Verification
The new API Security Verification page is designed to help with auditing security best practices and to verify basic
security vulnerabilities based on the OpenAPI Specification file.
This feature consists of two tools:
• The API specification assessment tool - This tool scans through OpenAPI Specification files that you upload to
generate an assessment report, providing a risk assessment score about the API design against a set of security
best practices.
• The API security test tool - This tool creates a test bundle for you to download and run in your controlled
environment to discover any security vulnerabilities in your application. The test bundle contains a set of tests
simulating attack patterns against APIs in question.

Availability: This new feature is available with the Advanced license only.
Where it's located: Application > API Security > Verification.
For more details, see Verification.

Override default mitigation settings for slow HTTP attacks
To prevent slow HTTP attacks, we configure a request body timeout which determines the minimal number of bytes
we accept during a specified time period.
By default, Imperva provides DoS mitigation for slow HTTP attacks based on a minimum request body timeout rate of
5000 bytes received every 30 seconds.
What changed: You can choose to override the default rates for any or all of the following HTTP methods: GET, POST,
PUT, RPC_IN_DATA, RPC_OUT_DATA.
1. Navigate to the website WAF Settings page (Application > Websites > Website Settings > WAF).
2. In the DDoS section, click Slow HTTP and configure the settings.

For more details, see DDoS Settings.
API: You can also customize the mitigation settings via the API, using the request_body_timeouts parameter, under
Site Management > Modify Site Configuration. For details, see Cloud Application Security API.
Availability: We are rolling out this feature over the next several weeks. It may not be immediately available in your
account.

Near Real-Time SIEM log integration updates

The following updates are now available. For an overview of the feature, see the Near Real-Time SIEM Log Integration.
Advanced Bot Protection customers
You can now configure the log integration independently to export your Advanced Bot Protection dashboard data to
your SIEM without needing to contact Support. Previously, Support was required to enable the integration.
1. On the Cloud Security Console top menu bar, click Account > Account Management.
For details, see Configure the SIEM Log Integration.
Cloud WAF customers
You can now start using the Near Real-Time SIEM solution with the S3 push method. Previously, the new mechanism
was available only to customers already using the old log integration with the S3 method.
2. On the sidebar, click SIEM Logs > WAF Log Setup.
Note that the integration is initially configured for the old log integration mechanism and is then migrated to the new
Near Real-Time SIEM mechanism within one week.
DDoS Protection for Networks customers
The integration continues to be available per request. To enable the feature for your account, contact Imperva
Support.
Waiting Rooms: Rollout Complete
Rollout of the Imperva Waiting Room service is now complete and available to all Cloud WAF (AppProtect) customers.
Availability: One waiting room is now included with your plan. Additional waiting room licenses are available as an
add-on to the Cloud WAF service.
What are Imperva Waiting Rooms?
Waiting Rooms let you control the traffic to your website when the origin server is unable to handle the load, while
providing a seamless experience to your customers.
The solution routes your website visitors to a virtual waiting room when their requests can't be handled immediately.
Visitors are placed in a virtual queue, creating a positive user experience and preventing loss of business.

Feature highlights:
• Set activation thresholds based on the incoming rate of traffic and/or total active users.
• Create custom rules to define with more granular control when to activate a waiting room.
• Customize the waiting room page that is displayed to your customers by adding your company logo, banner,
colors, images, videos, and so on. This enables you to keep your brand recognition, as well as engage visitors
with content that promotes your brand while they wait.
• The waiting room page reports the customer’s position in line, providing an indication of when their turn to
access your website will arrive. This information is regularly updated while they wait. At a later date, we will add
the estimated wait time to the page.
• Track waiting room statistics on the Website Performance Dashboard.
For full details on the new service, see Waiting Rooms.

DDoS Protection for Networks: On-demand mode update

New events and notifications were added for our Network Protection customers working in on-demand mode,
indicating when a protected network is diverted to Imperva or reverted back to your network.
Events: New events were added to the Network Protection Dashboard, which displays a log of security events
detected by Imperva. For more details, see Security Dashboard: DDoS Protection for Networks and IPs.
• IP range diverted
• IP range reverted
SIEM events: New SIEM events were added to the ATTACK log type. For more details, see SIEM Log Integration: DDoS
Protection for Networks and IPs.
Notifications: New email notifications were added to the Network Security > Network Protection Notifications
category. Emails are sent when an IP range is diverted and reverted. For more details, see Notification Settings.
Website Real-Time Dashboard: Visitor samples
Details of security rules that were triggered by a request are now presented in the visitor samples, which enable to
you view a sampling of real-time requests.
This information was not previously migrated to the new Real-Time Dashboard and was still available only on the old
Website Dashboard.
In addition, you can now search the visitor samples according to client name or IP address.
Where it’s located: On the Real-Time Dashboard, click Show visitor samples.
• To search the samples, enter a search string or IP address.
• In a session section, click More details. If any security rules were triggered by requests in the session, they are
listed here.
• Website Real-Time Dashboard
• Rules


June 26, 2022 Release

In this release:
• Website Onboarding Wizard and new 1-step HTTPS setup

• Client-Side Protection: Introducing Instant Block
• Client-Side Protection: Isolated enforcement
• Permission update for managing custom certificates
• API Security: Discovered APIs dashboard enhancement
Website Onboarding Wizard and new 1-step HTTPS setup
The Site Onboarding wizard has been updated and now offers a new 1-step SSL setup option, Configure SSL for a
new site, that lets you onboard a new site in 5 minutes and eliminates the need to complete validation of domain
ownership via txt or email. This fast SSL setup option blocks all traffic to the site until Imperva completes domain
ownership validation, so when onboarding an active site, you should continue using the 2-step Configure SSL for an
active site which will not block your traffic. Following validation, Imperva automatically generates an SSL certificate
for your new site.

What changed: A new SSL certificate options page now provides three site onboarding options (Configure SSL for an
active site, Configure SSL for a new site, No Imperva certificate).
• The Infographic page has been removed.
• Configure SSL for a new site option lets you onboard a new HTTPS site in 1-step and skip validation of domain
ownership via txt or email. After you change the DNS record and point traffic to Imperva, we validate the domain
by HTML since the site’s traffic is now managed by Imperva.
• No Imperva certificate option replaces the "I don't want SSL" link and lets you skip creation of the Imperva
certificate when you only want to upload a custom certificate.
• Configure SSL for an active site option includes the Wildcard SAN and Naked SAN options that previously
appeared on the scanning results page.
• The Configure later button lets you skip all SSL setup options and displays the View all websites page with the
new site already added to the table.

The API has been updated to trigger the new 1-step SSL configuration when adding a new site and configuring traffic
to reach Imperva.
• Previously, you needed to run two APIs, as follows: Add Site API (/api/prov/v1/sites/add) to receive the
CNAME/A records required for traffic configurations, then the Modify Site Configuration API (/api/prov/v1/
sites/configure) with the parameter domain_validation and value (DNS/HTML/EMAIL), add the txt record and
configure the traffic.
• Today, you run the first API, configure traffic, then run the second API to automatically add SSL support for the
new site using the HTML method validation, as follows:
parameter = domain_validation, value = html
For more details, see Configure SSL for a new site, under Onboarding a Site – Web Protection and CDN.
For more details on APIs, see Cloud Application Security v1/v3 API Definition.

Client-Side Protection: Introducing Instant Block
For more granular control over your service dependencies, take advantage of Client-Side Protection's additional
blocking and testing functionality.
Enable Instant Block to take advantage of the new features:
• Out-of-the-box blocking: Client-Side Protection automatically blocks known malicious domains.
• Instant blocking: Instantly block unwanted assets even while working in Monitor mode.
• Google Analytics Tracking ID blocking: Block undesired Google tracking IDs.
When enabling Instant Block on your website, you first turn it on only for a specified IP address. This enables you to
test your settings on a limited basis before enabling the feature for your entire application.
Where it’s located: On the Client-Side Protection dashboard, click Settings to enable Instant Block.
For full details, see Instant Block.

Client-Side Protection: Isolated enforcement
Apply your Client-Side Protection settings on a limited scope to test the impact before turning on global enforcement.
What changed: You can now turn on Enforce mode for one or more specific IP addresses and for a specific path on
your website. Services that are set to be blocked will be blocked for the specified IPs and path only.
Where it’s located: On the Client-Side Protection dashboard, click Simulate Enforce and fill in the details.

For more details, see Client-Side Protection Dashboard.

Permission update for managing custom certificates
On May 29, 2022 a new permission for managing custom certificates was added, enabling you to upload, replace, and
delete custom certificates for your websites.
In this release:
• The ability to upload, replace, and delete custom certificates has been removed from the Modify Site Settings
permission.
• All existing users who were previously assigned the Modify Site Settings permission have been automatically
assigned the new Manage custom certificates permission as well.
For new roles created in your account, use only the new Manage custom certificates permission to manage custom
certificates.
API Security: Discovered APIs dashboard enhancement
The Discovered APIs dashboard was enhanced and now in the API Hosts, API Resources and API Endpoints widgets,
you can click on the Expand button to open a popup page. This page shows all items for that widget for your account,

not only the top ones as indicated in the widget. You can also filter the results on the page to show only the new ones
by selecting the checkbox.
For more details, see Discovered APIs Dashboard.


In this release:
• Advanced Bot Protection: Onboarding progress bar

• Advanced Bot Protection: Alerts for configuration issues
• Old website security dashboard removed
Advanced Bot Protection: Onboarding progress bar
For all your Website Groups, you can now see a progress bar showing where you are in your process of onboarding the
Website Group.
Advanced Bot Protection: Alerts for configuration issues
For all your Website Groups, you can now see alerts for issues you need to deal with, for example: if you haven’t
configured an allowlist, or if you haven’t activated mitigation.
Old website security dashboard removed
The content of the old website security dashboard has been removed.
The page includes a link to the new website security dashboard, introduced in 2021.
For details on the new security dashboard, see Website Security Dashboard.



In this release:
• Waiting Rooms: Threshold value change

• Fixed: Spaces ignored in non-ASCII custom rule filters
• Heads Up: Consolidation of API Security UI
Waiting Rooms: Threshold value change
The minimum allowed value for the Maximum number of active users threshold was changed from 200 to 1.
Defining a very low threshold can be useful for testing purposes. However, the recommended minimum value for
production purposes remains 200.
Note that when a threshold value of 1-199 is defined, the New incoming users per minute option is not available.

Fixed: Spaces ignored in non-ASCII custom rule filters
Problem: When a custom rule filter includes a space between non-ASCII character words, the space was ignored for
some rule filter parameters.
Resolution: The issue is fixed. Relevant custom rules now work as intended.
For more details on custom rules, see Create Rules.

Heads Up: Consolidation of API Security UI
In order to improve the Cloud WAF API Security administrative user experience, we are consolidating the API Schema
Protection UI into the API Security UI.
This change is scheduled to take place starting June 19, 2022, and will be gradually rolled out to all accounts over the
following 2 weeks.
API Schema Protection based on uploaded API specifications will continue to work. The old API Discovery and
Automatic Integration functions will be deprecated during the same rollout period. Customers interested in API
Discovery and Automatic Integration are welcome to consider the Cloud WAF API Security Add-on. Contact your
Imperva Sales Representative if you have any questions.



Advanced Bot Protection Updates
New Executive Report Dashboard
A new report dashboard is available that provides key data for executives including: traffic types; mitigation by site;
CAPTCHA effectiveness by site; triggered conditions; traffic listing. You can schedule storage and/or sending an
automatic email.
Where it's located: You access the dashboard from the Dashboard entry in the navigation pane. Click Reporting Data
Region and from the drop down list on the right, select Executive Report.
For more information, see Understanding the Other (non-Traffic Overview) Displays.
New Publish Changes Workflow
When you make changes in your Advanced Bot Protection configuration, these changes do not take immediate effect.
Using a special link available in most main displays you can review all the pending changes you have made before you
publish, and you publish them all with a single click.
For more information, see Updating a Configuration.
Biometric Collection Enhancement
New enhancement of user verification that leverages Biometrics Collection added to the Mobile SDK and web
JavaScript. This feature leverages the user’s movement and other attributes, as a way to verify their identity. Since
each individual has their own unique features, this method of authentication adds an additional, highly advanced
layer to Imperva’s detection model.


May 29, 2022 Release

In this release:
• Add policy exception directly from a security event

• New permission for managing custom certificates
• New server status on Website Performance Dashboard
Add policy exception directly from a security event
When a security rule is triggered, you can now add an exception to the WAF Rules policy directly from the Security
Events page, without needing to open and edit the policy itself. This includes the Cross Site Scripting, Illegal Resource
Access, Remote File Inclusion, and SQL Injection rules.
Where it’s located: On the Cloud Security Console Security Events page (Application > Security Events), under
Request Details, click Add exception to policy.
You then have the option to open and edit the policy, or add the exception to the policy in 1-click.
The exception is added only for the specific website in which the rule was triggered.

Within the policy, the exception is labeled Added through the Security Events page.
• View Security Events

New permission for managing custom certificates
The new Manage custom certificates permission enables you to upload, replace, and delete custom certificates for
your websites.
This permission is granted to the Account Admin user by default. The Account Admin or any user with Manage users/
Manage user roles permissions can assign this permission to other account users as needed.
Note:
• Previously, the Modify site settings permission granted users the ability to manage custom certificates. Users
who currently have the Modify site settings permission can continue to manage custom certificates. At a later
date, Imperva will automatically migrate permissions for these users to the new Manage custom certificates
permission. Updates will follow in future release notes.
• For new roles created in your account, use only the new Manage custom certificates permission to assign this
ability.
For more details on configuring custom certificates for your websites, see:
• Web Protection - General Settings

New server status on Website Performance Dashboard
A new server status was added to the Website Performance Dashboard.
For origin servers that are configured according to a CNAME, the new status is displayed when one or more of the
servers using this CNAME are down.

Where it's located: On the Website Performance Dashboard (Application > WAF > Dashboards > Performance) under
Status (Origin DC).
For more details on the dashboard, see Website Performance Dashboard.




In this release:
• Subscribe to the monthly Attack Report

• New rule filter parameter: IP Reputation Risk Level
• Get account user list via the API
• Adding emails for ownership validation
• Heads Up: Deprecation of certificate details from Get Site Status API
Subscribe to the monthly Attack Report
Gain insights into attack trends on your assets and easily share them across your organization.
The Attack Report helps you discover the value of your security solution by providing an overview of attacks on your
websites and web applications, including attack distribution by type, severity, time, source country, source client, and
website. The report covers an extended list of attack types, helping you understand trends based on real attack data.
Data in the report represents activity in the websites in your account and its subaccounts that were most targeted
over the past year.
Availability: We are gradually rolling out the new report to customers over the next several months. It may not yet be
Subscribe: Configure notification recipients to receive a monthly email with the report attached, in PDF format. The
report is available to anyone via email.
• By default, the account admin user and any recipient listed in the Notification Settings Default Executive
Attack Report Notifications policy automatically receive the report.
• You can add additional recipients to the default policy, or configure a new notification policy in Notification
Settings: Account and Website > Executive Attack Report Notifications.
• Attack Report
• Notification Settings
New rule filter parameter: IP Reputation Risk Level
The new IP Reputation Risk Level rule filter parameter was added for configuring custom rules. This parameter
enables you to define an action for Imperva to take based on the Imperva Reputation Intelligence assessment of risk
posed by the source IP address.

The risk assessment is based on activity of an IP across the Imperva customer base over the previous 2 weeks (clean
and malicious traffic). Risk is continually evaluated so the risk level for a given IP can change on a daily basis.
Where it’s located: On the Cloud Security Console Rules page (Application > Websites > <select a website> > Security
> Rules.
For more details on creating rules and configuring this parameter, see:
• Create Rules

Get account user list via the API
An API was added for retrieving the list of users in an account.
The response includes details for each user, including Imperva user ID, first and last name, email address, and the
roles to which the user is assigned.
For details, see Identity Management API Definition.

Adding emails for ownership validation
There is a new method for adding emails used to validate website ownership. When onboarding a site or revalidating
your Imperva certificate, approved emails appear in the drop-down menu on the Activate SSL Support page
(Validate by e-mail).
What changed: The domain's Whois record is no longer used for SSL email validation. Imperva previously pulled
additional emails from the record and automatically added them to the domain's default emails used to authenticate
website ownership.
For details, see Adding Emails for Ownership Validation

Heads Up: Deprecation of certificate details from Get Site Status API
The SSL details of the Get Site Status API (/api/prov/v1/sites/status) have been deprecated and will be removed from
the API response as of October 1, 2022.
You can now retrieve certificate details for your protected websites using the new SSL Certificates API. For details, see
SSL Certificates API Definition.



In this release:
• Advanced API Security Automatic Integration

• View IP reputation data for security events
• Heads Up: End of support for SSLv3 and RC4 cipher
Advanced API Security Automatic Integration
Advanced API Security was enhanced and you can now perform automatic integration of the discovered results with
your existing APIs in order to start monitoring and protecting the discovered APIs quickly.
Where it’s located: On the API Security > Settings tab, under Automatic Integration, select a checkbox next to the
website you want to enable automatic integration for.
When automatic integration is enabled, the discovered endpoints are added to the APIs Inventory table in the My APIs
tab under API Security > Inventory. This ensures that the violations are alerted immediately.
Note: If you enabled the automatic integration feature via the API Schema Protection UI, you have to enable the
feature again as this is now a feature of the Advanced API security Add-on.
For more details, see Settings.

View IP reputation data for security events
Each security event now includes a link from the source IP of the event to the Imperva Reputation Intelligence
service, enabling you to easily view more details on the IPs attacking your sites.
Reputation Intelligence leverages reputation data from across the Imperva customer base and 3rd party providers to
help in incident response.
What changed: The source IP was previously presented as a static number only.
Where it’s located: In the Cloud Security Console Security Events page. (Application > Security Events)
The Source IP of each session links to Reputation Intelligence data on the specific IP address.

• Reputation Intelligence
Heads Up: End of support for SSLv3 and RC4 cipher
As of July 1, 2022, Imperva will no longer support the SSLv3 security protocol and the RC4 cipher.
These older versions have been deprecated across the industry.
To avoid any issues, please prepare for the change accordingly.
For the list of supported TLS versions, see Web Protection - SSL/TLS.
For the list of supported ciphers, see Supported Cipher Suites.



May 1, 2022 Release

In this release:
• Introducing Virtual Waiting Rooms

• Online Fraud Prevention
• Limit user to API use only
• TLS Configuration API
• Bot Access Control Configuration API
• DDoS Protection for Networks: Change of automatic revert duration for On-Demand customers
Introducing Virtual Waiting Rooms
Control the traffic to your website when the origin server is unable to handle the load, while providing a seamless
experience to your customers.
The solution routes your website visitors to a virtual waiting room when their requests can't be handled immediately.
Visitors are placed in a virtual queue, creating a positive user experience and preventing loss of business.

Feature highlights:
• Set activation thresholds based on the incoming rate of traffic and/or total active users.
• Create custom rules to define with more granular control when to activate a waiting room.
• Customize the waiting room page that is displayed to your customers by adding your company logo, banner,
colors, images, videos, and so on. This enables you to keep your brand recognition, as well as engage visitors
with content that promotes your brand while they wait.
• The waiting room page reports the customer’s position in line, providing an indication of when their turn to
access your website will arrive. This information is regularly updated while they wait. At a later date, we will add
the estimated wait time to the page.
• Track waiting room statistics on the Website Performance Dashboard.
Availability:

• As of this release we are starting a gradual rollout of the new add-on to our customers. In the first stage, the
service is enabled upon request.
• Waiting Rooms are available as an add-on to the Cloud WAF service. Once enabled, you can configure 1 waiting
room in your account. Licenses for additional waiting rooms are available for purchase.
• To get started, submit a request to Imperva Support.
For full details on the new service, see Waiting Rooms.

Online Fraud Prevention
Imperva Online Fraud Prevention protects your customers and their data from automated and client-side attacks,
reducing the motivation for attackers to target your websites.
Traditional solutions detect and reconcile fraud after it has taken place. Imperva’s OFP solutions can make the
difference between fixing the damage after the fact, or stopping fraud before it occurs.
Imperva OFP consist of 3 products: Advanced Bot Protection, Account Takeover Protection, and Client-Side Protection.
In this release, we introduce the following enhancements to those products to support OFP.
Note: The OFP products are available as individual add-ons or as part of the App Protect Enterprise bundle. Contact
your Imperva Sales Representative for details.
Advanced Bot Protection
ABP identifies API endpoints to ease the onboarding process
ABP now presents a list of the endpoints in your websites that have API calls in them, enabling you to configure
appropriate per-Path Policies for them.
For more information, see Configuring per-Path Policies for Endpoints with API Calls.
New Conditions that enhance out-of-the-box allowlisting are available
There are two new Conditions that are active in the allow Directive of the Default Policy:
• Financial Data Aggregators: Identifies requests that come from one of the data aggregator IP ranges attributed
to ASNs owned by financial/fintech organizations.
• Monitoring Tools: Identifies requests that come from a known monitoring tool, either: Host Tracker, New Relic,
Pingdom, or Uptime Robot.
For more information, see Inserting a Condition into a Directive.
New Advanced Bot Protection Captcha Report
A new report is available that enables you to better understand your Captcha mitigation, showing how many bots vs
humans are being served Captchas, and how many are solving or failing them.
For more information, see Understanding the Dashboard.

Account Takeover Protection
Zero-day leaked credential detection
Gain visibility into user credentials logging in to your website that have been used by known attackers and are likely
publicly leaked.
Imperva Research Labs analyze Account Takeover Protection data on credential stuffing attacks across our customer
base to determine which other credentials may be connected to an identified attacker, and therefore likely to also be
at risk.
For more information, see Users at Risk.
Financial aggregator support and detection
View login requests that were classified as coming from known aggregators. Use the data for your own security
investigation.
Aggregators can generate many logins from the same IP address, which can be perceived as an attack. Account
Takeover Protection identifies aggregators, distinguishing them from attackers, and thereby reduces false positives.
For more information, see Explore the Data.
User behavior anomaly detection
Behaviors that deviate from what is considered standard and reasonable login activity can be an indication of fraud.
Account Takeover Protection tracks login patterns to detect anomalies, and presents you with that information.
For more information, see Explore the Data.
Client-Side Protection
Terraform support
Use Terraform to onboard and configure Client-Side Protection. Programmatically configure Client-Side Protection
instead of using the Cloud Security Console.
For details, see https://registry.terraform.io/providers/imperva/incapsula/latest/docs/resources/

resource_csp_site_configuration.
Limit user to API use only
Define a user with permissions to use only the API. This user cannot log in to the Cloud Security Console.
This can be useful when creating users that only require access to the API, such as for automation processes.
What changed: The Set as API-only user option was added to User Settings. The account admin or anyone with the
Manage users permission can set this option.
Where it’s located: In the Cloud Security Console:

2. On the sidebar, click User Management > Users.
3. Click a user row to open the user settings.
4. Under Actions, click Set as API-only user.
Note:
• When this option is enabled for a user, the label API Only is displayed next to the user name.
• To remove the API-only limitation, click the Remove API-only restriction option under Actions.
• You cannot set this option for an external user in your account (a user that was created in a different account
and then added to your account). Example: A user is created in Account A, and then added to Account B. You can
set the user as API-only in Account A, but not in Account B.
• The API-only access is managed for the user at the parent account level. Therefore, the user cannot access any
other accounts or their subaccounts via login to the Cloud Security Console.
For details on managing users, see Account Users.

TLS Configuration API
You can now configure HSTS support for your websites using the Imperva TLS Configuration API.
HTTP Strict transport security (HSTS) ensures that any attempt by visitors to use the unsecure version (http://) of a
page will be forwarded automatically to the secure version (https://). HSTS support is available only for sites that have
SSL support. For more details on HSTS support, see Web Protection - General Settings.
What changed: The following APIs were added:
• GET /api/prov/v3/sites/{extSiteId}/settings/TLSConfiguration
• POST /api/prov/v3/sites/{extSiteId}/settings/TLSConfiguration
For details on using the new APIs, see Cloud Application Security API Definition under Site Management.
Bot Access Control Configuration API
Retrieve and update the bot configuration for your websites using the Imperva API. The new endpoints correspond to
the settings configured on the Web Protection - Security Settings page in the Cloud Security Console.
The Bot Access Control configuration reflects the manual changes performed by a user in your account. It includes:
• Canceled good bots: Bots that are removed from the default “Good bots list”. These bots can no longer access
your website by default and must pass additional challenges.
• Bad bots: Bots that are added to the default list of blocked bots.
What changed: The following APIs were added:

• GET /api/prov/v3/sites/{extSiteId}/settings/botConfiguration: Retrieve the Bot Access Control configuration for a

given website.
• POST /api/prov/v3/sites/{extSiteId}/settings/botConfiguration: Update the Bot Access Control configuration for

a given website.
For details on using the new APIs, see Cloud Application Security API Definition under Site Management.
DDoS Protection for Networks: Change of automatic revert duration for
On-Demand customers
If you are using Imperva’s Network Protection service in on–demand mode, and if your traffic diversion is controlled
by Imperva when under attack (automatically or after your confirmation), your traffic is reverted back to you
automatically after 12 hours with no malicious activity.
What changed: We are extending this period to 48 hours. This extended period enables you to coordinate the revert
time with your off hours or with another convenient time prior to the automatic 48 hour operation.
If you would like the traffic reverted back to you earlier than 48 hours, contact Imperva Support to submit your
request.

April 24, 2022 Release

In this release:
• Website Troubleshooting API

Website Troubleshooting API
Retrieve connectivity test results for your websites using the Imperva API. This information can help you troubleshoot
connectivity issues that occur when Imperva data centers cannot reach your origin web servers.
For details, see Troubleshooting API Definition.
For details on troubleshooting in the Cloud Security Console, see Troubleshoot Website Errors.


In this release:
• HTTP/2 support functionality

• Change in existing custom rules
HTTP/2 support functionality
Imperva delivery settings allow you to enable HTTP/2 support for traffic between supporting end-user (visitor)
browsers and Imperva. For details, see the Enable HTTP/2 option in Delivery Settings.
It is possible that a browser requesting resources from multiple sites or apps, all of which use a common root domain
and resolve to the same Imperva IP, will automatically use the same connection during the session. Depending on the
client, if any connection is opened to a website with HTTP/2 support enabled in the Cloud Security Console delivery
settings, all additional requests sent to sub-domains or the naked domain will continue to use HTTP/2, even if their
HTTP/2 setting is disabled.
Using HTTP/2 in most cases, even when disabled for the specific site, is not problematic. If, however, your website is
experiencing any issues, please contact Imperva Support for assistance.
Example:
You have 2 sites configured in the Cloud Security Console. Both sites point to the same IP address. The Enable
HTTP/2 setting is turned on for www.example.com. The setting is turned off for api.example.com. When the browser
opens an HTTP/2 connection to www.example.com, it will use the same HTTP/2 connection that was already
established to send a request to api.example.com.
Change in existing custom rules
Over the next several weeks, custom rules that include only the IP List filter parameter configured to detect
anonymous proxy IP addresses or a Tor exit node will be converted to the Malicious IP List filter parameter. No impact
to current rule behavior is expected.
Note:
• Rules in which the IP List parameter is present but set to other values will not be changed.
• To avoid the risk of impacting current rule functionality, we will not convert a custom rule that includes other
parameters in addition to the IP List parameter.
Why the change? The IP List parameter is configurable only by Support. One of the reasons it is used is to define an
action for Imperva to take if the source IP of the request is identified as an anonymous proxy IP or Tor exit node.
After Support added the custom rule (per customer request), you could view it in the UI, but not edit it.

With the recent introduction of the Malicious IP List parameter which serves the same function, we will convert your
existing rule so that you can configure and edit it yourself.
The rules appear as follows:
Before After
IPList == 1;16 (for Tor IPs) MaliciousIPList == TorIPs
IPList == 1;3;14;16 (for anonymous proxy IPs) MaliciousIPList == AnonymousProxyIPs
For example:
Before:
After:
Where it’s located: On the Cloud Security Console Rules page.
For more details on custom rules: see:
• Manage Rules



In this release:
• Visibility into all certificates used for your websites

Visibility into all certificates used for your websites
View details of all SSL certificates configured in Imperva for your websites in one location without needing to go into
each individual website.
What’s changed: The SSL Certificates page was added, displaying certificate and status details for all websites in the
account. In addition, details of any domain requiring ownership validation are listed, including instructions for
completing the validation.
Availability: In this release, we start rolling out the new page. It may not yet be available in your account. We expect
to complete rollout to all accounts by the end of May.
Where it’s located: In the Cloud Security Console, navigate to Application > WAF > SSL Certificates.
For details, see View SSL Certificates.
You can also access the certificate and status details using the API. For details, see SSL Certificates API Definition.



In this release:
• WAF settings migration to Policy Management

• Near Real-Time SIEM log integration updates
• Homepage: View ACL violations
WAF settings migration to Policy Management
In this release, we start migrating WAF settings to the new WAF Rules policy for existing customers. We expect to
complete migration of all accounts over the next several months. (Migration of WAF settings for a single account is
completed in just a few minutes.)
Policy Management enables you to define a set of policies to apply to multiple sites instead of replicating the same
policy over and over.
The new WAF Rules policy type lets you to easily manage your mitigation settings for website WAF rules in a central
policy, while still benefiting from the default out-of-the-box policies.
No downtime is expected during migration, and no action is required on your part. Imperva runs an automated
migration process that moves all of your existing WAF settings into the new WAF Rules policies.
What’s changing: The following WAF settings are currently available on the Website WAF Settings page under each
website’s configuration. After migration, they are managed using the WAF Rules policy via the UI and API.
• Cross Site Scripting (XSS)
• Illegal Resource Access
• Remote File Inclusion
• SQL Injection
The Backdoor Protection rule continues to be defined at the website level on the WAF Settings page and will be
migrated at a later date.
Where it’s located: Policies are managed on the Cloud Security Console’s Policies page.
2. On the sidebar, click WAF > WAF Policies.

API: Once your account is migrated, you can no longer use the following APIs to configure WAF settings and
exceptions:
• /api/v1/sites/{SiteId}/settings/rules/SQL_INJECTION/exception
• /api/v1/sites/{SiteId}/settings/rules/CROSS_SITE_SCRIPTING/exception
• /api/v1/sites/{SiteId}/settings/rules/ILLEGAL_RESOURCE_ACCESS/exception
• /api/v1/sites/{SiteId}/Settings/rules/REMOTE_FILE_INCLUSION/exception
Instead, use the Policies API to configure WAF Rules. For details, see Policy Management API Definition.
Note: Once the migration process is complete for all customers, the old (existing) WAF settings will be removed from
the application, and the APIs listed above will be decommissioned.

Near Real-Time SIEM log integration updates
Notification of S3 unavailability
If your SIEM storage repository becomes unavailable, Imperva will be unable to upload the log files.
When this happens, you will be notified by email, according to your notification settings. (Make sure that SIEM storage
notifications are configured for your account. For details, see Notification Settings.)
For more details on SIEM storage unavailability, see Configure the SIEM Log Integration.
Create multiple connections
The Near Real-Time SIEM log integration now supports connections to multiple cloud storage repositories.
What changed: Previously, when configuring the log integration to send security logs to your cloud storage
repository, you could create only a single connection. Now you can create multiple connections, enabling you to send
logs for different Imperva services to different storage locations.
Availability: The Log Configuration page is currently available to customers who are using the Near Real-Time SIEM
log integration for the DDoS Protection for Networks and IPs service, or for Advanced Bot Protection.

• Configure the SIEM Log Integration

Homepage: View ACL violations
The number of requests blocked due to ACL policy violations is now displayed on the account dashboard. This
includes requests blocked by country, IP address, or URL according to your ACL policy settings.
Where it’s located: On the Home page, displayed when you log in to the Cloud Security Console, view ACL Policies in
the Security events graph.


March 27, 2022 Release

In this release:
• Fixed: BGP Monitoring status added to Audit Trail

• Heads up: Deprecation of WAF settings API
Fixed: BGP Monitoring status added to Audit Trail
The issue applies to customers subscribed to the DDoS Protection for Networks service.
Problem: The BGP Monitoring status was not previously included in the Connection added or Connection changed
audit events.
Resolution: The issue is fixed. BGP Peer Monitoring status is now included in the relevant audit events.
Heads up: Deprecation of WAF settings API
As of August 1, 2022, following the migration of WAF settings for all customer accounts to the new WAF Rules policy,
the old WAF setting APIs will be deprecated.
What changed: Once your account is migrated, you can no longer use the following APIs to configure WAF settings
and exceptions:
In addition, details of the WAF settings and exceptions will be removed from the following Site Management APIs:
• Get site status
• All other Site Management APIs that return details of the site’s WAF settings configuration

For more details on the migration of WAF settings to the WAF Rules policy see the February 20, 2022 release notes.


In this release:
• DDoS Protection for Networks: Self-adaptive DDoS detection policies

• New API for uploading custom certificates
• Old email notification list removal
DDoS Protection for Networks: Self-adaptive DDoS detection policies
In 2021, we introduced self-adaptive DDoS security policies, as described in the release notes.
As of this release, rollout of self-adaptive policies for both detection and security is now complete for all DDoS
Protection for Networks customers.
These policies are automatically generated and updated based on our machine-learning algorithm that continuously
analyzes the assets’ (networks, IPs) traffic rates and patterns.
The automated policies can adapt more quickly and accurately than policies relying on manual configuration, as the
policy is continuously aligned with the current traffic behavior.
New API for uploading custom certificates
Imperva’s v2 API now supports the upload of custom certificates for your protected websites. Imperva’s v2 API better
aligns with REST API standards and best practices.
For details on the new endpoints for custom certificates, see Cloud WAF v2 API Definition.
The custom certificate endpoints support upload of RSA certificates, as well as ECC certificates, a recently added
capability. For more details, see ECC Certificate Support.
Old email notification list removal
The E-mail for notifications option on the Account Settings page is no longer displayed in accounts in which the new
Notification Settings feature is enabled. This option was previously used for defining notification recipients.

For reseller accounts, the email option is located in the Account Settings > Preferences page:
The new Notification Settings feature introduced earlier this year provides you with more granular control over
which notifications you receive, and the list of recipients who receive them. The new page is currently being rolled out
and may not yet be available in your account.
For details, see Notification Settings.



In this release:
• ECC certificate support

ECC certificate support
In addition to RSA certificates, Imperva Cloud WAF now supports ECC certificates.
You can upload your own ECC certificate to Imperva so it can be presented to your website visitors.
Benefits:
• ECC certificates have a smaller key size than RSA certificates, so less data is passed to the client during the TLS
handshake. This results in faster page load times, as well as offering better support for mobile devices.
• ECC certificates provide a security level comparable to or surpassing that of an RSA 2048 certificate.
By default, Imperva supports the prime256v1 (secp256r1) Elliptic Curve Digital Signature Algorithm (ECDSA) only.
1. In the Cloud Security Console, navigate to Application > Websites > <your site> > Website Settings > General.
2. Under SSL Support > ECC Custom Certificate, click Configure and follow the onscreen instructions.
For more details, see ECC Certificate Support.




In this release:
• Log Setup renamed

• Heads up: Old email notification list removal
Log Setup renamed
For improved clarity, the Logs Setup menu item and page have been renamed WAF Log Setup.
Heads up: Old email notification list removal

On March 20, 2022, the E-mail for notifications option on the Account Settings page will no longer be displayed in
accounts in which the new Notification Settings feature is enabled. This option was previously used for defining
notification recipients.
For reseller accounts, the email option is located in the Account Settings > Preferences page:

The new Notification Settings feature introduced earlier this year provides you with more granular control over
which notifications you receive, and the list of recipients who receive them. The new page is currently being rolled out
and may not yet be available in your account.
For details, see Notification Settings.


February 27, 2022 Release

In this release:
• API Security
• Notification Settings update
• DDoS Protection for Networks/IPs: Account Asset API
API Security
API Security is now available under the account-level on the Cloud Security Console as an add-on to the CloudWAF.
The API Security feature under the website-level has been renamed API Schema Protection and still exists as a built-
in feature of the CloudWAF. It will continue to be supported for customers who want to validate API calls using their
own well defined API Specifications. In addition, CloudWAF will continue to support automatic generation of API
endpoints as a baseline.
The API Security add-on is purpose-built to address application specific threats against custom APIs. It is not
uncommon for APIs in production to deviate from API specifications due to the lack of API documentation or frequent
changes. There are also categories of data exfiltration attacks leveraging schema conforming API calls that cannot be
detected by API Schema Protection. The key first step to protect applications against these new categories of threats is
to discover the APIs, to discover their structure in order to differentiate from API endpoint detection, and to identify
sensitive information that is being transferred using the APIs.
The initial release of the API Security add-on provides a comprehensive, data driven API Discovery, which enables you
to:
• Understand your API exposure surface with complete and up to date inventory of your APIs and their
configuration.
• Protect your APIs with a positive security model even if you don’t have an OAS file. With an ongoing learning
mechanism, API Discovery constantly learns the structure of the APIs whenever they are updated.
• Gain tighter protection of your APIs on top of the existing OAS files provided by the development teams.
• Decide on the appropriate security level for each API endpoint according to the sensitivity of the data returned
by it.
• Download a specifications file of the discovered endpoints.
• Identify contextually sensitive data.
• Use analytics and display Data Classification so that you can know which API endpoint transfers PII and other
sensitive information.

Additional capabilities
• Integrates with API management platforms through designated APIs and open source tools, making security an
integral part of API lifecycle management.
• Automatically disables Captcha cookie challenges and JavaScript challenges on API traffic.
• Leverages the SaaS infrastructure and the CDN, WAF, BOT and DDoS capabilities of the Imperva Application
Security suite, and uses the same management portal.
For more details, see Imperva API Security.

Notification Settings update
The new Notification Settings feature introduced earlier this year provides you with more granular control over which
notifications you receive, and the list of recipients who receive them.
What changed: The following changes are introduced in this release:
• Next phase of migration: We are starting to rollout the new Notification Settings to partners and reseller
accounts, as well as their customer accounts. The new settings replace the former email notification options in
Account Settings. The migration of all accounts is expected to be completed within several weeks.
• Get notified about activity in your subaccounts: For accounts with subaccounts, you can now also create
policies to receive notifications about activity in your subaccounts. The new functionality is available via the UI
and the API in accounts that have been moved over to the new Notification Settings mechanism.
For reseller accounts, your existing Account E-mail Settings that determine if you receive notifications on
activity in your subaccounts will be automatically moved over to the Notification Settings page. They will be
listed as Subaccount Default Notifications.
Where it’s located: On the Notification Settings page, you can view default notification settings and create new
notification policies. In the Cloud Security Console, navigate to Account > Account Management > Notification
Settings.
For more details, see Notification Settings.

DDoS Protection for Networks/IPs: Account Asset API
An API was added to enable you to easily retrieve a list of the protected network ranges and IPs defined for your
account. This list can be useful for using in other API calls.
For details, see Asset Management API Definition.




In this release:
• Heads Up: WAF settings migration to Policy Management

• SIEM log change for user agent
New Features
None.
Enhancements
Heads Up: WAF settings migration to Policy Management
Website WAF rule settings are moving to our Policy Management feature.
Policy Management enables you to define a set of policies to apply to multiple sites instead of replicating the same
policy over and over.
The new WAF Rules policy type enables you to easily manage your mitigation settings for website WAF rules in a
central policy, while still benefiting from the default out-of-the-box policies.
Migration to policies: Starting in March 2022, WAF settings for customer accounts will be migrated to the new WAF
Rules policy over the course of several months. (Migration of a WAF settings for a single account is completed in just a
few minutes.)
No downtime is expected during migration, and no action is required on your part. Imperva runs an automated
migration process that moves of all your existing WAF settings into the new WAF Rules policies.
What’s changing: The following WAF settings are currently available on the Website WAF Settings page under each
website’s configuration. After migration, they will be managed using the WAF Rules policy via the UI and API.
• Cross Site Scripting (XSS)
• SQL Injection
The Backdoor Protection rule continues to be defined at the website level on the WAF Settings page and will be
migrated at a later date.

Where it’s located: Policies are managed on the Cloud Security Console’s Policies page.
Note: Once the migration process is complete for all customers, the old (existing) WAF settings will be removed from
the application.
Security Mitigation
Fixes
SIEM log change for user agent
SIEM logs now report the value of the user agent field for each request instead of according to the session as a whole.
Previously, the user agent reported for each request on a session was based on the first request in the session.
For more details on SIEM log files for the Imperva Cloud WAF log integration, see Log File Structure.
Known Issues
None.



In this release:
• New Imperva Data Center in Bogota, Columbia

• Website dashboard enhancements
• Cloud Security Console menu change
• Enhanced security of role-based access policy
• Certificate renewal process change
• Heads Up: SIEM log change for user agent
New Features
None.
Enhancements
New Imperva Data Center in Bogota, Columbia
We are starting to roll out a new data center (PoP) in Bogota, Columbia and expect it to be fully functional within the
next few weeks.
The Bogota PoP is the newest addition to our world-wide network of 47 data centers, helping you deliver your
Website dashboard enhancements
Real-Time Dashboard: The following sections were added:
• Imperva data centers: Real-time data according to the Imperva data centers handling the requests.
• Origin servers: Real-time data on your origin servers. Select multiple servers to view and compare
simultaneously.
Performance Dashboard: Design enhancements include:
• Changes to layout, coloring, and graph types
• New options for expanding each graph for an enlarged view or saving the graph as an image file
• The DC status and Origin status columns were temporarily removed from the All websites table while we
reevaluate these statistics

Where it’s located: In the Cloud Security Console, navigate to Application > WAF > Dashboards.
For more details, see Website Dashboards.

Cloud Security Console menu change
To align with Imperva’s offering categories (Application, Network, Data), the Edge menu item in the Cloud Security
Console was changed to Network.
Enhanced security of role-based access policy

For enhanced security, a subaccount user who is not assigned a role in the parent account can no longer view assets in
the parent account.
What changed: Previously, when a subaccount user logs in to the Cloud Security Console, they can view assets in the
parent account by entering the Application, Network, or Data areas. These menu items are no longer visible until the
user enters a subaccount in which they have an assigned role.
To allow a subaccount user to access the parent account, the user must be assigned an appropriate role in the parent
account. This can be done by the account admin, or by any user who has the Manage users and Manage user roles
permissions in the parent account. For more details, see Manage Roles and Permissions.
Certificate renewal process change
There has been a minor change in the certificate renewal process.
If an Imperva-generated certificate for your website includes unverified SANS, they will be removed from the new
certificate and the old certificate will be replaced 72 hours before the actual expiry date. Previously, the change was
made 24 hours before the expiry date.
If you did not verify all SANs and they were removed from the new certificate, this time extension allows Imperva to
republish the previous certificate that has not yet expired. This provides you with a last opportunity to verify all
required SANs before the actual expiration date and maintain your SSL support.
Typically, when your site's Imperva-generated certificate needs to be renewed, the process is completed
automatically by Imperva. In some instances, you will receive an email notification from Imperva requiring you to
revalidate ownership of your domain.
It is critical to review the required action and deadline as specified in the email, and take prompt action. If your
websites are not revalidated before the deadline, SSL support will be removed and the sites will be unreachable over
SSL.

Security Mitigation
Fixes
Heads Up: SIEM log change for user agent
The following change is scheduled to roll out during the week of February 20th, 2022.
SIEM logs will now report the value of the user agent field for each request instead of according to the session as a
whole.
Previously, the user agent reported for each request on a session was based on the first request in the session.
For more details on SIEM log files for the Imperva Cloud WAF log integration, see Log File Structure.
Known Issues
None.


In this release:
• Near Real-Time SIEM log configuration updates

• New option for uploading a custom certificate
• Audit events added for Imperva support actions
• Website settings display active custom error page
• Heads Up: Enhanced security of role-based access policy
• Heads Up: Certificate renewal process change
• Custom error pages not displayed
New Features
None.
Enhancements
Near Real-Time SIEM log configuration updates
A new page was added to the Cloud Security Console for configuring the new Near Real-Time SIEM log integration for
your account.
Availability: The Log Configuration page is now available to customers who are using the Near Real-Time SIEM log
integration for the DDoS Protection for Networks and IPs service, or for Advanced Bot Protection. You can now
view and modify the log configuration for your account.
Where it’s located: To open the Log Configuration page:
For details, see Configure the SIEM Log Integration.
DDoS Protection for Networks and IPs and Advanced Bot Protection customers: Interested in the new Near Real-
Time SIEM log integration? The integration is currently offered as an Early Availability feature. To enable the feature
for your account during this period, contact Imperva Support.
Cloud WAF customers:
• Customers who are using the legacy SIEM log integration with the S3 push method can contact Imperva Support
to request migration to the new mechanism.

• In early 2022, we will migrate all customer accounts that are currently using the Imperva SIEM log integration
with the S3 push method to the new Near Real-Time SIEM mechanism.
• At a later stage, the new mechanism will be available to new and existing customers who start using the SIEM
log integration with the S3 push method.
For more information, see Near Real-Time SIEM Log Integration.

New option for uploading a custom certificate
Upload a custom certificate for your website that is already in use for another website in your account, without
needing to upload the private key again.
This is especially useful when the existing certificate was generated using a CSR and you want to use it for multiple
websites in your account.
Note: This applies to websites directly under the same parent account, or websites in the same subaccount.
In the Cloud Security Console:
1. Navigate to Application > Websites > <your site> > Website Settings > General.
2. Under SSL Support > Custom certificate, click Configure.
3. Follow the onscreen instructions to upload your certificate without uploading the private key.
For more details, see Upload a Custom Certificate for Your Website on Imperva.
You can also configure the certificate to be used for multiple websites in your account using the /api/prov/v1/sites/
customCertificate/csr API. The domain parameter enables you to define the common name, which can be a wildcard
domain to cover multiple domains. For more details, see Create New CSR in the Site Management section of Cloud
Application Security v1/v3 API Definition.
Audit events added for Imperva support actions
The Imperva team has the ability to assume the identity of a specific end-user in a customer account for investigation
and troubleshooting purposes.
This enables Imperva Support, for example, to view the account from the customer perspective, or to perform pre-
approved actions on the customer’s behalf.
What changed: When an Imperva employee assumes the identity of a user in your account, the following events are
logged in the Audit Trail:
• Logged in as customer account user
• Logged out of customer account user
These audit trail entries indicate the account user whose identity was temporarily taken on. For example: “Imperva
Support logged in as account user user@demo.com”.

In addition, all actions performed by Imperva Support while logged in as a user of your account are also recorded in
the Audit Trail. For example: “API key created. Performed by Imperva Support logged in as user@demo.com”.
Where it’s located: In the Cloud Security Console’s Audit Trail page.
2. On the sidebar, click Account Management > Audit Trail.
For more details on Audit Trail, see the Audit Trail Documentation.
Website settings display active custom error page
Custom error pages can be defined at the website level by account users, or at the account level, by submitting a
request to Imperva Support.
If a custom error page is defined at the account level it is used for all websites in the account that have not defined
their own custom error page.
What changed: When viewing the custom error pages for a website, the UI displayed only the website level
configuration. Now, if there is a custom page defined only at the account level, it is displayed in the website settings,
so you can see the error page that is currently active for the website.
This is based on the logic of how custom error pages are applied. If a “more specific” custom error page is defined, it
overrides more general pages.
For example, if there is a custom error page defined for an Access denied error at the website level, it overrides a
custom error page defined for an Access denied error at the account level, and is presented in the event of an error of
that type. For more details, see Custom Error Pages.
Where it’s located: In the Cloud Security Console, open the Delivery Settings page under Application > Websites >
<your site> > CDN > Delivery and scroll to the Custom Error Page section.

Heads Up: Enhanced security of role-based access policy

The following change is scheduled for implementation the week of February 13th, 2022.
For enhanced security, a subaccount user who is not assigned a role in the parent account will no longer be able to
view assets in the parent account.
What’s changing: Currently, when the user logs in to the Cloud Security Console, they can view assets in the parent
account by entering the Application, Edge, or Data areas. These menu items will no longer be visible until the user
enters a subaccount in which they have an assigned role.
Heads Up: Certificate renewal process change
As of February 2022, there will be a minor change in the certificate renewal process.

SSL.
As of July 1, 2022 Imperva will no longer support the SSLv3 security protocol and the RC4 cipher.
Security Mitigation
Fixes
Custom error pages not displayed
Problem: Custom website error pages are not displaying in some cases.
Resolution: This issue is fixed.
Known Issues
None.

January 30, 2022 Release

In this release:
• WAF Policies: Upload IPs in bulk from a CSV file

• Heads Up: Enhanced security of role-based access policy
• Custom error pages not displayed
New Features
None.
Enhancements
WAF Policies: Upload IPs in bulk from a CSV file
When configuring IP addresses, ranges, or subnets in a WAF policy, you can now add a list of IPs in bulk by uploading a
file in .csv format.
Where it’s located: Bulk upload is available everywhere in the Policies page where IPs are entered.
For more details, see Create and Manage Policies.

Heads Up: Enhanced security of role-based access policy
The following change is scheduled for implementation the week of February 13th, 2022.
For enhanced security, a subaccount user who is not assigned a role in the parent account will no longer be able to
view assets in the parent account.
What’s changing: Currently, when the user logs in to the Cloud Security Console, they can view assets in the parent
account by entering the Application, Edge, or Data areas. These menu items will no longer be visible until the user
enters a subaccount in which they have an assigned role.

SSL.
Security Mitigation
Fixes
None.
Known Issues
Custom error pages not displayed
Problem: Custom website error pages are not displaying in some cases.
Solution: This issue is expected to be resolved shortly. An update will follow in future release notes.
For more details on custom error pages, see Custom Error Pages.



In this release:
• Client-Side Protection: API update

• Attack Analytics: “Exposed origin server” insight fixed
New Features
None.
Enhancements
Client-Side Protection: API update
For enhanced security, the following API endpoints were updated so that sensitive information is sent only in the
POST body, instead of in the URL as query parameters.
Before After
PUT /v1/sites/{siteId}/settings/emails/{email} POST /v1/sites/{siteId}/settings/emails/add
DELETE /v1/sites/{siteId}/settings/emails/{email} POST /v1/sites/{siteId}/settings/emails/delete
These endpoints enable you to manage the list of users who receive email notifications for your protected websites.
For more information, see Client-Side Protection API.


SSL.
Security Mitigation
Fixes
Attack Analytics: “Exposed origin server” insight fixed
An issue with the Attack Analytics "exposed origin server" insight was detected, and the insight was temporarily
disabled during our investigation.
The issue is now fixed and the insight has been re-enabled.
Known Issues
None.


In this release:
• New rule filter parameter: Malicious IP List

• Attack Analytics: “Exposed origin server” insight temporarily disabled
New Features
None.
Enhancements
New rule filter parameter: Malicious IP List
The new Malicious IP List rule filter parameter is now available when configuring custom rules. The parameter
enables you to define an action for Imperva to take if the source IP of the request is identified as an anonymous proxy
IP or Tor exit node.
For details, see Rule Filter Parameters.

SSL.
Fixes
None.

Known Issues
Attack Analytics: “Exposed origin server” insight temporarily disabled
We have detected an issue with the Attack Analytics "exposed origin server" insight and have temporarily disabled
this insight while we investigate.
Actionable insights are recommended actions for you to take, based on attacks that have targeted your sites and
applications. For more information, see Actionable Insights.


In this release:
• Introducing Website Troubleshooting

• Enhanced sidebar navigation
• Certificate Management: API for updating a CRL
• DNS Protection minor UI and API enhancements
New Features
Introducing Website Troubleshooting
A new Troubleshooting page provides greater visibility into connectivity issues that occur when Imperva proxies
cannot reach your origin server.
The new page is intended to help you troubleshoot the following errors:
• Error code 20: The Imperva proxy failed to connect to your web server, due to a TCP connection timeout.
• Error code 8: The Imperva proxy failed to connect to your web server, due to a TCP connection rejection (TCP
reset).
When one of these errors occurs, Imperva automatically runs connectivity tests (Ping, MTR, and MTR over TCP) and
displays the results on the Troubleshooting page.
Benefits:
• Access additional details to determine the root cause of the issue.
• Quickly determine if the connectivity issue is on the origin server side and proceed to resolve it.
Availability: We are starting to gradually roll out this new feature. It may not be immediately available in your
account.
Where it’s located: In the Cloud Security Console, navigate to Application > Troubleshooting. Expand a row to view
the test results.

• Troubleshoot Website Errors
• Cloud WAF Error Pages and Codes
• How to Troubleshoot error codes 20 and 8
Enhancements
Enhanced sidebar navigation
You can now easily collapse the side navigation panel in the Cloud Security Console to maximize the work area on the
screen.

When the sidebar is collapsed, menu options are displayed on hover to enable you to quickly access the page you
want.

To enable this functionality, some sidebar options in Website Management were changed and moved into a
hierarchical structure:
• Website Overview was renamed Dashboards.
• The new Origin and Network category includes the General, Monitoring, and Client CA Certificates pages.
• The new Security category includes the Policies and Rules pages.
• The new CDN category includes Delivery and Cache pages.
Menu options in Account Management and Data pages were also placed in collapsible sections:


Certificate Management: API for updating a CRL

An API enabling you to replace a Certificate Revocation List (CRL) file currently uploaded for your website was added.
If client certificate support is enabled for your site, you can upload a CRL file to verify whether certificates are valid
and trustworthy.
What changed: PUT /sites/{siteId}/CRL/{crlId} was added.
For details, see Certificate Manager API Definition.

DNS Protection minor UI and API enhancements
For enhanced simplicity, the following changes were made to the DNS Protection service.
DNS Protection API
Management of DNS domains configured for Imperva DNS Protection and their DNS records were separated.
• DNS record details and configuration were removed from all of the /domain endpoints and instead are managed
using the /domain/{domainId}/records endpoint only.
• A PUT method was added for editing the existing DNS record configuration for a domain.
For details, see DNS Protection API Definition.
Protected DNS Zones page
The Origin NS Records column was removed. This information applies to zones configured for Imperva Proxy DNS
and is visible when viewing or editing the specific zone’s configuration.


SSL.
Security Mitigation
Fixes
None.
Known Issues


In this release:
• Mobile App update

• Client-Side Protection updates
• Heads Up: DNS Protection minor UI and API enhancements
New Features
None.
Enhancements
Mobile App update
A new version of the Imperva Security Mobile App is now available.
Enhancements include:
• Security hardening
• The minimum Android version required is now 8
• General fixes
The new version is available via the Apple App Store and the Google Play App Store.
For more details on the mobile app, see Imperva Security Mobile App.
Client-Side Protection updates
The following enhancements were added to Client-Side Protection:
Direct IP communication
View IP addresses that are receiving data directly from your website.
If your site or application is communicating directly with specific IP addresses, it is likely to indicate malicious activity.
Therefore, communication to these IP addresses is automatically blocked when Client-Side Protection is in Enforce
mode. While in Monitor mode, this communication is allowed.
When direct IP communication is detected, you can see it listed on the Dashboard. You can then click for more details,
and view the list of IP addresses, as well as the web pages that are making the requests.

Domain categories
Quickly understand the purpose of the domains discovered by Client-Side Protection.
Services are categorized according to their purpose or industry, and listed in the Client-Side Protection dashboard
under the service name.

Heads Up: DNS Protection minor UI and API enhancements
For enhanced simplicity, the following changes are planned for early January 2022.
DNS Protection API
Management of DNS domains configured for Imperva DNS Protection and their DNS records will be separated.
• DNS record details and configuration will be removed from all of the /domain endpoints and instead be
managed using the /domain/{domainId}/records endpoint only.
• A PUT method will be added for editing the existing DNS record configuration for a domain.
For details on the current DNS Protection API, see DNS Protection API Definition.
The Origin NS Records column will be removed. This information applies to zones configured for Imperva Proxy DNS

Security Mitigation
Fixes
None.
Known Issues


December 12, 2021 Release

In this release:
• Heads Up: DNS Protection minor UI and API enhancements

• Heads Up: Migration to Near Real-Time SIEM integration
New Features
None.
Enhancements
Heads Up: DNS Protection minor UI and API enhancements
For enhanced simplicity, the following changes are planned for early January 2022.
DNS Protection API
Management of DNS domains configured for Imperva DNS Protection and their DNS records will be separated.
• DNS record details and configuration will be removed from all of the /domain endpoints and instead be
managed using the /domain/{domainId}/records endpoint only.
• A PUT method will be added for editing the existing DNS record configuration for a domain.
For details on the current DNS Protection API, see DNS Protection API Definition.
The Origin NS Records column will be removed. This information applies zones configured for Imperva Proxy DNS

Heads Up: Migration to Near Real-Time SIEM integration

In January 2022 we will start to automatically migrate customer accounts to our new Near Real-Time SIEM
integration.
Our existing log integration enables you to receive your Imperva logs and archive or push these events into your SIEM
solution.
The new mechanism introduces a dramatic reduction in the time it takes to deliver logs to you after the security event
occurs.
Availability:
• During December 2021, customers who are currently using the SIEM log integration with the S3 push method
can contact Imperva Support to request migration to the new mechanism.
• In Q1 of 2022, we will migrate all customer accounts that are currently using the Imperva SIEM log integration
with the S3 push method.
Note:
• There are no configuration changes required on your part.
• Additional IP addresses that are used for the new SIEM mechanism were recently added to the Imperva IP
address list.
18.197.138.101/32
52.28.122.247/32
18.196.8.244/32
34.195.164.78/32
34.227.199.200/32

35.168.228.214/32
54.178.125.129/32
13.114.18.213/32
13.115.55.10/32
54.153.205.221/32
13.239.174.189/32
13.236.96.83/32
To prepare for migration, verify that you have all Imperva IP addresses included in your allowlist. Note that the
IPs supporting the Near Real-Time SIEM integration are not returned by the API that retrieves the Imperva
ranges, as they are not required by all Cloud WAF customers. For details, see Allowlist Imperva IP addresses &
Setting IP restriction rules.
Note that during the migration process, there will be a short period in which logs will be sent from both the old
and new systems.
What to expect after your account is migrated to the Near Real-Time SIEM integration:
As a first step, the new mechanism has been implemented for:
• Amazon S3 push method only, in which logs are pushed to your S3 bucket.
• Security event logs only, which include suspicious events detected by Imperva. Access logs will be added at a
later date.
Current platform New SIEM platform

Smaller files sent every 10-70
Sending rate Large files sent every 5-10 minutes
seconds
File arrives within 10-30 minutes File arrives within 3-5 minutes of
Data freshness
or more of the event the event
One log file with both security and

access events
One log file with security events
File contents These files will continue to be in
only
use after your account is migrated
to the new mechanism. They will
contain only access events.
Log file names <config_id>_<uuid>.log <account_id>.WAF_RAW_LOGS.<uuid>.log

51226475.WAF_RAW_LOGS.7f108651-1258-4177-
Example 44268_b8e36106-2e39-4eaa-88ab-90ff8b7542e6.log
a3dd-c9f6bb4dccfa.log

Note: In the event that you change your connection details in the Logs Setup, it can take up to 3 hours for the
configuration changes to take effect.
Security Mitigation
Fixes
None.
Known Issues



In this release:
• DDoS Protection for Networks/IPs Updates

• Mobile App: Attack Analytics Actionable Insights
• Homepage dashboard update
• Advanced Bot Protection: Role-Based Access Control (RBAC) added
New Features
None.
Enhancements
DDoS Protection for Networks/IPs Updates
Cross connect support for Megaport
You can now establish a direct connection between your infrastructure located in Megaport-enabled facilities and the
Imperva service via a Layer 2 connection.
Availability: Supported in the Imperva data centers in Melbourne and Sydney Australia.
For more details, see Direct Connection.
Performance metrics API
You can now get performance metrics for your DDoS Protection for Networks connections via the Imperva API.
Performance Monitoring metrics provide visibility into the performance of the connections between Imperva data
centers and your origin network. View metrics on latency, jitter, and packet loss to assess the stability of your
connections.
For details on the API, see DDoS Protection for Networks: Performance Monitoring API Definition.
For more information on Imperva Performance Monitoring, see Configure Performance Monitoring.

Flow Monitoring API update
You can now retrieve Flow Exporter details via the API by providing the IP address of your exporter. The exporterIp is
the IP address of your network device that is sending flow data to Imperva.
What changed: Previously, details were available only by providing the Imperva exporter ID.
For more details on the API, see Flow Exporter API Definition.
For more details on Imperva’s Flow Monitoring service, see Flow Monitoring.
View real-time data for sub accounts
View real-time data for a protected network or IP on dashboards in a sub account. See top traffic patterns for DDoS
traffic on your network.
1. In the Cloud Security Console, navigate to Edge > Network Protection > Dashboard or Edge > IP Protection
> Dashboard.
2. In the Ranges or IPs table, click an IP range or a single IP to open the Analytics page.
3. Make sure the Real Time view is selected in the time range drop-down.
For more details on the Analytics Dashboard, see Analytics: DDoS Protection for Networks and IPs.
Note: The Real-Time view in the main Network Protection and IP Protection Dashboards is not yet supported in sub
accounts.
Mobile App: Attack Analytics Actionable Insights
You can now view Attack Analytics Actionable Insights on the Imperva Security Mobile App.
Actionable Insights provide recommended actions for attacks that have targeted your sites and applications. Learn
about the steps you can take to enhance your security posture.
The new version is available via the Apple App Store and the Google Play App Store.
• Imperva Security Mobile App
• Attack Analytics Actionable Insights

Homepage dashboard update
To align with the Website Security Dashboard, the WAF events section the account-level dashboard was renamed
WAF violations.
This section displays malicious activity, calculated by sessions and events.

In addition, the details popup that is displayed when you click the ellipsis has been updated.
Tip: Hover over the Action column for more details.
Where it’s located: The homepage is displayed by default when you log in to your account. Alternatively, click Home
on the top menu bar.
For more details, see Homepage Dashboard.

Advanced Bot Protection: Role-Based Access Control (RBAC) added

From November 30 2021, role-based access control now applies to Advanced Bot Protection.
Roles and permissions must be configured by an admin user for non-admin users to be able to perform any
configuration actions in Advanced Bot Protection.
The required permission is Can edit ABP configuration. Users without this permission can access Advanced Bot
Protection in read-only mode.
Note that the limitations for a user in read-only mode apply to the settings windows and not to the dashboards.
Users in read-only mode continue to have access to full dashboard functionality.
For details on assigning roles and permissions, see Manage Roles and Permissions.
For details on Advanced Bot Protection, see Understanding Advanced Bot Protection.
In January 2022 we will start to automatically migrate customer accounts to our new Near Real-Time SIEM
integration.
solution.
occurs.
Availability:
• During December 2021, customers who are currently using the SIEM log integration with the S3 push method
can contact Imperva Support to request migration to the new mechanism.
• In Q1 of 2022, we will migrate all customer accounts that are currently using the Imperva SIEM log integration
with the S3 push method.
Note:
address list.
18.197.138.101/32
52.28.122.247/32
18.196.8.244/32

34.195.164.78/32
34.227.199.200/32
35.168.228.214/32
54.178.125.129/32
13.114.18.213/32
13.115.55.10/32
54.153.205.221/32
13.239.174.189/32
13.236.96.83/32
Note that during the migration process, there will be a short period in which logs will be sent from both the old
and new systems.
later date.

seconds
Data freshness

access events
only


51226475.WAF_RAW_LOGS.7f108651-1258-4177-

As of July 1, 2022 Imperva will no longer support the SSLv3 security protocol and the RC4 cipher.
Security Mitigation

Fixes
None.
Known Issues

November 21, 2021 Release

In this release:
• DDoS Protection for Networks: View performance metrics

• Store your private key in a 3rd party HSM service
• DDoS Protection for Networks and IPs: Send us your feedback
• Website certificate selection by Imperva proxies
New Features
DDoS Protection for Networks: View performance metrics
Gain visibility into the performance of the GRE tunnel connections between Imperva data centers and your origin
network.
View metrics on latency, jitter, and packet loss to assess the stability of your connections, when you're experiencing
network issues, or any time you want to check on the connection status in order to speed up your investigation.
Where it’s located: On the new performance dashboard. In the Cloud Security Console, navigate to Edge > Network
Protection > Dashboard > Performance.
For details, see Performance Dashboard.

Store your private key in a 3rd party HSM service

You can now upload your own website certificate to Imperva while maintaining your private key in an external key
management and encryption service.
Regulatory requirements may demand that your certificate's private key be hosted in an HSM. If you choose to use
your own certificate for your Imperva-protected website, you can upload your certificate without the private key while
maintaining the private key in a 3rd party cloud HSM service.
Fortanix Data Security Manager is the HSM service currently supported for this integration.
For details, see Upload a Custom Certificate with HSM Support.
Enhancements
DDoS Protection for Networks and IPs: Send us your feedback
How did we do? Easily share your feedback about Imperva’s mitigation of a specific DDoS attack.
A message is displayed on the analytics page when drilling-down into an attack.
You can then opt to open a short form and provide your feedback.
The message is displayed when you open the analytics page as follows:
• You receive a DDoS event ended mail notification, and click the link to view more details.
• You click the Analyze Attack button on the Network/IP Protection Dashboard. The button is displayed in the
dashboard’s Event Log table for a DDoS event has ended event.
Website certificate selection by Imperva proxies
If you have uploaded a custom certificate for a website in addition to the Imperva-generated certificate we provide
(“Imperva-generated certificate”), the Imperva proxy server must decide which certificate to use.
What changed: To optimize the selection process, the algorithm used to select which certificate to use has been
changed.
Note: Applies to newly onboarded websites only. We will continue to use the previous method for existing sites.
Before the change:
The Imperva proxy selected a certificate in this order:
1. The website's custom certificate.
2. A custom certificate from another site in your account with a SAN corresponding to the site in question.

3. The Imperva-generated certificate.
After the change (for new websites only):
The Imperva proxy now selects a certificate in this order:
3. A custom certificate from another site in your account with a SAN corresponding to the site in question.
To ensure that your custom certificate is used for a website, make sure that it is uploaded to that specific website's
configuration in Imperva.
Starting the week of December 5, 2021, we will start to automatically migrate customer accounts to our new Near
Real-Time SIEM integration.
solution.
occurs.
Availability:
• Early December 2021: Migration of approximately 50% of Enterprise 20 customer accounts that are currently
using the Imperva SIEM log integration with the S3 push method.
• In Q1 of 2022, migration of additional customer accounts who are currently using the SIEM log integration with
the S3 push method will continue. Updates will follow in future release notes.
Note:
address list.
18.197.138.101/32
52.28.122.247/32
18.196.8.244/32
34.195.164.78/32

34.227.199.200/32
35.168.228.214/32
54.178.125.129/32
13.114.18.213/32
13.115.55.10/32
54.153.205.221/32
13.239.174.189/32
13.236.96.83/32
later date.

seconds
Data freshness

access events
only

51226475.WAF_RAW_LOGS.7f108651-1258-4177-

Security Mitigation
Fixes
None.
Known Issues



In this release:
• DDoS Protection for Networks and IPs: Enhanced sub account support
• Change in the Alternative Domain/Hosts table
• Certificate configuration options added
• Domain validation policy changes
• Security rule statistics added to Website Security Dashboard
• Heads Up: Planned maintenance on the Cloud Security Console
• Heads Up: Old Performance/Security/Traffic dashboards removal
New Features
None.
Enhancements
DDoS Protection for Networks and IPs: Enhanced sub account support
In addition to protected networks, you can now manage protected IPs and flow exporters at the sub account level.
To facilitate the transition, you can move your existing assets from the parent account to its sub accounts using a new
Imperva API.
For details, see Sub Account Support.

Change in the Alternative Domain/Hosts table
For enhanced clarity, changes were made in the Alternative Domains/Hosts table. This table lists the additional
domains or hosts linked to the onboarded website using the CNAME provided by Imperva.
Where it’s located: On the General Settings page in the Cloud Security Console (Application > Websites> <select a
website> > General Settings > DNS Settings).
What changed: The Verified field was renamed Protected Status, and the possible values were changed as follows:
Before the change After the change

Approved Protected
Pending Bypassed
Blocked Misconfigured
- Verified (new value)

For more details, see Website General Settings.

Certificate configuration options added
When you onboard a website to Imperva and request an Imperva-generated certificate, you have the following
options:
• Add a wildcard or full domain SAN
• Add a naked domain SAN
Your preferences are used by Imperva the first time the certificate is generated, and each time the certificate is
renewed.
What changed: Previously, you could not change these options in the UI after onboarding, and needed to use the API
or contact Imperva Support if you wanted to make a change. Now you can configure the options in the UI.
Impact: Changing the options does not impact the current certificate for your website. The new settings will take
effect the next time the certificate is renewed.
1. Navigate to Application > Websites and click a website name.
2. On the sidebar, click Website Settings > General.
For more details, see Web Protection - General Settings.

Domain validation policy changes

As mandated by the CA/B Forum, the regulatory/standards organization that administers the public web trust,
effective November 30th, 2021, the previously accepted HTTP Domain control validation (DCV) method will no longer
be allowed when issuing wildcards or for subdomains.
The primary goal of this industry mandate is to improve the security posture by addressing the security issues of the
existing baseline requirements to authenticate an entire domain namespace.
This policy change will apply to all new requests, renewals, and re-issues for Imperva-generated certificates issued for
your protected websites.
There is no impact to TLS/SSL certificates that have already been issued until the certificate expires. However, no
additional SANs could be added to or removed from a certificate containing a wildcard SAN validated using HTTP
Domain control validation.
To continue using this validation method, it will be required to validate each subdomain (SAN:DNSName) individually.
Therefore, Imperva will support wildcard SAN validation only via DNS or email validation.
If we have identified that your configuration needs to be updated to comply with this change in the standards, you will
receive additional communications from Imperva.
Security rule statistics added to Website Security Dashboard
You can now view statistics for triggered custom security rules for your protected websites.
Where it’s located: On the Website Security Dashboard, under Security settings (Application > WAF > Dashboards >
Security).

For more details on the dashboard, see Website Security Dashboard.

Heads Up: Planned maintenance on the Cloud Security Console
Planned maintenance on the Imperva Cloud Security Console is scheduled for Sunday November 21, 2021 between
06:00PM - 08:00PM UTC for a Cloud WAF database upgrade.
During the process, the Cloud Security Console (UI and API) will be unavailable.
Your assets will remain fully protected by Imperva systems for the duration of the activity.
Heads Up: Old Performance/Security/Traffic dashboards removal
The Performance, Security, and Traffic tabs of the old Website Dashboard page are planned for removal in the near
future. Updates will follow in future release notes.
If you are still using the old Website Dashboard, we encourage you to familiarize yourself now with the new, enhanced
dashboards.
The new website Performance and Security dashboards introduce improved usability, faster investigation time, and
more actionable data, and are currently available to all users.
Where the new dashboards are located: On the top menu bar, navigate to Application. On the sidebar, click WAF >
Dashboards.
The Traffic tab has moved to the Performance & traffic section of the new Website Performance dashboard.
For more details about the new Website Dashboards, see Website Dashboards.
Security Mitigation
Fixes
None.
Known Issues



In this release:
• Website Performance Dashboard: Enhanced Performance

• Customize the homepage layout
• DDoS Protection for Networks: Change in confirmation mails before traffic is diverted
• Heads Up: Planned maintenance on the Cloud Security Console
New Features
None.
Enhancements
Website Performance Dashboard: Enhanced Performance
The Performance dashboard provides caching and traffic statistics for your Imperva-protected websites and
applications.
What changed: The following performance improvements are rolling out over the next several weeks:
• Resolution of 1 minute when the selected time range is less than 12 hours. The maximum resolution was
previously 10 minutes.
• Improved page loading time.
For more details on the dashboard, see Website Performance Dashboard.

Customize the homepage layout
You can now customize the layout of the homepage account-level dashboard.
What changed: The Arrange button enables you to:
• Click the toggles to show or hide a section of the dashboard. By default, all sections are displayed.
• Click and drag to change the order of the sections displayed on the dashboard.

The customized view is saved per user, per account.

DDoS Protection for Networks: Change in confirmation mails before traffic
is diverted
When an attack is detected, DDoS Protection for Networks customers working in on-demand mode can request that
Imperva confirm before diverting traffic to Imperva.
In addition to Imperva contacting you by automated mail, and by text/phone call according to your preferred method,
our Network Operations Center (NOC) team was also manually sending a confirmation mail.
What changed: The NOC team is no longer sending the duplicate confirmation mail. If you have any automation rules
that rely on the manual mails, we recommend you update them to rely on the automated mails.
Manual mails from NOC team:
• Sent from Imperva Support <support@incapsula.com>

• Subject line includes "DDoS Detected"
Automated notification mails:
• Sent from Imperva Service <no_reply@out.imperva.com>

• Subject line starts with "DDoS attack detected"
Heads Up: Planned maintenance on the Cloud Security Console
Planned maintenance on the Imperva Cloud Security Console is scheduled for Sunday November 21, 2021 between
06:00PM - 08:00PM UTC for a Cloud WAF database upgrade.
During the process, the Cloud Security Console (UI and API) will be unavailable.
Your assets will remain fully protected by Imperva systems for the duration of the activity.

Security Mitigation
Fixes
None.
Known Issues


In this release:
• Introducing Near Real-Time SIEM integration

New Features
None.
Enhancements
Introducing Near Real-Time SIEM integration
We are starting to roll out our new near real-time SIEM integration solution. The new mechanism introduces a
dramatic reduction in the time it takes to deliver logs to you after the security event occurs.
solution.
As a first step, the new mechanism will be implemented for:
later date.
Availability:
Until December 1, 2021, customers who are currently using the Imperva SIEM log integration with the S3 push
method can contact Imperva Support to request migration to the new mechanism.
address list. To prepare for migration, verify that you have all Imperva IP addresses included in your allowlist.
Note that the IPs supporting the Near Real-Time SIEM integration are not returned by the API that retrieves the
Imperva ranges, as they are not required by all Cloud WAF customers. For details, see Allowlist Imperva IP
addresses & Setting IP restriction rules.
At a later stage, the new mechanism will be available to new and existing customers who start using the SIEM log
integration with the S3 push method. Updates will follow in future release notes.

What changed:
After your account is migrated to the new mechanism, the following changes to the log files will apply:

seconds
Data freshness
One log file with both security and Two log files - one for security
File contents
access events events and one for access events

51226475.WAF_RAW_LOGS.7f108651-1258-4177-
These files will continue to be in These files will be introduced after

use after your account is migrated your account is migrated to the
to the new mechanism. new mechanism.
Comments
They will now contain only They will contain only security
access logs. logs.


As of November 7, 2021, the Performance, Security, and Traffic tabs of the old Website Dashboard page will no
longer be accessible.
The new website Performance and Security dashboards introduce improved usability, faster investigation time, and
more actionable data, and are currently available to all users.
Dashboards.
Security Mitigation
Fixes
None.

Known Issues
None.


In this release:
• Notifications of ongoing network level DDoS attacks

• CDN: Enhanced option for purging specific resources
• Heads up: Near Real-Time SIEM integration
• Heads Up: Deprecation of API authentication using query parameters
New Features
Enhancements
Notifications of ongoing network level DDoS attacks
Popup notifications have been added to the Cloud Security Console, giving you greater visibility into ongoing Layer
3/4 volumetric DDoS attacks on your assets.
What changed: In the event of an active DDoS attack, a notification is displayed in the top-right corner of the Console
window when you log in.
The popup includes links to the attacked assets, opening a drill-down view of the attack analysis.
• Website groups: The Imperva IPs that support your Cloud WAF protected websites.
• Protected Networks and IPs: Your origin IP addresses or ranges protected by the DDoS Protection for Networks
and Single IPs services.

The information updates every 5 minutes. If you close the popup and a new attack occurs during your logged in
session, a new notification is displayed.
CDN: Enhanced option for purging specific resources
As part of the caching functionality provided by Imperva CDN, you have the option to tag resources according to a
specified response header value in the resources. This enables you to subsequently purge resources according to the
tag name.
What changed: Previously, the response was tagged according to the entire value of the specified header. Now, if
there are multiple values in the header separated by commas, the resource is tagged with multiple tags. This provides
you with greater granularity for purging specific resources.
For example:
Previous behavior:
• Header Name: Cache-Tag

• Header Value: “tag1,tag2,tag3”
• Tagging Result: The resource is tagged with 1 tag - “tag1,tag2,tag3”
New behavior:
• Header Name: Cache-Tag

• Header Value: “tag1,tag2,tag3”
• Tagging Result: The resource is tagged with 3 different tags - “tag1”, “tag2”, and “tag3”
Where it’s located: In the Cloud Security Console, navigate to Application > <select your website> > Cache >
Advanced Settings > Tag the Response According to the Value of this Header.
For more details on caching configuration options, see Cache Settings.

Heads up: Near Real-Time SIEM integration
On November 1, 2021, we are starting rollout of our new near real-time SIEM solution. The new mechanism
introduces a dramatic reduction in the time it takes to deliver logs to you after the security event occurs.
Our existing log integration enables you to retrieve or receive your Imperva logs and archive or push these events into
your SIEM solution.

later date.
Availability:
• In the initial phase of rollout, customers who are currently using the Imperva SIEM log integration with the S3
push method will be migrated to the new mechanism. This phase is expected to continue through the end of the
year.
• At a later stage, the new mechanism will be made available to new and existing customers who start using the
SIEM log integration with the S3 push method. Updates will follow in future release notes.
What changed:

Sending rate Large files sent every 5-10 minutes Smaller files sent every 10 seconds
Files sent after 10-30 minutes or
Data freshness Files sent after 3-5 minutes
more
File contents

51226475.WAF_RAW_LOGS.7f108651-1258-4177-

Comments
access logs. logs.
Note:
• Access to your S3 bucket is verified by Imperva before your account is migrated. In the event that your S3 bucket
is not accessible, our team will contact you to update your S3 allowlist.
To verify that you have all Imperva IP addresses included in your allowlist, see Allowlist Imperva IP addresses &
Setting IP restriction rules. The additional IP addresses that are used for the new SIEM mechanism were recently
added to the list. They will be in use as of start of the Near Real-Time SIEM rollout on November 1st.
• In the event that you change your connection details in the Logs Setup, it can take up to 3 hours for the

Heads Up: Deprecation of API authentication using query parameters

In September 2020, we introduced support for API authentication using request headers instead of sending them as
query parameters.
For backward compatibility, we still support sending the api_id and api_key parameters in the query string.
On November 1, 2021, support for API authentication by sending the API Key/ID as query parameters will be
discontinued. At that point, API calls using the authentication query parameters will no longer work.
For more details on API authentication, see Authentication.

longer be accessible. The new website Performance and Security dashboards introduce improved usability, faster
investigation time, and more actionable data, and are currently available to all users.
Dashboards.

Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for Networks: SIEM integration

New Features
DDoS Protection for Networks: SIEM integration
Send events logs for the Imperva DDoS Protection for Networks and IPs services to your preferred SIEM solution.
Imperva pushes the event logs to your Amazon S3 bucket, enabling you to import the events into your SIEM solution.
This integration is based on the new Imperva Near Real-Time SIEM solution, currently rolling out.
Availability: We are now offering the SIEM integration for DDoS Protection for Networks and IPs as an Early
Availability feature. To enable the feature for your account during this period, contact Imperva Support.
Events include:
• Connection up
• Connection down
• IP up
• IP down
• DDoS attack detected
• DDoS event has started
• DDoS event has stopped
• Flow traffic has stopped
• Flow traffic has started
• Incompatible flow traffic

For more details, see SIEM Log Integration: DDoS Protection for Networks and IPs.
Enhancements
On November 1, 2021, we are starting rollout of our new near real-time SIEM solution. The new mechanism
introduces a dramatic reduction in the time it takes to deliver logs to you after the security event occurs.
your SIEM solution.
later date.
Availability:
year.
What changed:

more
File contents

51226475.WAF_RAW_LOGS.7f108651-1258-4177-
These files will be introduced after

your account is migrated to the
These files will continue to be in
Comments new mechanism.
to the new mechanism.
They will contain only security
logs.

They will now contain only

access logs.
Note:

query parameters.


longer be accessible. The new website Performance and Security dashboards introduce improved usability, faster
investigation time, and more actionable data, and are currently available to all users.
Dashboards.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• Visibility into alternative domains defined for a website (CNAME reuse)

• Cloud WAF: DNSSEC compliance for DNS CNAME resolution
• Account Takeover Protection: Allowlist API
• DDoS Protection for Networks: Maintenance email address updated
• Heads Up: Old Performance/Real-time/Security/Traffic dashboards removal
New Features
None.
Enhancements
Visibility into alternative domains defined for a website (CNAME reuse)
Alternative domains that are connected to an onboarded website via CNAME reuse are now displayed in the Cloud
Security Console.
Background: Imperva enables the use of website settings for several different domains that share the same IP
address. This is implemented by using the CNAME provided by Imperva for the onboarded (primary) website. For
more details, see CNAME Reuse.
What changed: The list of all domains pointing to the IP address of an onboarded website via CNAME reuse is now
provided via the UI and API.
Next steps:
• For enhanced protection, Imperva will add an option in the near future to block all domains that do not appear
in the table. Initially, this option will be disabled by default. You can choose to turn it on for a higher level of
protection.
• Imperva will also be introducing a new website level “Imperva-generated certificate” that will provide support
for all alternative domains associated with an onboarded website. Note: The website certificate will support SNI
communication only. The existing certificates will continue to be used for non-SNI communication.
• UI: A new table lists all the alternative domains pointing to the IP address of the onboarded website via CNAME
reuse, and therefore sharing the same site configuration.

• Domains are automatically added to the table when requests for them reach Imperva.
• You can also manually add domains to the table to prepare for the enhanced protection offered by the
next steps explained above. Add domains to the table to instruct Imperva to allow legitimate traffic to
these domains once the next steps are implemented.
Legitimate traffic for all verified domains is allowed.
To access the UI, navigate to Application > Websites > <select a website> > General Settings. For more details,
see Website General Settings.
• API: You can also manage alternative domains using the Imperva API. For details, see Website Domain
Management API Definition.
Cloud WAF: DNSSEC compliance for DNS CNAME resolution
In this release, we are re-enabling DNSSEC compliance on the impervadns.net and incapdns.net domains. These
domains support all websites onboarded to Imperva’s Cloud WAF.
This enhancement completes the end-to-end chain of trust as we now sign and validate Imperva’s CNAME records
with DNSSEC.
Details:

DNSSEC (Domain Name System Security Extensions) adds a layer of authentication to DNS CNAME resolution to
prevent requests from being “hijacked” and diverted to other addresses. This boosts protection against man-in-the-
middle attacks, such as DNS cache poisoning and forged DNS responses.
When onboarding your site to Cloud WAF, Imperva provides you with a CNAME that is used both for pointing traffic to
the Imperva network, and for identifying the site in the event that multiple domains are linked under the same
Imperva site configuration and policy. The CNAME resolves to an IP address in Imperva’s DNS zone.
After onboarding, you can see DNS settings for your site in the General Settings page. For details, see Website General
Settings.
On November 1, 2021, we are starting rollout of our new near real-time SIEM solution. The new mechanism introduces
a dramatic reduction in the time it takes to deliver logs to you after the security event occurs.
your SIEM solution.
later date.
Availability:
year.
What changed:

more
File contents

51226475.WAF_RAW_LOGS.7f108651-1258-4177-


Comments
access logs. logs.
Note:
Account Takeover Protection: Allowlist API

You can now manage your Account Takeover Protection allowlist via the Imperva API.
The allowlist enables you instruct ATO Protection to allow all login attempts from specific IP addresses.

• Account Takeover Protection API

• Allow Access to Trusted IPs
DDoS Protection for Networks: Maintenance email address updated
As a DDoS Protection for Networks customer, you may occasionally receive email notifications from Imperva about
maintenance activities.
These mails originate from the address noc@incapsula.com.
What changed: To help you more easily identify these maintenance announcements, the sender name was added to
the email address, and will appear as follows: Imperva NOC <noc@incapsula.com>.
For more details on maintenance activities, see Maintenance Readiness.

Heads Up: Old Performance/Real-time/Security/Traffic dashboards
removal
As of October 24, 2021, the Performance, Real-time, Security and Traffic tabs of the old Website Dashboard page will
no longer be accessible. The new website Performance, Real-time, and Security dashboards introduce improved
usability, faster investigation time, and more actionable data, and are currently available to all users.
Dashboards.
query parameters.
Security Mitigation

Fixes
None.
Known Issues
None.


In this release:
• New Notification Policies in Notification Settings

• Classic UI removed
New Features
None.
Enhancements
New Notification Policies in Notification Settings
Additional notification policies are being rolled out for the new Notification Settings feature, providing users with
more granular control over which notifications they receive, and the list of recipients who receive them.
The new notification policies being rolled out include:
• Subscription notifications
• SIEM log storage notifications
• Edge security (includes notifications for Network DDoS events, status and configuration updates on flow
exporters, router connections, and DNS zones)
In addition, an API for creating and managing notification settings for user accounts has been added.
Availability:
• As of this release, new accounts can take advantage of the complete Notification Settings feature, including the
newly added notification policies.
• Rollout of the Notification Settings feature to all accounts that do not yet have access is starting and will
continue through the end of the year.
View default notification settings and create new notification policies.

Where it’s located: In the Cloud Security Console, navigate to Account Management > Notification Settings.
For more details about the Notification Settings page, see Notification Settings.
For more details about the Notification Settings API, see Notification Settings API Definition.
Classic UI removed
The Switch to Classic UI option was removed.

The new navigational structure in the Cloud Security Console rolled out last year aligns with Imperva’s offering
categories (Application, Edge, Data), addresses scalability and usability issues, and reduces time to navigate.
For more details on the new UI, see Cloud Security Console.
removal
Dashboards.
query parameters.
Security Mitigation
Fixes
None.
Known Issues
None.



In this release:
• Account Takeover Protection Updates

• Client-Side Protection Updates
• Custom certificates must include the website’s domain
• Heads Up: Closing access to the Classic UI
New Features
None.
Enhancements
Account Takeover Protection Updates
The following enhancements were made to Account Takeover Protection:
Reset your password
If you have defined a password for viewing username fields in cleartext, you can now reset the password directly from
the Account Takeover Protection dashboard.
Previously, only the Imperva Support team could reset the password.
Where it’s located: On the ATO Protection Settings page, click Change password.
For more details, see View Username Data.
Add multiple IPs and IP ranges to the allowlist
For enhanced usability, you can now add single IP addresses, multiple IP addresses, or IP ranges to the allowlist.
What changed: Previously, you could only add individual IP addresses to the allowlist, one at a time.
Where it’s located: On the ATO dashboard, click the settings icon to access the allowlist settings.
To add multiple IP addresses, separate the IPs with commas. To add an IP range, use the IP/mask format.
For more details, see Allow Access to Trusted IPs.

Client-Side Protection Updates

The following enhancements were made to Client Side Protection:
Pre-approve services for multiple websites simultaneously
When adding a service to the allowlist, you can now add it to multiple websites at once.
1. On the Client-Side Protection dashboard, click Pre-approve Services.
2. Click Set for multiple websites and select from the list of websites in your account.
New estimated risk values added
Possible values for estimated risk now include malicious, magecart, and malware.
The estimated risk value indicates the likelihood that the service is being used for malicious intent. Previously, values
included Low, Medium, High, and No data.
In the event that the service is determined by Imperva to be malicious, or to be connected specifically to malware or
Magecart attacks, the new values are used instead of the low/medium/high categorization.

Custom certificates must include the website’s domain

When onboarding or configuring SSL support for a secure website in Imperva, if you choose to upload your own
custom certificate, it must include the SAN for the website’s domain.
What changed: If the certificate does not include the website’s domain, the upload is blocked and an error message is
displayed. Previously, upload of the certificate was not blocked, even if it did not include the website’s domain. This is
not a valid configuration and could impact the protection of the website.
Where it’s located: You can upload a custom certificate for your Imperva-protected website on the General Settings
page of the Cloud Security Console: Application > Websites > <your site> > Website Settings > General.
For details, see Upload a Custom Certificate for Your Website on Imperva.
Heads Up: Closing access to the Classic UI
On October 3, 2021, the Switch to Classic UI option will be removed.
If you are still using the Classic UI, we encourage you to familiarize yourself now with the enhanced look and feel of
the new UI and start taking advantage of new features available only in the new UI.
removal
Dashboards.

query parameters.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• RSA key length limit for custom certificates

• Heads Up: Custom certificates must include the website’s domain
• Website traffic metrics displayed on the account dashboard
• Application Delivery: “State” rule parameter supports regions
• Monitoring Settings page replaced
• Website Performance Dashboard: 95th percentile indicator removed
New Features
None.
Enhancements
RSA key length limit for custom certificates
As part of onboarding your website to Imperva, you have the option to upload your own certificate.
What changed: You can no longer upload a certificate that is 4096 bits or larger. This change applies to all existing
websites or newly onboarded websites.
Exception: If your website is currently using a certificate that is 4096 bits or larger, you can replace it as required for
certificate rotation.
Why the change? According to industry standards for PKI, the recommended key size is an RSA 2048 bit certificate.
This is the recommendation of the National Institute of Standards and Technology (NIST), Mozilla, and others.
In addition, Imperva supports this recommendation for the following reason: The majority of clients support PFS
ciphers. When a client supports PFS ciphers, the Imperva proxy will always use it. And when a PFS cipher is used, the
certificate key is used only for server authentication. It does not affect key exchange, and therefore has no impact on
encryption strength and security.
Where it’s located: You can upload a new custom certificate for your website on the General Settings page. For
details, see Web Protection - General Settings.
Heads Up: Custom certificates must include the website’s domain
The following change is planned for September 26, 2021.

When onboarding or configuring SSL support for a secure website in Imperva, if you choose to upload your own
custom certificate, it must include the SAN for the website’s domain.
What’s changing: If the certificate does not include the website’s domain, the upload will be blocked and an error
message will be displayed. Previously, upload of the certificate was not blocked, even if it did not include the
website’s domain. This is not a valid configuration and could impact the protection of the website.
Where it’s located: You can upload a custom certificate for your Imperva-protected website on the General Settings
page of the Cloud Security Console: Application > Websites > <your site> > Website Settings > General.
For details, see Upload a Custom Certificate for Your Website on Imperva.
Website traffic metrics displayed on the account dashboard
Website traffic metrics were added to the account-level dashboard, located on the Home page of the Cloud Security
Console.
Availability: This change is being rolled out over the next several weeks and may not yet be enabled in your account.
The new Website Traffic section displays the following metrics:
• Total visits: (Sessions) The number of times the website was accessed.
• Total bandwidth: All bandwidth used for responses served from the Imperva cache and from your origin server.
• Bits per second: The average number of bits per second of incoming and outgoing traffic passing between
clients and Imperva, based on calculation of the 95% percentile.
• Top websites: The websites in the account with the highest total visits, total bandwidth, or bits per second.
The new Traffic by Geo Location map shows traffic distribution by country.

Application Delivery: “State” rule parameter supports regions

When creating a custom rule, you can now use the State rule filter parameter together with the CountryCode
parameter to identify requests from a specific region in countries outside of the United States. You can use this to
block traffic from a specific region.
What changed: Previously, the State parameter applied to states within the United States, and accepted only the 2-
character ISO codes for those states. Now, the parameter supports any 2-character alphanumeric string, enabling you
to create a filter that identifies regions or subdivisions within countries outside of the United States, according to
standard ISO codes.
For example, the Ukraine country code is UA, and the region code for Crimea is 43. To match requests coming from
Crimea, you can create the following filter: "CountryCode == UA & State == 43".
For details on creating custom rules, see Rules.

Monitoring Settings page replaced
The old Monitoring Settings page has been removed. The new Website Monitoring Settings page replaces the old
Monitoring Settings page, and is available to all customers.
Where the new Monitoring Settings page is located: On the top menu bar, navigate to Application > Websites >
<select a website> > Monitoring Settings.
For more details about the new Website Monitoring Settings page, see Load Balancing Monitoring Settings.
Website Performance Dashboard: 95th percentile indicator removed
An indicator of the 95th percentile of bandwidth usage was previously displayed in the new Website Performance
Dashboard’s Requests over time and Bits/second graphs.
The metric was not aligned with calculation of the 95th percentage of bandwidth usage presented in the Usage
Report, used for billing clean traffic, and was therefore removed.
• View Account Usage

• Account Bandwidth Calculation

removal
Dashboards.
query parameters.

Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• Client-Side Protection API

• Certificate renewal: Action required
• Heads Up: Old Security and Performance dashboards removal
New Features
None.
Enhancements
Client-Side Protection API
You can now access your Client-Side Protection data and configuration via the API.
Client-Side Protection guards your customers’ data from theft through client-side attacks like digital skimming, supply
For details, see Client-Side Protection API Definition.

Certificate renewal: Action required
Typically, when your website's Imperva-generated certificate needs to be renewed, the process is completed
Subject lines of the mail: "Domain revalidation required" or "Domain revalidation deadline"
SSL.
Note:
• Due to internal changes made to enhance our certificate revalidation process, you may be asked to revalidate
ownership of your domain long before the certificate’s expiration date. This will help us align our system, and
enable us to complete the process more automatically moving forward.
• Revalidation emails are sent to account users as follows:

• For customers who subscribed to Imperva after June 27, 2021, notification recipients are defined on
the Notification Settings page. For details, see Notification Settings.
• For customers who subscribed to Imperva before June 27, 2021, notification recipients are defined in
Account Settings. For details, see Account Settings. Notification settings for existing customers will be
migrated to the new mechanism at a later date.
Make sure that the users who need to receive these mails are defined in the relevant location.
For more details on certificate renewal, see Revalidate Your Imperva Certificate.
Heads Up: Old Security and Performance dashboards removal
As of October 24, 2021, the Security and Performance tabs of the old Website Dashboard page will no longer be
accessible. The new website Security and Performance dashboards introduce improved usability, faster investigation
time, and more actionable data, and are currently available to all users.
Dashboards.


query parameters.
Fixes
None.
Known Issues
None.


In this release:
• Heads Up: GlobalSign Atlas TLS ICA certificate rotation

• Events page replaced with new Security Events page
• Heads up: Old Monitoring Settings page removal
New Features
None.
Enhancements
Heads Up: GlobalSign Atlas TLS ICA certificate rotation
To promote good ecosystem security and agility, GlobalSign will be rotating their Atlas Intermediate CA certificates
(ICAs) on a regular schedule.
The first certificate replacement is scheduled for August 24, 2021. Thereafter, the ICA certificate will be replaced
quarterly.
Note: This change applies only to Imperva-generated SSL certificates.
What do I need to do?
Most customers can expect the change to be seamless.
However, if you are using certificate pinning, note that it is not supported for Imperva-generated certificates.
Websites using SSL certificate pinning with Imperva-generated certificates may experience a service disruption when
the ICA certificate is replaced.
To prevent that from happening, we advise you to remove any certificate pinning linked to Imperva-generated
certificates.
You may continue to use certificate pinning by uploading and pinning custom certificates instead. For details, see
Upload a Custom Certificate for Your Website on Imperva.
Where can I read more about this change?
For more information from GlobalSign, see https://support.globalsign.com/atlas/atlas-tls/atlas-tls-ica-rotations-2021.

Change in Feature Availability

Events page replaced with new Security Events page
The old Events page has been removed. The new Security Events page replaces the old Events page, and is available
to all customers.
What changed: The Security Events page provides an enhanced view for exploring the security events detected and
mitigated by Imperva.
Where the Security Events page is located: In the Cloud Security Console, navigate to Application > Security
Events.
For more details, see View Security Events.

Heads up: Old Monitoring Settings page removal
As of August 29, 2021, the old Monitoring Settings page will no longer be accessible. The new Website Monitoring
Settings page replaces the old Monitoring Settings page, and is available to all customers.
Where the new Monitoring Settings page is located: On the top menu bar, navigate to Application > Websites >
<select a website> > Monitoring Settings.
For more details about the new Website Monitoring Settings page, see Load Balancing Monitoring Settings.

Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• Website Monitoring Settings API

• DDoS Protection for Networks: BGP route advertisement for performance monitoring
• RSA key length limit for custom certificates
• New Website Monitoring Settings page: Rollout complete
• Heads Up: Events page removal
New Features
None.
Enhancements
Website Monitoring Settings API
You can now manage website monitoring settings via the API.
The website monitoring settings determine when origin servers should be considered “up” or “down” (active or
inactive) by the Imperva Load Balancer. They also enable you to select which failure scenarios you want to produce
alarm messages, and how to send them.
For details, see Load Balancing Monitoring Settings API Definition.

DDoS Protection for Networks: BGP route advertisement for performance
monitoring
As part of the DDoS Protection for Networks service, performance monitoring servers were introduced to support an
upcoming capability that is planned for release in the near future. Performance Monitoring will provide visibility into
the performance of the GRE tunnel connections between Imperva data centers and your origin network.
What changed: Imperva is now advertising BGP routes to our performance monitoring servers over GRE tunnels.
You can now see the IP addresses that are advertised for each GRE tunnel connection. They are listed as PM Server 1
and PM Server 2 in the Origin Connectivity table.
Where it’s located: In the Cloud Security Console, navigate to Edge > Network Protection > Connectivity Settings.
RSA key length limit for custom certificates
As part of onboarding your website Imperva, you have the option to upload your own certificate.

What changed: To date, Imperva has not limited the size of uploaded certificates. As of this release, you cannot
upload a certificate that is 4096 bits or larger. This applies only to websites onboarded to Imperva on or after this
release.
Why the change? According to industry standards for PKI, the recommended key size is an RSA 2048 bit certificate.
This is the recommendation of the National Institute of Standards and Technology (NIST), Mozilla, and others.
In addition, Imperva supports this recommendation for the following reason: The majority of clients support PFS
ciphers. When a client supports PFS ciphers, the Imperva proxy will always use it. And when a PFS cipher is used, the
certificate key is used only for signing. It does not affect key exchange, and therefore has no impact on encryption
strength and security.
Where it’s located: You can upload a new custom certificate for your website on the General Settings page. For
New Website Monitoring Settings page: Rollout complete
As part of our new, improved user experience for the Cloud Security Console, we have completed the rollout of the
new Website Monitoring Settings, which is now available to all customers. The new Website Monitoring Settings page
replaces the old Monitoring Settings page, which will no longer be available after August 29, 2021.
What changed: The UI has been streamlined for an enhanced user experience.
Where it’s located: On the top menu bar, navigate to Application > Websites > <select a website> > Monitoring
Settings.
For more details about the Website Monitoring Settings page, see Load Balancing Monitoring Settings.
quarterly.
certificates.


Heads Up: Events page removal
As of August 22, 2021, the old Events page will no longer be accessible. The new Security Events page replaces the old
Events page, and is available to all customers.
Events.

Security Mitigation

Fixes
None.
Known Issues
None.


In this release:
• Limitations to assigning Admin roles

• DNS Protection: Issue with hyphens in managed domain name and record name fixed
New Features
None.
Enhancements
Limitations to assigning Admin roles
Only an account administrator or users with the Administrator role are now able to assign the Administrator role to
other users.
What changed: All users with the ability to manage user roles were previously able to assign the Administrator role to
users.
Due to security hardening, only account administrators and users with the Administrator role are now able to:
• Create a role with administrator permissions
• Assign the administrator role to a user
In addition, users who aren’t account administrators and don’t have the Administrator role are no longer able to
modify administrator user assignments.
• To add/modify a user: In the Cloud Security Console, navigate to Account Management > Users & Identity
section > Users.
• To create a new role: In the Cloud Security Console, navigate to Account Management > Users & Identity
section > Roles.
For more details about managing roles, see Manage Roles and Permissions.

For more details about creating account users, see Account Users.
quarterly.
certificates.

Events.


query parameters.
discontinued.
Security Mitigation
Fixes
DNS Protection: Issue with hyphens in managed domain name and record
name fixed
Problem: Hyphens in a domain name or record name would prevent the domain or record from resolving. For
example, domain-with-hyphens.com or record-with-hyphens.example.com would not resolve.

Solution: The behavior is fixed. Managed domains or records will now resolve even if they contain hyphens.
For more information on managed domains, see Add/Edit a Primary Managed DNS Zone.
Known Issues
None.


In this release:
• Account dashboard updates

• DNS Protection: Hyphens in managed domain records
New Features
None.
Enhancements
Account dashboard updates
The following updates were made to the account dashboard, located on the Home page of the Cloud Security
Console:
• Top attacked websites: The Security section displays the 5 websites in the account with the highest number of
security events.
You can filter the websites according to total events, blocked events, or alerted events.
The Expand button opens a popup that displays up to the 10 top websites.

• Top websites: The Performance section displays the 5 websites in the account with the highest number of
requests.
You can filter the websites according to total requests or requests with errors.
The Expand button opens a popup that displays up to the 10 top websites.

• Sub account metrics: The Sub accounts table displays application security statistics for each of the account’s
subaccounts.
Information presented in the table has been changed, and now includes:
• Total visits
• WAF events
• Mitigated bots
• Total bandwidth
• Usage (95th percentile)
For more details, see the Homepage Dashboard.

quarterly.
certificates.


Events.

Security Mitigation

Fixes
None.
Known Issues
DNS Protection: Hyphens in managed domain records
We’ve identified an issue with managed domain records that contain hyphens. If the DNS record name includes a
hyphen, the domain is not resolved. For example, record-with-hyphens.example.com won't resolve.
We are currently working on a resolution. A workaround solution is to remove hyphens from DNS record names using
the UI or API.


In this release:
• Revamped Website Monitoring Settings page

New Features
None.
Enhancements
Revamped Website Monitoring Settings page
The Website Monitoring Settings page has been revised in order to improve the user experience.
The website monitoring settings determine when origin servers should be considered “up” or “down” (active or
inactive) by the Imperva Load Balancer. They also enable you to select which failure scenarios you want to produce
alarm messages, and how to send them.
Availability:
• The new page is currently being rolled out and may not yet be enabled for your account.
• The new page is available only in the new UI.
What changed:
• An API for viewing and modifying the website monitoring settings has been added.
• The UI has been streamlined for an enhanced user experience.
Where it’s located: On the top menu bar, navigate to Application > Websites > <select a website> > Monitoring
Settings.
For more details about the Website Monitoring Settings page, see Load Balancing Monitoring Settings.
For more details about the Website Monitoring Settings API, see Load Balancing Monitoring Settings API Definition.


quarterly.
certificates.


Security Mitigation
Fixes
None.
Known Issues
the UI or API.


In this release:
• Single sign-on (SSO) now available to resellers

New Features
None.
Enhancements
Single sign-on (SSO) now available to resellers
Single sign-on for login to the Cloud Security Console is now available to reseller accounts.
SSO provides multiple benefits, including an improved user experience and centralized user authentication
management.
For details, see Single Sign-On (SSO).

query parameters.
discontinued.
Security Mitigation

Fixes
None.
Known Issues
the UI or API.


In this release:
• DDoS Protection for Networks: Configure Flow Monitoring Settings

• Client-Side Protection: Set service status for multiple websites
New Features
None.
Enhancements
DDoS Protection for Networks: Configure Flow Monitoring Settings
Imperva’s monitoring service monitors your origin network to detect and notify you about DDoS attacks, as well as
enabling an automated mitigation process.
What changed: DDoS Protection for Networks customers using the on-demand deployment mode can now configure:
• flow exporter settings
• flow status notifications
• notification recipients
Previously, these settings were configured by Imperva Support.
Where it’s located: In the Cloud Security Console, navigate to Edge > Network Protection > Flow Monitoring
Settings.
For details, see Flow Monitoring Settings.

Client-Side Protection: Set service status for multiple websites
Set mitigation status (block/allow) for a service for multiple websites at once.
What changed: New options enable you to multi-select websites in your account, and apply the mitigation status for
the service to all of the selected websites. Previously, you could only set the status for one website at a time.
Where it’s located: On the Client-Side Protection Dashboard, in the Status column.

For details, see Client-Side Protection Dashboard.
Security Mitigation
Fixes
None.
Known Issues
the UI or API.


In this release:
• Introducing Notification Settings: Define your own policies

• DDoS Protection for Networks: Details added to attack notifications
• Homepage dashboard: Details added on DDoS attacks
• New website real-time dashboard: Rollout complete
New Features
Introducing Notification Settings: Define your own policies
The new Notification Settings feature provides you with more granular control over which notifications you receive,
and the list of recipients who receive them.
Availability: As of this release, all new customers and new App Protect Professional self-service trial accounts can
take advantage of the new Notification Settings.
For details on the new feature, see Notification Settings.

Enhancements
DDoS Protection for Networks: Details added to attack notifications
When a volumetric DDoS attack on your network assets is detected by Imperva’s network monitoring service, email
notifications are sent to you.
What changed: The attack notifications now include a list of the top destination IPs in the 5 minutes that preceded
the notification. You can then view additional details in the Analytics dashboard, under Destination IPs.
• Monitoring
• Notifications
• Analytics
Homepage dashboard: Details added on DDoS attacks
The Home page account-level dashboard now provides more details on network level (Layer 3/4) DDoS attacks,
including:
• The specific asset targeted in the attack, such as the IP address or website.
• The peak value of malicious traffic detected during the selected time frame.
• The status of the attack — if it is still active or if it has ended.
Where it’s located: The homepage is displayed by default when you log in to your account in the Cloud Security
Console. Alternatively, click Home on the top menu bar.
For more details, see Homepage Dashboard.

New website real-time dashboard: Rollout complete
Rollout of the new and improved Website Real-Time Dashboard is now complete.
The new dashboard provides consolidated performance and availability monitoring for your origin servers and traffic.
Where it’s located: Navigate to Application > WAF > Dashboards > Real-Time.
For more details, see Website Real-Time Dashboard.

Security Mitigation
Fixes
None.
Known Issues
the UI or API.



In this release:
• DDoS Protection for Networks: Change in network prefix usage calculation

• New website General Settings page: Rollout complete
• Expanded homepage dashboard: Rollout complete
New Features
None.
Enhancements
DDoS Protection for Networks: Change in network prefix usage calculation
The usage calculation of network prefixes for licensing and billing purposes has been adjusted, providing you with
more value for your investment.
The add-on for network prefixes determines how many network ranges you can define as part of your subscription to
DDoS Protection for Networks.
What changed: Before the change, each /48 IPv6 address was counted as 1 prefix. Following the change, all /48 IPv6
addresses under the same /32 subnet are considered 1 prefix in total.
Where it’s located: This change is reflected on the Subscription page in the Cloud Security Console. Under
Infrastructure Protection > C Class Ranges, the Used column will now display the adjusted value.
New website General Settings page: Rollout complete
As part of our new, improved user experience for the Cloud Security Console, we have completed the rollout of the
new website General Settings page, now available to all existing accounts and new customers.
What changed:
• All settings from the old website General Settings page except for SSL Support settings have moved to the new
page.
• SSL Support settings are still available on the old website General Settings page. They will be moved to a new
location at a later date. For more details, see Web Protection - General Settings.

To open the new page, navigate to Application > Websites > <select a website> > General Settings. For more details,
see Website General Settings.
The new page is available only in the new UI. Learn more: Cloud Security Console.
Expanded homepage dashboard: Rollout complete
We have completed the rollout of adding Website configuration and reliability sections to the Home page account-
level dashboard. This improvement, now available to all customers, provides enhanced visibility to the status of your
websites and connections.
Website configuration posture:
• View the configuration status of your websites.
• Get more details on any open configuration issues and how to address them.
Website reliability:
• Cloud WAF customers: View the up/down status of your websites based on the origin server availability.
• DDoS Protection for Networks/IPs customers: View the availability of your protected networks or IPs.
Each section is clickable and opens modal screens for further drill-down into each metric.
Where it’s located: The homepage opens by default when you log in to your account. Alternatively, click Home on the
top menu bar.
For more details on the new sections, see Homepage Dashboard.
Security Mitigation

Fixes
None.
Known Issues
the UI or API.


In this release:
• Advanced Bot Protection Billing Dashboard

• CDN: Custom rules to rewrite response headers are applied to error pages
• List data centers API update
New Features
None.
Enhancements
Advanced Bot Protection Billing Dashboard
The new billing dashboard in Advanced Bot Protection enables you to view the number of requests that ABP
processed for your application. You can configure the report to show data for your desired time frame and websites.
This enables you to compare your bills with the number of requests on the application.
Availability: The dashboard is currently available to US customers only. It is expected to be available to all customers
within a few weeks.

1. In Advanced Bot Protection, select the Dashboard menu item.
2. Select the Reporting Data Region from the bar at the top.
3. From the drop-down list at the top-right, select Billing Dashboard.
For more details, see Understanding the Billing Dashboard.

CDN: Custom rules to rewrite response headers are applied to error pages
Rollout of this feature is now complete and enabled for all customers.
Custom rules that use the Rewrite Response Header action are now also applied to error pages returned by Imperva
in the event of a connection error.
For more information on custom rules and error pages, see:
• Create Rules
• Custom Error Pages

List data centers API update
The /api/prov/v1/sites/dataCenters/list API that lists your website’s data centers now returns the name of the Origin
PoP if one is defined for the website. For more details, see Cloud Application Security v1/v3 API Definition.
You can configure an Origin PoP as part of the Dynamic Content Acceleration service for improved performance. For
more details, see Dynamic Content Acceleration.

query parameters.
discontinued.
Security Mitigation

Fixes
None.
Known Issues
the UI or API.


In this release:
• Introducing Notification Settings: Define your own policies

• API Security enhancements
• Expanded homepage dashboard
• New website General Settings page
• "View security information" permission removed
New Features
Introducing Notification Settings: Define your own policies
The new Notification Settings feature provides you with more granular control over which notifications you receive,
and the list of recipients who receive them.
Availability: As of this release, all new App Protect Professional self-service trial accounts can take advantage of the
new Notification Settings.
For details on the new feature, see Notification Settings.

Enhancements
API Security enhancements
The following enhancements were introduced in this release:
API Discovery. Enables you to:
• Understand which API endpoints are in your environment.
• Protect your APIs with a positive security model even if you don’t have an OAS file. With an ongoing learning
mechanism, API Discovery constantly learns the structure of the APIs whenever they are updated.
• Gain tighter protection of your APIs on top of the existing OAS files provided by the development teams.
• Download an OAS file of the discovered endpoints.
• Automatically integrate discovered APIs with your existing APIs.
View Data Classification. Know which API endpoint transfers PII information and decide on the appropriate security
level for each API endpoint according to the sensitivity of the data returned.
UI enhancements. To improve the usability experience, API Security is now separated into two options on the Cloud
Security Console sidebar:
• APIs: This page now enables you to view all the APIs that are configured for the website, edit the APIs, and view
APIs that were discovered using API Discovery. In addition, you can now access the API Security Dashboard from
here.
• API Settings: This page now enables you to perform the site configuration, enable API Discovery, and enable
automatic integration.

Expanded homepage dashboard
Website configuration and reliability sections were added to the Home page account-level dashboard, providing
enhanced visibility into the status of your websites and connections.
Website configuration posture:
• View the configuration status of your websites.
• Get more details on any open configuration issues and how to address them.
Website reliability:
• Cloud WAF customers: View the up/down status of your websites based on the origin server availability.
• DDoS Protection for Networks/IPs customers: View the availability of your protected networks or IPs.
Each section is clickable and opens modal screens for further drill-down into each metric.

Where it’s located: The home page opens by default when you log in to your account. Alternatively, click Home on
the top menu bar.
Availability: The new dashboard sections are gradually rolling out over the next few weeks and may not be
immediately enabled for your account.
For more details on the new sections, see Homepage Dashboard.

New website General Settings page
As part of our new, improved user experience for the Cloud Security Console, we are starting to gradually roll out a
new website General Settings page.
What changed:
• All settings from the old Website General Settings page except for SSL Support settings have moved to the new
page.
• SSL Support settings remain on the old Website General Settings page. They will be moved to a new location at
a later date.
• To open the new page, navigate to Application > Websites > <select a website> > General Settings. For more
details, see Website General Settings.
• To open the old page, navigate to Application > Websites > <select a website> > Website Settings > General.
Availability:
• Rollout is expected to continue for two months and therefore may not be immediately enabled for your
account.

• The new page is available only in the new UI. Featuring a new navigational structure and a clean, streamlined
experience, the new UI is currently rolling out to customers. Learn more: Cloud Security Console.
"View security information" permission removed
The View security information permission was not in use and was removed.
It is no longer displayed in Account Management > Roles.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for Networks: Monitoring email notifications fixed
New Features
None.
Enhancements
None.
Fixes
DDoS Protection for Networks: Monitoring email notifications fixed
Problem: Monitoring alert mails were not sent to the account notification list (defined in Account Settings) unless
there was also at least one recipient defined in the account escalation notification list (defined in Monitoring
Settings).
Solution: The behavior is fixed. Monitoring alert mails are now sent to the account notification list whether or not
there are recipients defined in the account escalation notification list.
This fix applies to the following notifications:
• NetFlow traffic start/stop/bad data alerts
• DDoS attack detected alerts
• Network traffic diverted alerts
For more details on notifications, see Notifications.
Known Issues
None.


May 9, 2021 Release

In this release:
• Advanced Bot Protection (ABP) events added to Audit Trail

• CDN: Custom rules to rewrite response headers are applied to error pages
New Features
None.
Enhancements
Advanced Bot Protection (ABP) events added to Audit Trail
ABP events are now tracked and displayed in the Audit Trail.
The Audit Trail displays a log of actions performed in your account by account users, system processes, and Imperva
Where it’s located: In the Cloud Security Console, navigate to Account Management > Audit Trail.
For more details, see Audit Trail.

CDN: Custom rules to rewrite response headers are applied to error pages
Custom rules that use the Rewrite Response Header action are now also applied to error pages returned by Imperva in
the event of a connection error.
Availability: This functionality is being rolled out over the next several weeks.
For more information on custom rules and error pages, see:
• Create Rules
Security Mitigation

Fixes
None.
Known Issues
None.

May 2, 2021 Release

In this release:
• OpenAPI (Swagger) definition file for Cloud API v1

• Consolidated API documentation
New Features
None.
Enhancements
OpenAPI (Swagger) definition file for Cloud API v1
All APIs for managing your Imperva account and sites are now available in a Swagger API definition file.
Swagger is a cloud based, interactive API testing and documentation tool. APIs are visually rendered as a fully
interactive document, enabling you to:
• visualize and interact with the API resources
• view and download the API documentation
• learn how to use the API
• try out the API before integrating it into your code using your API ID and key
For details, see Cloud Application Security v1/v3 API Definition.
Note: To better align with REST API standards and best practices, Imperva is gradually rolling out API V2 — a new
version of APIs, available for your use in managing your Cloud Application Security account and sites. The V2 APIs
either provide an alternative to existing APIs, or provide APIs with new functionality. (All existing version 1 APIs
continue to be supported.) For details, see API Version 2/3 Overview.
Consolidated API documentation
A consolidated reference to all Imperva customer-consumable APIs is now available in the documentation portal.
For details, see the Imperva API Reference.

Security Mitigation

query parameters.
On December 31, 2021, support for API authentication by sending the API Key/ID as query parameters will be
discontinued.
Fixes
None.
Known Issues
None.
Delete this text and replace it with your own content.


In this release:
• Mobile App: Support added for sub accounts

• New Imperva Data Center in Dublin, Ireland
• API Security: Enhanced design
• New rule action to override a WAF setting
• API: Modify the Imperva visitor cookie
• Cloud WAF: DNSSEC support
New Features
None.
Enhancements
Mobile App: Support added for sub accounts
View data for sub accounts in the Imperva Security Mobile App.
• Users with sub account access: You can now log in to the mobile app with your Imperva user credentials and
view your account.
• Users with parent account access: When you log in to a parent account that has sub accounts, you can now
switch between the parent and sub accounts.
Tap the Account icon to view and select from the list of your account’s sub accounts.

For more details on the mobile app, see Imperva Security Mobile App.
New Imperva Data Center in Dublin, Ireland
We are starting to rollout a new PoP in Dublin, Ireland and expect it to be fully functional within the next few weeks.
The Dublin PoP is the newest addition to our world-wide network of 46 data centers, helping you deliver your

API Security: Enhanced design

To provide you with an improved user experience, the following changes were implemented for API Security and are
rolling out over the next 2 weeks.
The API Security Dashboard has moved
In the Classic UI: On the API Security page, click the API Security Dashboard link to open the dashboard.
In the New UI: The dashboard is now located together with all website dashboards. (Application > WAF > Dashboards
> API Security)
The existing APIs page was split
• APIs: Displays a simple summary of your APIs onboarded to API Security.
• Action Configuration: For each of your APIs/endpoints, configure alert or block actions for each API Security
violation type.
Navigation changes (New UI only)
The API Security menu (Application > Websites > API Security) now includes two options:

• APIs: Opens the APIs and Action Configuration pages.
• API Settings: Displays Site Configuration settings.
For full details, see the API Security Documentation.

New rule action to override a WAF setting
Override a WAF setting for a subset of your protected website, enabling you to apply a more granular mitigation
strategy.
This can be useful if your website hosts several applications and you want to define a different threat response for one
or more of the applications, such as Alert instead of Block.
What changed: You can now create a custom rule to define an alternative WAF action for a subset of your domain, for
a specific threat type.
Where it’s located: On the Add Rule page, select the Override WAF Settings rule action.
For details, see Override WAF Settings.

API: Modify the Imperva visitor cookie
To correlate HTTP sessions to specific visitors to your sites, Imperva uses an HTTP cookie (visid_incap). The cookie is
associated with the naked domain for your site. If you prefer, the cookie can be sent without the domain.
What changed: A parameter is now available for your use with the API to instruct Imperva to send the cookie without
the domain. Previously, only Support was able to configure this option.
Where it’s located: The Modify Site Configuration API (/api/prov/v1/sites/configure) now includes the
set_cookies_without_domain parameter. When set to true, the naked domain is not included in the cookie.
Note: If this option was previously enabled for your site by Support, you cannot disable the setting via the API unless
the support team first removes the manual configuration. If you want to use the API to disable the option for your
sites, contact Support to request the adjustment.
For more details on this API, see Site Management API.
Security Mitigation


Cloud WAF: DNSSEC support
As of Wednesday, April 28th, as a precautionary measure, we will temporarily disable the DNSSEC support for Cloud
WAF onboarded sites. Service availability is not impacted. Please contact Imperva Support if you have any questions.
Fixes
None.
Known Issues
None.
Delete this text and replace it with your own content.


In this release:
• Usage Report in sub accounts
New Features
None.
Enhancements
Usage Report in sub accounts
The Usage Report is now available in sub accounts, displaying data for the specific sub account only.
What changed:
Previously, the report was available only in the parent account.
Availability:
• We are gradually rolling out this change for all accounts over the next several weeks.
• The change applies to both the Usage Report UI and API.
Note:
• When viewed in a sub account, the purchased quantity and overage data are not displayed. Those values are
relevant to the overall parent account only.
• In the API, the purchasedQuantity and overages fields display -1 for a sub account.
New UI:
2. On the sidebar, click Usage Report.
Classic UI:
On the sidebar, select Management > Usage Report.

For more details on the usage report, see View Account Usage.
Fixes
None.
Known Issues
None.


In this release:
• Rollout of the new UI extended

• Client-Side Protection updates
• Attack Analytics: Change in time range functionality
New Features
None.
Enhancements
Rollout of the new UI extended
In order to facilitate a smooth transition for our customers, gradual rollout of the Cloud Security Console’s new UI has
been extended.
What’s new in the new UI?
• A new navigational structure aligns with Imperva’s offering categories (Application, Edge, Data), addresses
scalability and usability issues, and reduces time to navigate.
• The Home page provides an at-a-glance view of all of your protected assets from the moment you log in to your
account. Quickly understand the overall account status and identify what requires your immediate attention or
further investigation.
• The new Website Dashboards and Security Events Page provide enhanced usability, faster investigation, and
more actionable data at the website level. These dashboards are easily accessible — no need to navigate to each
individual website.
Learn more:
• Cloud Security Console
• Website Dashboards
Don’t want to wait? If the new UI is not yet enabled for your account and you would like to opt-in now, contact your
sales representative to request the change.

Client-Side Protection updates

The following features are now available in Client-Side Protection:
• Estimated risk: View the estimated likelihood that the service is being used for malicious intent. Client-Side
Protection assigns an estimated risk level for each service: Low, Medium, or High.
• Apply bulk action to grouped services: Set the action for all services in the group with one click.
Where it’s located: In the Client-Side Protection dashboard, under Discovered Website Services.

Attack Analytics: Change in time range functionality
To align all Cloud Security dashboards, the following change was implemented for the time range function:
When you select a time range option, the dashboard reflects data spanning from the current time back to the same
time at the start of the time range.
In this example, the data spans the time period starting from the current time back through the same time 7 days
earlier.

What changed: Previously, the time range spanned from the current time back to 00:00 on the start date of the range.
Note: There is no change in the custom range option, which always spans from 00:00 on the first day to 23:59 on the
last day of the range.
Security Mitigation
Fixes
None.
Known Issues
None.



In this release:
• CDN: Delivery rule data added to Get Statistics API

New Features
None.
Enhancements
CDN: Delivery rule data added to Get Statistics API
The Get Statistics API now enables you to retrieve information on your custom delivery rules for a single website or
for all websites in your account, including the option to specify a custom time frame.
Where it’s located: The following values were added to the stats parameter of the Get statistics API (/api/stats/v1):
• delivery_rules: Returns the list of delivery rules with total number of hits for each rule.
• delivery_rules_timeseries: Returns the list of delivery rules with the number of hits per rule for each time stamp
in the selected time range.
For more details on the Get Statistics API, see Traffic Statistics and Details API.
Security Mitigation
Fixes
None.
Known Issues
None.



In this release:
• New real-time website dashboard

• New Imperva Data Center in Denver, Colorado
• CDN: Variables added for delivery rules
• New Site Reference ID field in SIEM logs
• Update: Migration to the new GlobalSign Atlas platform
New Features
None.
Enhancements
New real-time website dashboard
As part of our new user experience for the Cloud Security Console, we are now starting to roll out the new and
improved Website Real-Time Dashboard.
The new dashboard provides consolidated performance and availability monitoring for your origin servers and traffic.

Rollout is expected to continue through April 2021.
Availability:
• The new dashboard is available only in the new UI. Featuring a new navigational structure and a clean,
streamlined experience, the new UI is currently rolling out to customers. Learn more: Cloud Security Console.
• The existing real-time dashboard continues to be displayed in both the classic and new UI.
Where it’s located: Navigate to Application > WAF > Dashboards > Real-Time.
Learn more: Website Real-Time Dashboard.

New Imperva Data Center in Denver, Colorado
We are starting to rollout a new PoP in Denver, Colorado, USA and expect it to be fully functional within the next few
weeks.
The Denver PoP is the newest addition to our world-wide network of 45 data centers, helping you deliver your
CDN: Variables added for delivery rules
New variables are available for your use when defining custom redirect and rewrite delivery rules.
• Proxy ID
• PoP ID
• Origin PoP ID
• Session ID
• Request ID
• Site ID
• Account ID
For example, you can create a rule to rewrite request headers to provide you with information on the Imperva data
center that handles each request.

Where it's located: You can use these variables in the To field when creating a rule. For more details, see Create Rules.
New Site Reference ID field in SIEM logs
Reference ID is a free-text field defined in account and website settings that enables you to add a unique identifier to
correlate an object in our service, such as a protected website, with an object on the customer side.
The following change to Reference ID in the SIEM log integration is rolling out during the course of the week.
The new Site Reference ID field will be added, in the following formats:
• CEF: siteTag
• LEFF: siteTag
• W3C: s-sitetag
The Site Ref ID field corresponds to the Reference ID option in the Cloud Security Console Website General Settings.
• If Reference ID is already configured in website settings, the new field will appear in your logs when this change
is implemented.
• If this field is not configured in your website settings, the field will not appear in logs in CEF or LEFF formats. For
W3C format, the field will appear with an empty value.
Note: There is no change to the Account Reference ID field in the SIEM logs. This field corresponds to the account
level Reference ID option in the Cloud Security Console Account Settings.

• Log File Structure

• Example Logs
Update: Migration to the new GlobalSign Atlas platform
As a follow up to our previous notifications regarding the migration to the new GlobalSign Atlas platform, we want to
inform you of the following change.
In response to customer feedback, the certificate migration process has been extended until April 30, 2021. To
minimize any disruption to your service, we ask that you complete the required actions described below prior to that
date.
For follow-up questions or specific configuration issues, contact Imperva Support at https://www.imperva.com/login.
Background: For improved security and performance, we are now moving to the new GlobalSign Atlas Platform for
ordering and maintaining new SSL certificates. This platform is replacing the GlobalSign CloudSSL service that was
used until now.
To support this change, we are migrating all of our existing GlobalSign CloudSSL certificates to the new platform.
Impact:
Note: This change is only applicable to Imperva-generated SSL certificates.
While most customers can expect a seamless and transparent process, there are a few use cases where your attention
and action are required.
• Revalidation: During the migration, all SAN’s will be migrated to the new SSL certificates. In most cases,
Imperva will revalidate the SANs automatically. In the event that automatic revalidation is not possible, you will
receive a revalidation email from Imperva. We ask that you promptly complete the process to revalidate
ownership of your domain. You will receive an additional mail confirming that validation completed
successfully.
• Certificate pinning: Websites using SSL certificate pinning with Imperva-generated certificates may experience
a service disruption when the certificate is migrated.
To prevent that from happening, we advise you to remove any certificate pinning linked to any Imperva-
generated certificates.
You may continue to use certificate pinning by uploading and pinning custom certificates instead. For details,
see Upload a Custom Certificate for Your Website on Imperva.
• GlobalSign root certificate: Client applications that are using the GlobalSign root certificate in their trust store
will need to update the trust store with the Atlas root certificate after migration.
Additional information about Atlas:
• https://www.globalsign-media.com/en/datasheet/atlas/
• https://www.globalsign.com/en/blog/atlas-blogged

Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for Networks: Sub account support

• Heads up: New Site Ref ID field in SIEM logs
New Features
None.
Enhancements
DDoS Protection for Networks: Sub account support
DDoS Protection for Networks now supports sub accounts, enabling you to simplify the management of enterprise
accounts and manage user access.
You can share the connectivity configuration between the parent and sub accounts, while isolating the management
of network ranges to specific sub accounts.
In a sub account, the network dashboard and traffic analytics provide data on the specific sub account only, enabling
complete user access management.
For details, see DDoS Protection for Networks and IPs: Sub Account Support.
To enable this feature for your account, contact Imperva Support.

Heads up: New Site Ref ID field in SIEM logs
Starting February 28, 2021, we will roll out the following change to Reference ID in the SIEM log integration. The
rollout is expected to be completed during the course of the week.
The new Site Ref ID field will be added, in the following formats:
• CEF: siteTag
• LEFF: siteTag
• W3C: s-sitetag
The Site Ref ID field corresponds to the Reference ID option in the the Cloud Security Console Website General
Settings.
is implemented.

Note: There is no change to the Ref ID field in the SIEM logs. This field corresponds to the account level Reference ID
option in the Cloud Security Console Account Settings.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• Introducing account and website dashboards

• Attack Analytics: 1-click mitigation for bad IP reputation insights
• CDN: Indicator of stale content added to X-Iinfo header
• Heads up: New Site Ref ID field in SIEM logs
New Features
None.
Enhancements
Introducing account and website dashboards
We are starting to roll out a new user experience, with both new and improved dashboards in a state-of-the-art
platform.
• Account dashboard: New! The Home page provides an at-a-glance view of all of your protected assets from the
moment you log in to your account. Quickly understand the overall account status and identify what requires
your immediate attention or further investigation.
• Website dashboards: Improved security and performance website dashboards provide enhanced usability,
faster investigation, and more actionable data at the website level. The website dashboards are easily
accessible - no need to navigate to the each individual website.
Coming soon: Improved real-time website dashboard.
• Security Events page: An enhanced view for exploring the security events detected and mitigated by Imperva.
Rollout is expected to continue through April 2021.
Availability:
• The new dashboards are available only in the new UI. Featuring a new navigational structure and a clean,
streamlined experience, the new UI is currently rolling out to customers.
• Don’t want to wait? If the new UI is not yet enabled for your account, you can Opt in via a popup displayed
when you log in. This option enables the new UI for your account, as well as the new dashboards. For more
details, see Cloud Security Console.
• The existing website dashboards and website events page continue to be displayed in both the classic and new
UI.

• The Home page dashboard is displayed by default when you log in to the Cloud Security Console. Learn more:
Homepage Dashboard
• Security Events: Navigate to Application > Security Events. Learn more: View Security Events
• Website dashboards: Navigate to Application > WAF > Dashboards. Learn more: Website Dashboards
• Note: The existing Network Traffic Dashboard was moved to the new website dashboard location in the new UI.
It displays incoming traffic metrics on network layer (Layer 3/4) DDoS protection for all websites in your Imperva
account. Learn more: Network Traffic Dashboard
Attack Analytics: 1-click mitigation for bad IP reputation insights
When the Attack Analytics Insights mechanism identifies malicious traffic from IP addresses with negative
reputations, you can now turn on mitigation with a single click.
The new option automatically creates a security rule that denies access to the malicious IP for 3 days.
What changed: Previously, there was a link to open the Rules page for the relevant site, enabling you to manually
create a custom security rule.
Where it’s located: On the Insights page, click the block icon to automatically create the rule.
For more information on security rules, see Manage Rules.
For more details on Attack Analytics insights, see Actionable Insights.

Rollout of DNSSEC compliance for CNAME resolution is now complete.

What changed: When onboarding your site to Cloud WAF, Imperva provides you with a CNAME that is used both for
pointing traffic to the Imperva network, and for identifying the site in the event that multiple domains are linked
under the same Imperva site configuration and policy. The CNAME resolves to an IP address in Imperva’s DNS zone.
This enhancement completes the end-to-end chain of trust as we now sign and validate Imperva’s CNAME records
with DNSSEC.
New sites: Sites receive a CNAME from the new impervadns.net domain that supports DNSSEC.
Existing sites: Sites that were onboarded before this change are defined with the incapdns.net domain. DNSSEC is
now enabled on that domain as well.
After onboarding, you can see DNS settings for your site in the Website Settings > General page. For details, see Web
Protection - General Settings.
CDN: Indicator of stale content added to X-Iinfo header

A new value (‘c’) was added to the X-Iinfo header to indicate when stale content was served from the Imperva cache.
The X-Iinfo HTTP response header is used by Imperva to track and troubleshoot the caching of resources. You can use
it as a quick way of checking if a specific resource was cached.
Stale content can be served when the resource is not found or not fresh in the Imperva cache, and Imperva can’t
connect to the origin server. (You can define settings to determine when stale content may be served. For more
details, see Cache Settings.)
For more details on the X-Iinfo header, see Troubleshoot caching.

Heads up: New Site Ref ID field in SIEM logs
Starting February 28, 2021, we will roll out the following change to Reference ID in the SIEM log integration. The
rollout is expected to be completed during the course of the week.
The new Site Ref ID field will be added, in the following formats:
• CEF: siteTag
• LEFF: siteTag
• W3C: s-sitetag
The Site Ref ID field corresponds to the Reference ID option in the the Cloud Security Console Website General
Settings.

is implemented.
Note: There is no change to the Ref ID field in the SIEM logs. This field corresponds to the account level Reference ID
option in the Cloud Security Console Account Settings.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
New Features
None.
Enhancements
None.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• Cloud security self-service trial

• New and improved DNS Protection Service: Rollout complete
• Imperva Security Mobile App: Now available for Android
• CDN: New custom cache rule action to serve stale content
• Attack Analytics: 1-click mitigation for misconfigured WAF settings
• Attack Analytics: New incident graph functionality
• Audit Trail API v2
New Features
Cloud security self-service trial
On Monday, February 1, 2021, we are introducing a free, self-service trial, enabling you to experience Imperva's cloud
services for yourself.
The trial includes a wide variety of Imperva features and services. with optional add-ons available to try out as well.
For more details on the trial, see Imperva Cloud Security Trial.
To start the trial, visit https://www.imperva.com/free-trial/.
Note: If you are an existing customer interested in a trial for a service you do not currently subscribe to, please contact
an Imperva Sales Representative.
New and improved DNS Protection Service: Rollout complete
We have completed rollout of the new DNS Protection service, now available to all existing accounts and new
customers.
The new DNS Protection service includes both Managed DNS and Protected (Proxy) DNS, along with a new UI and
API.
What changed: Imperva DNS Protection now includes the following components:
• Protected DNS: The existing DNS Protection service provided by Imperva. Imperva serves as a DNS proxy,
where DNS queries are first processed by Imperva to filter out DDoS attacks before being forwarded to your
origin name server. With this solution, your DNS service is hosted outside of Imperva.
Existing DDoS Protection for DNS customer accounts were migrated to the new Proxy DNS component, which
includes an enhanced user interface and full API coverage. You can now also onboard your DNS zones to the
new Managed DNS service.
• Managed DNS: Our new offering of an end-to-end service as a DNS hosting provider. With this solution, your
DNS service is hosted within Imperva.

With Managed DNS, Imperva serves as the DNS records host and authoritative DNS, providing definitive
responses to DNS queries, as well as protecting you from Volumetric and DNS DDoS attack.
• DNS Protection dashboard and analytics:
A new dashboard was added, providing an at-a-glance view of metrics and advanced analytics for your
protected and managed DNS zones. View the number of queries per zone, a breakdown of passed vs. blocked
queries, top source IP addresses, and more.
Benefits of Managed DNS:
• Increased performance, reducing DNS queries response time via Imperva’s global anycast network of 45 PoPs
• Easy onboarding & migration via simplified UI and API
• Complete management of your DNS configuration within Imperva
• Built-in security, with L3/L4/L7 DDoS attack mitigation
More information:
• DNS Protection
• Onboard DNS Protection
Imperva Security Mobile App: Now available for Android
Cloud WAF customers can now take advantage of the Imperva Security mobile app, now also available for Android.
• View your Cloud Application Security dashboards on the go.
• Stay up-to-date with real-time push notifications on critical events.
• Drill down for more details.
What changed: Previously, the app was available for iOS and Mac only.
Download: You can download the app for Android directly from the Google Play Store at https://play.google.com/
store/apps/details?id=com.app.imperva.
For more information on the app, see Imperva Security Mobile App.
Enhancements
CDN: New custom cache rule action to serve stale content
A new action was added for custom cache rules, enabling you to define a TTL for serving stale content for specific
resource types.
When Imperva can't connect to the origin server, stale content is served instead of displaying an error to end users.
Availability: This feature is currently being rolled out and is expected to be available to all customers as of February
11, 2021.
What changed: Previously, there was only an option to enable a global setting to serve stale content for all cached
resources.

Where it’s located: On the Cache Settings page, under Custom Cache Rules. For details, see Cache Settings.
Note:
• When there is at least one enabled Serve Stale Content custom rule, the global Serve Stale Content option is
automatically enabled if it was not already, but does not apply globally and cannot be modified. The custom
rules override the global setting.
• The new action is also available in the API. For details, see Cache Settings API Definition.
Attack Analytics: 1-click mitigation for misconfigured WAF settings
When the Attack Analytics Insights mechanism identifies a misconfigured WAF setting, you can now turn on
mitigation with a single click.
What changed: Previously, there was a link to open the WAF Settings for the relevant site, requiring to manually
change the setting.
Where it’s located: On the Insights page, click the block icon to change the site’s setting from Alert Only to Block
Request for the specified threat type.
For more options, such as Block IP or Block User, go to the WAF Settings page.
For more details, see Actionable Insights.

Attack Analytics: New incident graph functionality
The following enhancements were made to the Incidents graph.

• View the graph as an area chart or a column chart. Easily switch between views.
• Click and drag an area of the graph to zoom in for a closer look.

>
Note: Zooming in changes the view in the graph only and does not affect other data displayed on the page.
• Click a section of a column to open the Incidents page to drill down into the associated incidents.

Audit Trail API v2

To better align with REST API standards and best practices, we are introducing a new version of the Audit Trail API.
What changed:
• Audit Trail API v1 is now deprecated. For details on the deprecation policy for Imperva SaaS products, see API
Lifecycle & Deprecation Policy.
• Audit Trail API v2 is now available. For details, see Audit Trail API Definition.
• The API response in both versions now also includes the user_details parameter, providing information on who
performed the action.
Security Mitigation
Fixes
None.
Known Issues
None.



In this release:
• API Security settings are moving

• Attack Analytics: Change in date range starting time
• Client-Side Protection: Visibility into Google Analytics IDs
• Edge services navigation update
New Features
None.
Enhancements
API Security settings are moving
The API Security settings are moving from the Website General Settings page to the API Security Site Configuration
page.
Settings for existing sites are being migrated over the next 2 weeks. When complete, the settings will be visible within
API Security.
Note: The settings that were already defined for an existing site will remain the same after the change.
Before:
After:
Attack Analytics: Change in date range starting time

To align with other Imperva dashboards, data displayed in Attack Analytics for a given time range now starts at 00:00
on the start date of the time range.

Previously, the time range spanned from the current time back to the same time on the start date of the time range.
For example, the data that is now displayed for this selection of the last 7 days covers the time range from 00:00 on
January 17th through the current time on January 24th.
Note: There is no change to time ranges in the following:
• SIEM logs: The time range begins at 00:00 of the start date.
• Attack Analytics API: You select a custom time range according to the UNIX time stamp.
Client-Side Protection: Visibility into Google Analytics IDs
Gain visibility into Google Analytics IDs getting data from your website to ensure data is not transferred to
unauthorized Google Analytics accounts.
This new capability helps protect you from Magecart attacks that leverage Google Analytics.
Where it’s located: On the Client-Side Protection dashboard, under the service name, Analytics IDs shows the
amount of IDs identified for the service. Applies to the Google LLC service only.
When you click Details to view more information for the service, you can view the individual IDs:


Edge services navigation update
The Edge services section was restructured and renamed in the Cloud Security Console’s new navigation model.
The Edge section was restructured as follows:
• DDoS Protection for Networks > moved under Network Protection

• DDoS Protection for Individual IPs > moved under IP Protection
In addition, the menu names and page names have been updated as follows:
• Protected Networks > Protection Settings

• Monitored Networks > Monitoring Settings
• Network Settings > Connectivity Settings
• Protected IPs > Settings

Security Mitigation
Fixes
None.
Known Issues
None.



In this release:
• Account Usage Report

• Aggregated statistics in weekly report
• Two-factor authentication users not required to change password
• New difficulty level added to GeeTest CAPTCHA
New Features
Account Usage Report
The new usage report displays bandwidth usage history for an account. It provides you with a view of your bandwidth
usage per service over time, enabling you to easily understand usage trends and quickly detect overages in your
account.
When a row in the table is expanded, a breakdown of usage for each service is displayed.

Availability: The feature is currently rolling out through March 2021. To request access to the new report at an earlier
date, contact Support.
• Classic UI: On the sidebar, select Management > Usage Report.
• New navigation (also currently rolling out): On the top menu bar, select Account > Account Management. On
the sidebar, select Usage Report.
The billing and actual usage data is also available via the API.
For more information, see View Account Usage.
Enhancements
Aggregated statistics in weekly report
The statistics presented in the weekly report for an account with sub accounts (the parent account) now include all of
the sub accounts as well.
Note:
• Because weekly reports contain comparative information between last week and the previous week, it will take
two weeks until the report will present all information with accurate comparisons.
• In addition to the report for the parent account, a report can be generated separately for each sub account and
includes only the statistics for the specific sub account.
For more details on the weekly report, see Account Settings.

Two-factor authentication users not required to change password
Users are currently required to change their password every 90 days to enhance their account security and to cater to
compliance requirements. As of this release, if the more secure two-factor authentication process is enabled for a
user, they will not be required to periodically change their password.

Note:
• Users can set two-factor authentication for themselves. For details, see User Preferences.
• The account admin can also enforce two-factor authentication for all account users. For details, see Account
Settings.
• For more details on the password policy, see Password Policy.

New difficulty level added to GeeTest CAPTCHA
A more difficult CAPTCHA challenge was added to the GeeTest CAPTCHA.
In addition to the Auto, Normal, and Hard difficulty levels, the Extra Hard level was added.
Availability: The GeeTest CAPTCHA is available to Advanced Bot Protection and Account Takeover Protection
customers only.
For details, see Website Security Settings.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• New navigational structure in the Cloud Security Console

• Lock your origin according to certificate fingerprint
• Unverified users are locked out
• Account bandwidth overage email notifications are sent
New Features
None.
Enhancements
New navigational structure in the Cloud Security Console
We are starting to gradually roll out a new navigational structure in the Cloud Security Console. The new format aligns
with Imperva’s offering categories (Application, Edge, Data), addresses scalability and usability issues, and reduces
time to navigate. Rollout is expected to continue through April 2021.
Once the new structure is enabled for your account, it is automatically displayed when you log in to the Cloud Security
Console.
To return to the old layout for the duration of your browser session, select Account > Switch to Classic UI on the
banner.
For more details, see Cloud Security Console.

Lock your origin according to certificate fingerprint

The Origin Lock feature can now be configured according to the SHA-1 fingerprint of your origin server certificate.
Origin Lock associates a specific IP or fingerprint with your account, preventing other accounts on the Imperva service
from setting up sites that forward traffic to your origin server.
Previously, the origin lock feature could only be configured according to origin server IP / Range. Using the fingerprint
provides a solution for using Origin Lock when your site uses dynamic IP addresses.
For more details on the Origin Lock feature, see Account Settings.
Unverified users are locked out
When a user is created in an account, a verification link is sent to the email address listed for the user. The new user
must click the link in the email to verify their address and set a login password.
What changed: The following changes were made to the email verification process:
The following users will receive 3 email reminders and must click the link to verify their address within 15 days or will
be locked out. The user:
• was created since January 1, 2020 or last logged in after January 1, 2020
• and created an API Key/ID for their user
• and has not verified their email address
The following users are now locked out. The user:
• was created before January 1, 2020 or last logged in before January 1, 2020
• and did not create an API Key/ID for their user
• and has not verified their email address
Locked users: Users who are locked out because they did not verify their email address will receive an email when
they try to log in. The mail includes a link to verify their email address and unlock their user.
For more information on adding users, see Account Users.
Security Mitigation

Fixes
Account bandwidth overage email notifications are sent
Problem: Some customers did not receive email notification of overages in their account.
Resolution: Overage notifications are now sent at the end of the billing period when your account usage has
exceeded the amount included in your billing plan.
Note: These email notifications are not directly connected to billing. Billing statements were unaffected and
accurately reflected usage and overages.
Known Issues
None.


In this release:
• Introducing the Managed DNS Service

• DDoS Protection for Networks: Configure GRE tunnel connections
• DDoS Protection for Networks: Self-adaptive DDoS security policies
• API Security updates
• Heads Up: New navigational structure in the Cloud Security Console
New Features
Introducing the Managed DNS Service
We are starting a gradual rollout of our new Managed DNS service, with an end-to-end service as a DNS hosting
provider.
Imperva serves as the DNS records host and authoritative DNS, providing definitive responses to DNS queries, as well
as protecting you from Volumetric and DNS DDoS attack.
What’s changing: The Imperva DDoS Protection for DNS will now transition to a Protected DNS solution and will
include two components:
• Proxy DNS: The existing DNS Protection service provided by Imperva. Imperva serves as a DNS proxy, where
DNS queries are first processed by Imperva to filter out DDoS attacks before being forwarded to your origin
name server. With this solution, your DNS service is hosted outside of Imperva.
• Managed DNS: Our new offering. With this solution, your DNS service is hosted within Imperva.
Rollout and migration:
The rollout process is expected to continue through the end of January 2021.
During rollout, existing DDoS Protection for DNS customer accounts will be migrated to the new Proxy DNS
component, which will include an enhanced user interface and full API coverage. After migration, you can also
onboard your DNS zones to the new Managed DNS service.
When rollout is complete, the new service including both Managed DNS and Proxy DNS, along with the new UI and
API, will be available to all other existing accounts and new customers.

To request access to the new service at an earlier date, contact Support.
More information:
• DNS Protection
Enhancements
DDoS Protection for Networks: Configure GRE tunnel connections
DDoS Protection for Networks customers can now configure GRE tunnel connections via the Cloud Security Console UI
or API.
What changed: After onboarding to the DDoS Protection for Networks service, you may want to edit or add new
connections. For example, if you change ISP or want to create new GRE tunnels. You can now do this via the Cloud
Security Console or API, for GRE-Tunnel type only. Other connection types must be configured by the Imperva team.
This is the first step in self-service configuration for the DDoS protection for Networks service. Additional functionality
is planned for future releases.
Where it’s located: On the Cloud Security Console sidebar, click Infrastructure > Network Settings.
For details, see Add a GRE tunnel connection.

DDoS Protection for Networks: Self-adaptive DDoS security policies
Imperva is introducing a new feature that automatically generates and updates DDoS security policies based on a
machine-learning algorithm that continuously analyzes the assets’ (networks, IPs) traffic rates and patterns.
Imperva’s SD-SOC (Software-Defined Security Operations Center) is designed to enhance the DDoS Protection for
Networks solution for the protected assets under our service. By automating security policy profiling, the risk of false
positives/negatives is significantly reduced as the policy is continuously aligned with the current traffic behavior.
What changed: Previously, security policies were defined and implemented manually for each asset by Imperva’s
SOC. These policies are now automatically updated and periodically reviewed by Imperva’s SOC as needed.
Availability: Currently available for Always-On customers only. Support for On-Demand customers will be available at
a later date.
Migration: We are starting migration of existing DDoS Protection for Networks Always-On customer accounts. Note
that:
• You will be notified directly by Imperva before migration, and asked to confirm the migration date scheduled
for your account.
• Migration is seamless and does not require you to make any configuration changes.
For more details on DDoS security policies, see Security Policy and Mitigation.
API Security updates
The following changes were implemented for API Security:

API Configuration:
• The API Configuration page was enhanced to enable you to set different configurations for the violation types:
Invalid URL, Invalid Method, Missing Parameter and Invalid Parameter Value violations.
• The APIs table filtering capabilities were also enhanced. You can now perform a search, select the option to
show only modified specs/endpoints, and filter each violation type column.
Site Configuration: This new page enables you to set a site level configuration that acts as the default configuration
for all APIs under it. You can now view and configure the default actions for the Invalid URL, Invalid Method, Missing
Parameter and Invalid Parameter Value violations.
For more information, see API Configuration.

Heads Up: New navigational structure in the Cloud Security Console
Over the next several weeks, we are starting to gradually roll out a new navigational structure in the Cloud Security
Console. The new format aligns with Imperva’s offering categories (Application, Edge, Data), addresses scalability and
usability issues, and reduces time to navigate. Rollout is expected to continue through April 2021.
Once the new structure is enabled for your account, it is automatically displayed when you log in to the Cloud Security
Console.

To return to the old layout for the duration of your browser session, select Account > Switch to Classic UI on the
banner.
For more details, see Cloud Security Console.
Security Mitigation
Fixes
None.
Known Issues
None.




In this release:
• Heads Up: Introducing the Managed DNS Service

• Unverified users are locked out
• Client-Side Protection: Add services to a pre-approved list
• Get Site Status API Update
• Policy Management API Update
• Updated error page
• Imperva SaaS service email change
New Features
Heads Up: Introducing the Managed DNS Service
We are starting a gradual rollout of our new Managed DNS service, with an end-to-end service as a DNS hosting
provider.
as protecting you from Volumetric and DNS DDoS attack.
What’s changing: The Imperva DDoS Protection for DNS will now transition to a Protected DNS solution and will
include two components:
• Proxy DNS: The existing DNS Protection service provided by Imperva. Imperva serves as a DNS proxy, where all
DNS queries are first processed by Imperva to filter out DDoS attacks before being forwarded to your origin
name server. With this solution, your DNS service is hosted outside of Imperva.
• Managed DNS: Our new offering. With this solution, your DNS service is hosted within Imperva.
Rollout:
• Phase 1 (Through January 24, 2021):
Existing DDoS Protection for DNS customer accounts are migrated to the new Proxy DNS component, which
will include:
• An enhanced user interface

• Full API coverage
• The option to transition any DNS zone to the new Managed DNS service
• Phase 2 (Starting January 24, 2021)
Managed DNS is available to all other existing accounts and new customers.
Details on onboarding the new Managed DNS service will follow in future release notes.
Enhancements
Unverified users are locked out
New users are now required to verify their email address within 15 days or the user will be locked.
• When a new user is created in an account, a verification link is sent to the email address listed for the user. The
new user must click the link in the email to verify their address and set a login password.
• If the user does not verify their email address within 15 days after the user was created, the user is locked out.
To unlock the user, contact Imperva Support.
• Notification emails are sent to the user before the user is locked, as a reminder to verify their email address. The
address verification link is included in the mail.
• When users are locked out, the account admin user receives an email notification with the list of unverified
users in the account.
Note: Applies only to users who are added to the system on or after November 13, 2020.
For more information on adding users, see Account Users.

Client-Side Protection: Add services to a pre-approved list
Give Client-Side Protection permission to approve specific services that you consider trusted and safe, without the
need for you to first review them.
What changed: You can now add specific domain names to a pre-approved list, with the option to include
subdomains. If and when these domains are discovered by Client-Side Protection, they are automatically approved
and marked as Allowed. In addition, an entry is logged to the Audit Trail indicating that the domain was allowed
based on the pre-approved list.
Where it’s located: On the Client-Side Protection dashboard, click Pre-approve Services.

Get Site Status API Update

Two parameters were added to the Get Site Status API response:
If your site is using a custom certificate, the Get Site Status API response returns details of the certificate’s fingerprint
and serial number. This can be useful when integrating with an external certificate management system, such as
Venafi.
Availability: Applies to custom certificates uploaded after the feature is implemented only.
Where it’s located: The fingerPrint and serialNumber parameters were added to the custom certificate section of
the response.
For more details on Get Site Status, see Site Management API.
Policy Management API Update
The following changes were made to the Policy Management API:
API Before the change After the change
The functionality was fixed.

Removes the previously applied
PUT /v2/assets/{assetType}/ assets from the specified policy
Applies a single policy to a single
{assetId}/policies/{policyId} (Performs a full update of the
asset and removes the previously
assets in the policy.)
applied policies from the asset.
The functionality was added.

PATCH /v2/policies/{policyId}/
N/A Applies a single policy to a single
{assetType}/{assetId}
applied assets from the policy.
For more information on Policy Management, see:

Updated error page
The default Imperva error page template was updated. This page is displayed to website visitors when they try to
access your site or application and encounter an error.
For more details, see Cloud WAF Error Pages and Codes.

Note: There is no change for sites using custom error pages, as described here: Custom Error Pages.
Imperva SaaS service email change
The email sender name and address for mail notifications sent by the Cloud Security Console have changed from
Incapsula Service no_reply@incapsula.com to Imperva Service no_reply@out.imperva.com.
Security Mitigation
Fixes
None.
Known Issues
None.



In this release:

• Application Delivery: New rule filter parameter - Response Code
• Attack Analytics: Visibility into IP Risk Score for incidents
• Client-Side Protection: Self-service trial
• Heads Up: Get Site Status API Update
• Heads Up: Imperva SaaS service email change
New Features
None.
Enhancements
We are starting a gradual rollout of DNSSEC compliance for CNAME resolution.
What changed: When onboarding your site to Cloud WAF, Imperva provides you with a CNAME that is used both for
pointing traffic to the Imperva network, and for identifying the site in the event that multiple domains are linked
under the same Imperva site configuration and policy. The CNAME resolves to an IP address in Imperva’s DNS zone.
The upcoming enhancement completes the end-to-end chain of trust as we will now sign and validate Imperva’s
CNAME records with DNSSEC.
Rollout:
• The feature will apply initially to newly added sites only. During onboarding, sites will receive a CNAME from the
new impervadns.net domain that supports DNSSEC.
• DNSSEC will be supported for existing sites at a later point, when DNSSEC is enabled on the incapdns.net
domain. Rollout is expected to continue through January 2021.
For details on onboarding, see Onboarding a Site – Web Protection and CDN.
After onboarding, you can see DNS settings for your site in the Website Settings > General page. For details, see Web
Protection - General Settings.

Application Delivery: New rule filter parameter - Response Code

The new Response Code rule filter parameter enables you to define an action to take based on the HTTP response
code Imperva receives from the origin server.
For example, you can rewrite responses or set caching rules according to the response code.
Where it’s located: In the Cloud Security Console, when adding or editing a custom response rule or a cache rule,
under Rule Filter.
For more details, see Rule Filter Parameters.

Attack Analytics: Visibility into IP Risk Score for incidents
Attack Analytics incident details now include the IP Risk Score of the attacking IPs, provided by Imperva Reputation
Intelligence.
The IP Score is taken from Reputation Intelligence at the time of attack, and provides an assessment of the risk level
posed by the attacking IP.
For more information on the risk score, see the Reputation Intelligence documentation.
• On the Incidents page. For more details, see View Incidents.

• On the Incident Details page. For more details, see View Incident Details.

Client-Side Protection: Self-service trial

The free Client-Side Protection 30-day trial is now available to our Cloud WAF customers directly from the Cloud
Security Console, without the involvement of an Imperva sales representative.
Client-Side Protection guards your customers’ data from theft through client-side attacks like digital skimming, supply
Where it’s located: On the Cloud Security Console sidebar, click Client-Side Protection, and click the Try it for free
button.
For details, see Get Started.

Heads Up: Get Site Status API Update
On December 13, 2020, we will add two parameters to the Get Site Status API response:
If your site is using a custom certificate, the Get Site Status API response will return details of the certificate’s
fingerprint and serial number. This can be useful when integrating with an external certificate management system,
such as Venafi.
Availability: Applies to custom certificates uploaded after the feature is implemented only.
Where it’s located: The fingerPrint and serialNumber parameters will be added to the custom certificate section of
the response.
For more details on Get Site Status, see Site Management API.

Heads Up: Imperva SaaS service email change

On December 13, 2020, the email sender name and address for mail notifications sent by the Cloud Security Console
are changing from Incapsula Service no_reply@incapsula.com to Imperva Service no_reply@out.imperva.com.
Security Mitigation
Fixes
None.
Known Issues
None.


In this release:
• New Imperva Data Center in Santiago, Chile

• New permissions limit access to Account Takeover Protection and Client-Side Protection configuration
• Update: Migration to the new GlobalSign Atlas platform
• Heads Up: Policy Management API Update
• Change in weekly report
New Features
None.
Enhancements
New Imperva Data Center in Santiago, Chile
We are starting to rollout a new PoP in Santiago, Chile and expect it to be fully functional within the next few weeks.
The Chile PoP is the newest addition to our world-wide network of 44 data centers, helping you deliver your
New permissions limit access to Account Takeover Protection and Client-
Side Protection configuration
The following permissions are now required for onboarding new sites, removing sites, changing mitigation options,
and modifying other settings in the associated service:
• Account Takeover Protection: Edit ATO configuration

• Client-Side Protection: Edit CSP configuration
By default, the account admin user has full permissions, and other users have read-only access, without the ability to
make changes to configuration settings. The account admin can grant the appropriate permissions to additional
users, as needed.
For instructions on defining user permissions, see Manage Roles and Permissions.
Update: Migration to the new GlobalSign Atlas platform
In response to customer feedback, the certificate migration process has been extended and is now expected to be
completed in February 2021. This extension enables us to bypass the deployment of non-critical changes during the
end of year high-impact time.
Background: For improved security and performance, we are now moving to the new GlobalSign Atlas Platform for
ordering and maintaining new SSL certificates. This platform is replacing the GlobalSign CloudSSL service that was
used until now.
To support this change, we are migrating all of our existing GlobalSign CloudSSL certificates to the new platform.

Impact:
successfully.
Note that if the validation is not completed by February 2021, the pending Imperva SSL certificate will expire.
Heads Up: Policy Management API Update
On December 13, 2020 the following changes will be implemented in the Policy Management API:
The functionality was fixed.

Removes the previously applied
PUT /v2/assets/{assetType}/ assets from the specified policy
{assetId}/policies/{policyId} (Performs a full update of the
assets in the policy.)
applied policies from the asset.
PATCH /v2/policies/{policyId}/
N/A
{assetType}/{assetId} The functionality was added.


applied assets from the policy.
For more information on Policy Management, see:
Fixes
Change in weekly report
The report was aligned to accurately reflect the last 7 days of activity.
What changed:
• All statistics now report data for the last 7 days. Previously, the report was showing statistics from the previous 8
days for top sites.
• The report dates were adjusted to accurately reflect the last 7 days. For example, a report generated on October
30 now displays the date range of October 23-October 29, instead of October 23-October 30.
Known Issues
None.


In this release:
• Account Takeover Protection: View top successful user logins

• DDoS Protection: Export and Share Network Layer Analytics Reports
• CDN: API Documentation Update
New Features
None.
Enhancements
Account Takeover Protection: View top successful user logins
View the list of users that have the most successful logins, along with the risk level that ATO Protection has assigned to
them.
Users with high risk probability who are successfully logging in are a good indication of user accounts that are
compromised and being used in an attack.
Where it’s located: On the Account Takeover Protection Dashboard, in the Top Visitors table.
For more details, see Explore the Data in the ATO Protection documentation.
DDoS Protection: Export and Share Network Layer Analytics Reports
Options for exporting and sharing network layer analytics were added.
What changed: Two buttons were added to the DDoS Protection for Networks Analytics and Network Traffic
Analytics pages.
• Export to PDF: Downloads a PDF file that includes a snapshot of the current view of the dashboard.
• Copy URL: Copies the URL to the clipboard, enabling you to share a link with others. (Users must log in to the
Cloud Security Console to access the analytics pages.)
For more details on analytics, see:
• Analytics: DDoS Protection for Networks and IPs
• Network Traffic Dashboard

CDN: API Documentation Update

For improved clarity and usability, the Application Delivery API documentation has been updated. There is no change
to the actual APIs.
What changed: The Performance Settings API Definition (Swagger) file has been divided into separate documents
according to cache, delivery, and load balancing settings.
• Cache Settings API Definition
• Delivery Settings API Definition
• Load Balancing Settings API Definition
Fixes
None.
Known Issues
None.


In this release:
• Define a custom error page for each error type

• Client-Side Protection: Download a report
• DDoS Protection for Individual IPs: API Update
New Features
None.
Enhancements
Define a custom error page for each error type
Define a separate custom error page for each type of error that Imperva presents to your website visitors.
What changed: Previously, you could define only a single custom error page for all error types.
Where it’s located: On the Cloud Security Console sidebar, click Websites > Delivery and scroll to the Custom Error
Page section.
Note: There is no change to existing custom error pages. If you have already defined a custom error page for your site,
it will continue to be used for all error types. No action is required.
For more details, see Custom Error Pages.

Client-Side Protection: Download a report
Download a report for your protected website in CSV format. The report includes the list of discovered website
services used by your application, as well as additional details about the services.

Where it's located: On the Client-Side Protection dashboard. For more details, see Dashboard.
DDoS Protection for Individual IPs: API Update

The following changes were made to the Protected IP APIs:
• GET methods were added, enabling you to retrieve details of your protected IPs.
• The methods for editing your protected IPs were changed from POST to PUT.
For details, see Protected IP API Definition.
Fixes
None.
Known Issues
None.


In this release:
• Attack Analytics API change

• Updated error page for connectivity issues
New Features
None.
Enhancements
Attack Analytics API change
The insight type MALICIOUS_IP_IN_WHITELIST_INSIGHT was renamed MALICIOUS_IP_IN_ALLOWLIST_INSIGHT.
Details:
The GET /v1/insights API returns details of actionable insights that were detected for your account. The API response
includes the insight type, in which the value MALICIOUS_IP_IN_WHITELIST_INSIGHT was changed to
MALICIOUS_IP_IN_ALLOWLIST_INSIGHT.
For more details on insights, see Actionable Insights.
For more details on the Attack Analytics API, see Attack Analytics API Definition.
Updated error page for connectivity issues
The error page displayed to website visitors when the Imperva proxy cannot connect to your origin server was
updated.
The new page provides additional guidance to you and to your visitors to help understand and troubleshoot the
problem.

Fixes
None.
Known Issues
None.


In this release:
• Policy Migration Update
New Features
None.
Enhancements
Policy Migration Update
We are resuming automatic migration of existing enterprise and FlexProtect customer accounts to Policy
Management. Policies enable you to centrally configure settings and apply them to sites in your account.
Policies are migrated at the parent account level. If your account has sub accounts, you can manually restrict the
viewing and editing of policies to specific sub accounts after migration.
For details on Policy Management and migration, see Create and Manage Policies.
Fixes
None.
Known Issues
None.


In this release:
• CDN: Configure weighted load balancing

• Attack Analytics insight renamed
• Migration to the new GlobalSign Atlas platform
• Statistics temporarily unavailable for accounts using Policy Management
• Heads Up: Attack Analytics API change
New Features
None.
Enhancements
CDN: Configure weighted load balancing
Assign weights to your data centers and origin servers to gain more precise control over the distribution of load
between them.
You can define a load balancing ratio to distribute load across your data centers, as well as a ratio for servers within a
data center.
What changed: Adds the option to define a predefined load balancing ratio in addition to the existing performance
and geo-targeting load balancing methods.
• In the Cloud Security Console Website Settings > Origin Servers page. For details, see Load Balancing Settings.
• Via the API. For details, see Cache Settings API Definition.
For more details, see Weighted Load Balancing.

Attack Analytics insight renamed
The Whitelist vulnerabilities insight was renamed Allowlist vulnerabilities.
For more details on Attack Analytics insights, see Actionable Insights.

Migration to the new GlobalSign Atlas platform
For improved security and performance, we are now moving to the new GlobalSign Atlas Platform for ordering and
maintaining new SSL certificates. This platform is replacing the GlobalSign CloudSSL service that was used until now.
To support this change, we are migrating all of our existing GlobalSign CloudSSL certificates to the new platform
starting today, October 11, 2020. Cloud SSL will be gradually phased out and is expected to be decommissioned by
November 22, 2020.
Impact:

successfully.
Note that if the validation is not completed by November 22, 2020 , the pending Imperva SSL certificate will
expire.
Statistics temporarily unavailable for accounts using Policy Management
In accounts that have already migrated to Policy Management, the following website statistics are not currently
available:
• Visitors from blacklisted IPs

• Visitors from blacklisted Countries
• Visitors from blacklisted URLs
What changed: If you are using the new Policies feature, the values of blocked IPs, requests, and sessions are not
counted at the site level, and are therefore hidden in the UI, and removed from the API. We are currently working on
providing these statistics within the framework of Policy Management.
Where it’s located: In accounts that have migrated to Policy Management, these statistics were removed from the
following locations:
• Cloud Security Console: In the Website Dashboard > Security page, under Threats.

• Weekly Report: These statistics are also currently unavailable in the weekly report that is sent to accounts that
have subscribed to receive it using the option in Account Settings.
• API: These statistics are not provided by the Get Statistics API for a site (/api/stats/v1).
Heads Up: Attack Analytics API change
On October 25, 2020, the following change will be made in the Attack Analytics API:
The insight type MALICIOUS_IP_IN_WHITELIST_INSIGHT will be changed to MALICIOUS_IP_IN_ALLOWLIST_INSIGHT.
Details:
The GET /v1/insights API returns details of actionable insights that were detected for your account. The API response
includes the insight type, which currently includes the value MALICIOUS_IP_IN_WHITELIST_INSIGHT as one possible
value. This value will be changed to MALICIOUS_IP_IN_ALLOWLIST_INSIGHT.
For more details on insights, see Actionable Insights.
For more details on the Attack Analytics API, see Attack Analytics API Definition.
Fixes
None.
Known Issues
None.


In this release:
• Attack Analytics: Snooze insights for later

• DDoS Protection for Networks: Routing optimization for network ranges now supported for cross connect
• Delivery Rules: Remove multiple occurrences of a header
• DNS bandwidth removed from “Always On” bandwidth usage
• Email notification before API key expiration
• Heads Up: Policy Migration Update
• Heads Up: Migration to the new GlobalSign Atlas Platform
New Features
None.
Enhancements
Attack Analytics: Snooze insights for later
Temporarily hide an insight to review at a later time.
1. On the Attack Analytics banner, click Insights.
2. Hover over an insight row and click the Snooze button .
3. Select a duration and click Set.

Snoozed insights are listed in the Snoozed section in the left pane.
For more details, see Actionable Insights.

DDoS Protection for Networks: Routing optimization for network ranges
now supported for cross connect
A recent enhancement to Imperva’s software-defined network range advertisement is now available for cross connect
customers, in addition to customers connecting via a GRE tunnel.
What changed: Imperva’s software-defined network range advertisement was recently enhanced to advertise
customer IP ranges from all Imperva PoPs in the region where the customer data center is located. Previously,

customer IP ranges were advertised only from the PoPs to which the customer was connected via a GRE tunnel, as
well as from our higher-capacity PoPs outside of the region.
This change is expected to result in improved performance, whether or not you are under attack. The new method
provides better DDoS handling, as more PoPs take part in traffic scrubbing.
Note:
• This change does not impact data storage regulation. User data continues to be stored only in the region that is
defined in Account Settings.
• With this method, traffic flows through a GRE connection which lowers the MTU of each packet by 24 bytes,
requiring you to adjust your TCP-MSS.
Availability: To activate routing optimization for network ranges for cross-connect, contact Imperva Support.
For more details on Imperva's software-defined network range advertisement, see Introduction: DDoS Protection for
Networks.
For more details on DDoS Protection for Networks over cross connect, see Direct Connection.
Delivery Rules: Remove multiple occurrences of a header
You can now remove all occurrences of a specified header from a request or response.
What changed: Previously, only the first occurrence of the header was removed. An additional rule was required to
remove each additional header.
Where it’s located: On the Cloud Security Console’s Rules page, when creating or editing a Remove Request Header
or Remove Response Header rule, select the option to Remove multiple header occurrences. For details, see Create
Rules.

DNS bandwidth removed from “Always On” bandwidth usage

DNS Protection was removed from the Always On Bandwidth calculation for billing purposes. The Always On
Bandwidth package includes bandwidth usage from multiple services.
Impact: This change will be reflected in lower reported bandwidth usage, although the portion of bandwidth usage by
the DNS Protection service is typically negligible. You can therefore expect minimal if any change in your account’s
bill. For details on how Imperva calculates your bandwidth for billing, see Account Bandwidth Calculation.
Where it’s located: Bandwidth usage is displayed in the Cloud Security Console’s Subscription page.
Email notification before API key expiration

If you set an expiration date for your API key, an email notification is sent to you before the API key expires. The email
includes a link enabling you to extend the validity of the API key for two weeks.
For details on setting an expiration date, see API Key Management.

Heads Up: Policy Migration Update
Automatic migration of existing enterprise and FlexProtect customer accounts to Policy Management resumes on
October 18, 2020.
Policies are migrated at the parent account level, although the option to restrict the viewing and editing of a policy to
a specific sub account was recently introduced.
If your account has sub accounts and you want your policies to be separated by sub account:
• If your account was already migrated, you can manually restrict policies to specific sub accounts using the UI or
API.
• If your account has not yet been migrated and you would like Imperva to automatically migrate your account
policies to your sub accounts, contact Imperva Support to request this option before October 18th.
For details on Policy Management, see Create and Manage Policies.

Heads Up: Migration to the new GlobalSign Atlas Platform
As previously announced, we are moving to the new GlobalSign Atlas Platform, and migrating all of our existing
GlobalSign CloudSSL certificates to the new platform.
• In order to implement critical enhancements to the process, migration was postponed and is now scheduled to
start on October 11, 2020.
• GlobalSign Atlas is now using the following CA for issuing new certificates: GlobalSign Atlas R3 DV TLS CA 2020.
Certificates issued by the old Atlas CA (GlobalSign HV RSA DV SSL CA 2018) are scheduled to be revoked on

October 21, 2020. To prepare for this change, all Imperva certificates issued by the old Atlas CA will be reissued
using the new Atlas CA starting October 11, 2020.
For details on the impact of migration and reissuing of the certificates, see the August 16, 2020 Release Notes.
Fixes
None.
Known Issues
None.


In this release:
• Heads Up: DNSSEC compliance for DNS CNAME resolution
New Features
None.
Enhancements
Heads Up: DNSSEC compliance for DNS CNAME resolution
On November 15, 2020, we are starting a gradual rollout of DNSSEC compliance for CNAME resolution. Rollout of this
feature was previously scheduled for September but was postponed in order to enhance the stability of the service.
What changed: During the existing process of onboarding your site to Cloud WAF, Imperva provides you with a CNAME
that is used both for pointing traffic to the Imperva network, and for identifying the site in the event that multiple
domains are linked under the same Imperva site configuration and policy. The CNAME resolves to an IP address in
Imperva’s DNS zone. The upcoming enhancement completes the end-to-end chain of trust as we will now sign and
validate Imperva’s CNAME records with DNSSEC.
Fixes
None.
Known Issues
None.


In this release:
• Heads Up: DNS bandwidth removed from “Always On” bandwidth usage
New Features
None.
Enhancements
Heads Up: DNS bandwidth removed from “Always On” bandwidth usage
The Always On Bandwidth package includes bandwidth usage from multiple services. On October 4, 2020, DNS
Protection will be removed from the Always On Bandwidth calculation for billing purposes.
Impact: This change will be reflected in lower reported bandwidth usage, although the portion of bandwidth usage by
the DNS Protection service is typically negligible. You can therefore expect minimal if any change in your account’s
bill. For details on how Imperva calculates your bandwidth for billing, see Account Bandwidth Calculation.
Where it’s located: Bandwidth usage is displayed in the Cloud Security Console’s Subscription page.
Fixes
None.
Known Issues
None.



In this release:
• New API authentication method hides PII

• CDN: Disable all website caching
• Policy Management: API to manage sub account access
• DDoS Protection Dashboards: 95th percentile of bandwidth usage is displayed
New Features
None.
Enhancements
New API authentication method hides PII
You can now submit your API key and API ID using headers instead of sending them as query parameters.
This is a more secure method than sending the API key and ID in the query string, preventing exposure of your
personally identifiable information (PII).
The headers used are x-API-Key and x-API-Id.
For backward compatibility, you can also continue to send the authentication details as query parameters.
CDN: Disable all website caching
A new cache mode option was added to completely disable caching for a site, including any user-defined custom
cache rules.
What changed:
In the Cloud Security Console, on the Website Cache Settings page, the No caching option was added. When enabled,
caching is completely disabled, including any user-defined custom cache rules.

In the version 1 API /api/prov/v1/sites/performance/cache-mode, the values available for the cache_mode parameter
were changed:
• The disable value turns off site caching entirely, including user-defined custom cache rules.
• The custom_cache_rules_only value was added. It enables caching for custom cache rules only. All other
site caching is disabled. (The former behavior of the disable value.)
In the version 2 API /sites/{siteId}/settings/cache, the values available for the mode parameter were changed:
• The disable value turns off site caching entirely, including user-defined custom cache rules.
• The custom_cache_rules_only value was added. It enables caching for custom cache rules only. All other
site caching is disabled. (The former behavior of the disable value.)
In both the version 1 and 2 API, the disabledByCacheMode parameter was added to custom cache rules. It
indicates if a custom cache rule is inactive because cache mode is set to “no caching”. The default value is false.
Policy Management: API to manage sub account access
APIs were added for managing the list of sub accounts that can access your account’s policies.
For each policy, you can define which sub accounts can view and manage the policy.
For details, see the Policy Management account application section of the Policy Management API Definition.
DDoS Protection Dashboards: 95th percentile of bandwidth usage is
displayed
The DDoS Protection for Networks and Network Traffic dashboards now indicate the 95th percentile mark of
bandwidth usage based on your account plan’s bandwidth allotment.

This provides you with continuous visibility into your general bandwidth usage ahead of the billing period.
In the Cloud Security Console DDoS Protection dashboards, the indicator is displayed when you select the following
view settings:
1. View By > Overall

2. Traffic > All
3. Real time view or any time period up to the last 90 days
For details on the dashboards, see:
• Security Dashboard: DDoS Protection for Networks and IPs

To learn more about how Imperva calculates the 95th percentile of bandwidth usage, see Account Bandwidth
Calculation.
Fixes
None.
Known Issues
None.



In this release:
• Introducing Client-Side Protection

• DDoS Protection for Individual IPs: API
• New Atlas CA for Imperva certificates
• DNSSEC compliance for DNS CNAME resolution
• Heads Up: CDN - Change in website cache policy APIs
New Features
Introducing Client-Side Protection
Client-Side Protection guards website visitor data from theft through client-side attacks like digital skimming, supply
Client-Side Protection provides you with visibility into third-party services used in your applications. It enables you to
review requests for external resources coming from you website and take action to block them as needed.
Key capabilities:
• Discover and monitor third-party services

• Allow approved domains
• Block unapproved domains
• Gain insights into each discovered service
• Continue to monitor and manage third-party services as applications develops
Benefits:
• Gain visibility into all your application's third-party components

• Maintain data privacy compliance when processing cardholder data and PII
• No installation or application changes required
• Out of the box monitoring
• 1-click mitigation
Client-Side Protection is part of the Imperva Cloud Application Security suite.
Learn more: See the Client-Side Protection Documentation.
Get started: Contact an Imperva Sales representative to request a free trial.
Enhancements
DDoS Protection for Individual IPs: API
You can now onboard your IP addresses to the DDoS Protection for Individual IPs service and manage their
configuration using the API.
Imperva provides an API definition file (Swagger) that presents an interactive version of the Protected IP APIs that you
can use to learn about the APIs, or test them using your API ID and key.

For details, see Protected IP API Definition.

New Atlas CA for Imperva certificates
maintaining new SSL certificates, as described in the August 16, 2020 Release Notes. Imperva certificates created by
GlobalSign Atlas are issued by GlobalSign HV RSA DV SSL CA 2018.
What's changing:
• Starting September 7, 2020, new Imperva-generated certificates that are created will be issued by a new
Certificate Authority: GlobalSign Atlas R3 DV TLS CA 2020.
• Certificates issued by the old Atlas CA are scheduled to be revoked on October 21, 2020. To prepare for this
change, all Imperva certificates issued by the old Atlas CA will be reissued by the new Atlas CA before October
21, 2020. For more details on the impact of the change, see the August 16, 2020 Release Notes.
DNSSEC compliance for DNS CNAME resolution
We are starting a gradual rollout of DNSSEC compliance for CNAME resolution.
Availability: The rollout is expected to be completed by September 20, 2020.

Heads Up: CDN - Change in website cache policy APIs
To align with an upcoming enhancement to website cache settings, the following changes in the caching APIs will be
implemented on September 13, 2020.
Version 1 API /api/prov/v1/sites/performance/cache-mode
The following changes will be made in the values available for the cache_mode parameter (as described here in the
documentation):
• The disable value cache behavior will be updated. It will now turn off site caching entirely, including user-
defined custom cache rules.
• The custom_cache_rules_only value will be added. It will enable caching for custom cache rules only.
All other site caching will be disabled. (The current behavior of the disable value.)
Version 2 API /sites/{siteId}/settings/cache
The following changes will be made in the values available for the mode parameter (as described here in the
documentation):

• The custom_cache_rules_only value will be added. It will enable caching for custom cache rules only.
All other site caching will be disabled. (The current behavior of the disable value.)
In addition, the cache mode options available in the Cloud Security Console UI will be updated accordingly. A new
option will be added to disable caching entirely, including user-defined custom cache rules.
Fixes
None.
Known Issues
None.


In this release:
• Heads Up: New Atlas CA for Imperva certificates

New Features
None.
Enhancements
Heads Up: New Atlas CA for Imperva certificates
maintaining new SSL certificates, as described in the August 16, 2020 Release Notes. Imperva certificates created by
GlobalSign Atlas are issued by GlobalSign HV RSA DV SSL CA 2018.
What's changing:
• Starting September 7, 2020, new Imperva-generated certificates that are created will be issued by a new
Certificate Authority: GlobalSign Atlas R3 DV TLS CA 2020.
• Certificates issued by the old Atlas CA are scheduled to be revoked on October 21, 2020. To prepare for this
change, all Imperva certificates issued by the old Atlas CA will be reissued by the new Atlas CA before October
21, 2020. For more details on the impact of the change, see the August 16, 2020 Release Notes.
On September 6, 2020, we are starting a gradual rollout of DNSSEC compliance for CNAME resolution.


documentation):
• The custom_cache_rules_only value will be added. It will turn off site caching except for custom cache
rules. (The current behavior of the disable value.)
documentation):
Fixes
None.
Known Issues
None.


In this release:
• Create and manage policies in a sub account

New Features
None.
Enhancements
Create and manage policies in a sub account
Policies can now be created and managed in a sub account, and restricted to the specific sub account only.
A policy created in a sub account can be managed only by users with the appropriate permissions in the specific sub
account, and is not visible from other sub accounts.
What changed: Previously, policies could be created and managed only in the parent account, and were available
from all sub accounts.
• Create and manage policies in a sub account: On the Cloud Security Console sidebar, select Management >
Policies.
• Edit policies from the Website Policies page: On the Cloud Security Console sidebar, select Websites > Policies.
For details, see Create and Manage Policies.



documentation):
documentation):
Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for Networks: Routing optimization for network ranges

• Migration to the new GlobalSign Atlas Platform
• DDoS Protection: Improved notification of DDoS events
New Features
None.
Enhancements
DDoS Protection for Networks: Routing optimization for network ranges
DDoS Protection for Networks customer IP ranges will now be advertised from all Imperva PoPs in the region where
the customer data center is located.
What changed: Previously, customer IP ranges were advertised only from the PoPs to which the customer was
connected via a GRE tunnel, as well as from our higher-capacity PoPs outside of the region.
This change is expected to result in improved performance, whether or not you are under attack. The new method
provides better DDoS handling, as more PoPs take part in traffic scrubbing.
Note: This change does not impact data storage regulation. User data continues to be stored only in the region that is
defined in Account Settings.
Availability: This enhancement is currently being rolled out.
• Available to new customers as of August 2, 2020.

• We are gradually reconfiguring existing customers to use the new advertisement policy.
• Applies only to DDoS for Networks customers connecting to Imperva over a GRE tunnel.
For more details on Imperva's software-defined network range advertisement, see Introduction: DDoS Protection for
Networks.
Migration to the new GlobalSign Atlas Platform
maintaining new SSL certificates.
The GlobalSign CloudSSL service that was used until now is obsolete and expected to be deactivated in the near
future.
To support this change, we are migrating all of our existing GlobalSign CloudSSL certificates to the new platform over
the next several weeks.
Impact:

This change relates to Imperva-generated certificates only.
• For most customers, the change will be transparent.

• If you received a revalidation email from Imperva, we ask that you promptly complete the process to revalidate
successfully.
• Sites using certificate pinning with Imperva-generated certificates may experience a service outage when
the certificate is migrated. You can continue to use certificate pinning on your site by uploading a custom
certificate instead. For details, see Upload a Custom Certificate for Your Website on Imperva.
• Client applications that are using the GlobalSign root certificate in their trust store will need to update the trust
store with the Atlas root certificate after migration.
Support:
• For more details on how Imperva supports secure websites, see Web Protection - SSL/TLS.
• For any additional questions, please contact Support.
• You can find more information about Atlas here:
https://www.globalsign-media.com/en/datasheet/atlas/
https://www.globalsign.com/en/blog/atlas-blogged
DDoS Protection: Improved notification of DDoS events
The notification mechanism for the start of L3/4 DDoS events was updated for improved sensitivity and accuracy.
What changed: The Cloud Security Console dashboards and email notifications more accurately reflect the start of
DDoS events.
Where it’s located: Event notifications are displayed in the Network Traffic Dashboard, in the DDoS for Networks/IPs
(Infrastructure) Dashboard, and sent by email. For details, see:

• Notifications

Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for Individual IPs: Self-service onboarding

• Attack Analytics: Identifying unprotected API hosts
New Features
None.
Enhancements
DDoS Protection for Individual IPs: Self-service onboarding
The DDoS Protection for Individual IPs service over GRE or IPinIP tunnels now supports end-to-end self-service
onboarding.
It is deployed as an always-on service and traffic flow is symmetric, where both ingress and egress traffic flow through
the Imperva network, providing a 3 second mitigation time SLA.
Availability: This change is being rolled out over the next several weeks.
What changed: Previously, onboarding required configuration by the Support team.
1. On the Cloud Security Console sidebar, click Infrastructure > IP Protection Settings.
2. Click Add Protected IP, and then select GRE Tunnel or IPinIP Tunnel.
For details, see Onboarding IP Protection over GRE or IP-in-IP.

Attack Analytics: Identifying unprotected API hosts
A new Insight was added to Attack Analytics that identifies your API hosts that have been attacked but are not
protected by API Security.

This calls your attention to sites you may want to onboard to Imperva API Security to benefit from the additional
protection.
Where it’s located: In the Attack Analytics Dashboard, click the Insights button in the banner to view the
recommended actions for your account.
To learn more, see:
• Get Actionable Insights

Fixes
None.

Known Issues
None.


In this release:
• API Security updates

• Attack Analytics: Exposed origin server insight updated
New Features
None.
Enhancements
API Security updates
The following changes were implemented for API Security:
OpenAPI Specification (Swagger) Version 3 support added: You can now use OASv3 to define your API structure.
New dashboard: For improved visibility and investigation capabilities, the landing page for API Security has been
replaced with a new dashboard that displays metrics at the individual site level. For details, see API Security
Dashboard.
Attack Analytics: Exposed origin server insight updated
The exposed origin server insight now identifies if your origin server IP address is visible in public DNS records,
indicating that the server is at increased risk of attack.

To learn more, see Get Actionable Insights.
Fixes
None.
Known Issues
None.



In this release:
• Account Takeover Protection API

• Attack Analytics: Exposed origin servers
New Features
None.
Enhancements
Account Takeover Protection API
You can now access your Account Takeover Protection data using an API.
• Leaked credentials login report: Retrieve the list of successful login events that used publicly available leaked
credentials.
• Compromised users login report: Retrieve the list of successful login events that had a non-zero probability of
being an attack.
For details, see Account Takeover Protection API.

Attack Analytics: Exposed origin servers
A new Insight was added, providing you with information on your origin server IP addresses that are exposed, and
recommended actions for mitigating the threat.
Attack Analytics detects if the origin server IP address is directly accessible via HTTP/S request, indicating that the
server is at increased risk of attack.

recommended actions for your account. This enables you to make any necessary adjustments to ensure that all traffic
to your site will pass only through Cloud WAF.

Fixes
None.
Known Issues
None.


In this release:
• Add DNS TXT records for your website

• Policies: Manage exceptions in a sub account
• Change in regional anycast topology for Cloud WAF
• Support removed for creating Pro or Business accounts via the API
New Features
None.
Enhancements
Add DNS TXT records for your website
The option to configure DNS text records for your site was added. TXT records specified in this section are returned by
Imperva when responding to TXT queries for your site's CNAME.
As part of onboarding your site, you configure your DNS settings to use the CNAME provided by Imperva. Because DNS
protocol does not permit other record types when the CNAME record exists, you can't add TXT records directly to your
domain's DNS configuration. This section enables you to configure TXT records while also using a CNAME record for
your domain.
For example, you can define a TXT record here for SPF and/or DKIM in order to prevent email spoofing.
Where it’s located: On the Cloud Security Console sidebar: Websites > Settings > General > DNS.

Policies: Manage exceptions in a sub account
Users with the appropriate permissions can now add, edit, and delete exceptions to policies that are applied to
websites in a sub account.
What changed: Previously, exceptions could be managed at the account level only.

Required permissions: The user must have a role in the specific sub account that includes one or more of the
following: Add/Edit/Delete exception to policy
1. On the Cloud Security Console sidebar, click Websites > Policies.

2. On the Policies page, click a policy name to edit the policy and configure exceptions.
For more details on policies, see the section on adding an exception in Create and Manage Policies.
Change in regional anycast topology for Cloud WAF
To further enhance our global network routing capabilities for DDoS attack mitigation, we are rolling out the following
network topology change over the next several weeks.
What’s changing:
Our current regional anycast topology for Cloud WAF customers is going to be enhanced with an additional layer of
global anycast. This means that a region will also be advertised globally.
This unique topology allows us to maintain the best performance for your end-customers (content will be served by
the nearest PoP), while improving our DDoS mitigation capacity.
As a practical example, the Imperva IP ranges for the US region will also be advertised in additional PoPs within EU
and APJ. Attacks originating from APJ and directly targeting your US IP address will already be mitigated within APJ.
Before the topology change:
After the topology change:

What’s important to know:
As mentioned above, this change will result in the advertising of regional IPs to other regions, which means that traffic
processing will not be isolated within the region.
What you need to do:
If you require traffic to be terminated (decrypted) in Imperva PoPs within the region only, please contact Support. Our
team will assist in provisioning the appropriate regional routing policy for you (US, EU, CA, AU).
Fixes
None.
Known Issues
None.

Support removed for creating Pro or Business accounts via the API
The ability to create Pro or Business accounts via the API is no longer supported. These plans were previously
discontinued, replaced by FlexProtect plans.
The change applies to configuring the plan_id parameter in the following APIs:
• Add a new managed account: /api/prov/v1/accounts/add

• Modify account configuration: /api/prov/v1/accounts/configure

These APIs are available for Reseller accounts only.


In this release:
• L3/L4 DDoS attack reporting added to Imperva Security mobile app

• Heads Up: Change in regional anycast topology for Cloud WAF
• Heads Up: Removing support for creating Pro or Business accounts via the API
• Heads Up: Policy Management rollout / Change in website ACL API
New Features
None.
Enhancements
L3/L4 DDoS attack reporting added to Imperva Security mobile app
Layer 3/4 DDoS attacks on website and network assets are now displayed in the mobile app dashboard.
In addition, you can set alerts to receive push notifications for the L3/L4 DDoS attacks.
For more details on the app, see Imperva Security Mobile App.
Heads Up: Change in regional anycast topology for Cloud WAF
To further enhance our global network routing capabilities for DDoS attack mitigation, we’re planning to make the
following network topology change.
The change is scheduled for July 12, 2020, as a gradual rollout over several weeks.
What’s changing:


Fixes
None.
Known Issues
None.

Heads Up: Removing support for creating Pro or Business accounts via the
API
On July 12, 2020, the ability to create Pro or Business accounts via the API will no longer be supported. These plans
were previously discontinued, replaced by FlexProtect plans.

This functionality is currently available to reseller accounts only.

Heads Up: Policy Management rollout / Change in website ACL API
As part of the process of migrating accounts to the new Policy Management feature, the APIs used for website ACLs
will be replaced with new APIs.
The following Site Management APIs will be replaced:
• Modify site access control list (ACL) configuration

• Modify whitelist configuration
ACL details will be removed from the following Site Management APIs:
• Get site status

• All other Site Management APIs that return details of the site’s ACL configuration
Policy Management rollout plan:
• June 7, 2020: The feature is available to all new accounts, by default.

• June 14, 2020: The feature is available to any customer by request. Contact Imperva Support or your sales
representative to schedule a time for migration.
• June 21, 2020: Automatic migration of existing free, pro, and business plan accounts begins.
• July 5, 2020: Automatic migration of existing enterprise and FlexProtect customer accounts begins.
For details on the new Policy Management API and the migration process, see Create and Manage Policies.



In this release:
• Attack Analytics: Direct access to Volumetric DDoS Attack analytics

• Whitelist rules now apply to smuggling attacks
• Heads Up: Removing support for creating Pro or Business accounts via the API
New Features
None.
Enhancements
Attack Analytics: Direct access to Volumetric DDoS Attack analytics
The link from an Attack Analytics volumetric DDoS attack incident to your account in the Cloud Security Console has
been adjusted. The link now directly opens the advanced analytics for the relevant website group, enabling you to
drill down for more information about the related DDoS attack on your websites.
What changed: Previously, the link opened the Network Traffic Dashboard at the account level.
Where it’s located: When viewing the Volumetric DDoS Attack incident in Attack Analytics, click Network traffic
dashboard.

• Volumetric DDoS Attacks

What’s changing:


Fixes
Whitelist rules now apply to smuggling attacks
Whitelist rules configured for your site now also apply to smuggling attacks, allowing them to bypass the Cloud WAF.
For example, if you add a whitelist rule on a specific IP address, and a smuggling attack is detected coming from that
IP, it will not be blocked. This can be useful for testing purposes.
What changed: Previously, the whitelist rule was ignored and the smuggling attack was blocked.
• Websites > Settings > Security > Whitelist Specific Sources, or

• Whitelist policy (after your account is migrated to Policy Management)
Known Issues
None.

Heads Up: Removing support for creating Pro or Business accounts via the
API
On July 12, 2020, the ability to create Pro or Business accounts via the API will no longer be supported. These plans
were previously discontinued, replaced by FlexProtect plans.

This functionality is currently available to reseller accounts only.



• Get site status




In this release:
• Attack Analytics: New log fields

New Features
None.
Enhancements
Attack Analytics: New log fields
The following fields were added to the Attack Analytics logs.
Attack Analytics corresponding

Field Description
field
The list of the CVEs (Common
cs9 Vulnerabilities and Exposures) that CVEs
are associated with the incident.
cs9Label Label of the CVE field. ImpervaAACves
For more details on Attack Analytics and CVEs, see:
• Attack Analytics Logs

• View Incidents
What’s changing:


Fixes
None.
Known Issues
None.


• Get site status





In this release:

• Heads Up: New fields in Attack Analytics logs
New Features
None.
Enhancements
What’s changing:


Heads Up: New fields in Attack Analytics logs
On June 21, 2020, the following fields will be added to the Attack Analytics logs.

Field Description
field

• View Incidents
Fixes
None.
Known Issues
None.


• Get site status





In this release:
• Introducing Policy Management

• Advanced Bot Protection: Support added for GeeTest CAPTCHA
• Heads Up: New fields in Attack Analytics logs
New Features
Introducing Policy Management
Centrally configure and manage settings, save them as a policy, and then apply the policy to multiple sites in your
account.
What changed: Previously, each website protected by Imperva had to be configured separately. Now you can
configure and maintain ACL and whitelist settings for your account, in one location.
Benefits include:
• Easily define and maintain settings

• Avoid the resource-intensive, time-consuming, and error-prone work of manual configuration
• Simplify the process of changing settings across all sites
• Automatically assign policies to new sites created in the account
Rollout plan:

• June 14, 2020: The feature will be available to any customer by request. Contact Imperva Support or your sales
For details on Policy Management and the migration process, see Create and Manage Policies.
Enhancements
Advanced Bot Protection: Support added for GeeTest CAPTCHA
You can now opt to use GeeTest CAPTCHA and select a difficulty level for the challenge that you want to present to
visitors.
Availability: Advanced Bot Protection customers integrating via Connectors only. (If you are instead using Advanced
Bot Protection via Imperva Cloud WAF, you can configure GeeTest CAPTCHA directly in the Cloud Security Console. For
details, see Web Protection - Security Settings.)
What changed: Previously, the GeeTest option required the user to provide credentials. That option has been
renamed Custom Geetest.

Where it’s located: On the Edit Website page, expand the advanced settings. Under Captcha settings, select Geetest.
For instructions on accessing the settings, see Editing a Website.
Heads Up: New fields in Attack Analytics logs
On June 21, 2020, the following fields will be added to the Attack Analytics logs.

Field Description
field

• View Incidents
Fixes
None.
Known Issues
None.


• Get site status




In this release:
• HTTP/2 support for connection between Imperva and origin

• WAF gRPC Support
• New rule filter parameter: ABP Action
New Features
None.
Enhancements
HTTP/2 support for connection between Imperva and origin
HTTP/2 is now supported for the connection between Imperva and your origin servers, providing enhanced
performance and security.
What changed: Previously, HTTP/2 was supported for the connection between clients and Imperva only.
Where it’s located: On the Delivery Settings page, under Network > Enable HTTP/2, select Support HTTP/2 from
client to Imperva and from Imperva to origin server.
For more details, see Delivery Settings.

WAF gRPC Support
Imperva Cloud WAF can now mitigate attacks on gRPC , providing you with enhanced security for your gRPC data.
New rule filter parameter: ABP Action
The new ABP Action parameter enables you to perform actions on requests based on the action taken by Advanced
Bot Protection (ABP).
For example, you can create a rule to rewrite responses or to set caching behavior when a specific action is taken by
ABP.

Where it’s located: In the Cloud Security Console Rules page, or the Cache Settings page (under Custom Cache
Rules). For more details, see Rule Filter Parameters
Availability: For use by Advanced Bot Protection customers only.
Fixes
None.
Known Issues
None.

On June 7, 2020, we are starting a gradual rollout of the new Policy Management feature.
As part of the rollout, website access control lists (ACLs) will be automatically migrated to the new policies, and the
APIs used for website ACLs will be replaced with new APIs.


• Get site status

What is Policy Management? Currently, each website protected by Imperva must be configured separately. Manually
configuring a large number of sites can be resource-intensive, time-consuming, and error-prone. Policy Management
introduces the ability to centrally configure and manage settings, save them as a policy, and then apply the policy to
multiple sites in your account.
For details on Policy Management and the migration process, see the Policy Management beta documentation.
• June 7, 2020: The feature will be available to all new accounts, by default.
• June 14, 2020: The feature will be available to any customer, by request. Contact Imperva Support or your sales


In this release:
• API: Changes in API responses

• API: List all custom cache rules API added
• API: Change in edit cache and delivery settings APIs
• Origin Lock fix
New Features
None.
Enhancements
API: Changes in API responses
As part of an upgraded certificate validation process, changes were made to API responses that affect several APIs.
What changed:
• When the action performed by the APIs requires DNS verification by the user, the response includes the
domain_dns key. Previously, this key contained a single value. Now it is an object composed of key/value pairs
(domain name: array of values).
For example:
Before Now
{"res":0,"res_message":"OK","debug_info":{"id-
{"res":0,"res_message":"OK","debug_info":{"id-
info":"999999", "domain_dns”:
info":"999999","domain_dns":"_globalsign-
{“example.com”:[“_globalsign-domain-
domain-verification content\u00-####-93403"}}
verification\u00-####-93403”]}}
The APIs impacted by this change are:
• Modify Site Configuration

• Move Site
• For APIs that include site status details in the response structure, the array of objects under ssl > generated
certificate > validation data previously contained only one element. Now it can have up to 2 elements.
In addition, the set_data_to field previously contained only one element. Now it can have up to 4 elements.
For example:
"validation_data": [
{
"dns_record_name": "incaptest.co",
"set_type_to": "TXT",

"set_data_to": [
"_globalsign-domain-verification=sdl_####_####_w9",
"_globalsign-domain-verification=70en#######DXSrwYj"
]
},
{
"dns_record_name": "test.incaptest.co",
"set_type_to": "TXT",
"set_data_to": [
"_globalsign-domain-verification=ldsFF########50725"
]
}
]
The APIs impacted by this change are any that include site status details in the response structure.
For more details on the APIs, see Site Management API.

API: List all custom cache rules API added
A new (version 2) API was added to enable you to retrieve the list of all custom cache rules defined for a site:
GET /sites/{siteId}/settings/cache/rules
What changed: Previously you could retrieve details of a single rule only by specifying a specific rule ID.
For details, see Cache Settings API Definition.
For details on version 2 API, see API Version 2/3 Overview.

API: Change in edit cache and delivery settings APIs
To better align with REST API best practices, the following version 2 APIs were changed from POST to PUT operations:
• /sites/{siteId}/settings/cache (Modify cache settings)

• /sites/{siteId}/settings/delivery (Modify delivery settings)
For details on cache and delivery APIs, see the Cache Settings API Definition.
For details on version 2 API, see API Version 2/3 Overview.
Fixes
Origin Lock fix
Origin Lock associates a specific IP with your account to prevent other accounts on the Imperva service from setting
up sites that forward traffic to that origin IP.
Problem: If a parent account configured origin lock but does not have any sites configured directly under it, the IPs
configured for origin lock were ignored and not locked.
Solution: The bug is fixed. All IPs configured for origin lock in an account are locked for use by the account and its sub
accounts only.

Known Issues
None.

On June 7, 2020, we are starting a gradual rollout of the new Policy Management feature.

• Get site status

• June 7, 2020: The feature will be available to all new accounts, by default.
• June 14, 2020: The feature will be available to any customer, by request. Contact Imperva Support or your sales
• June 28, 2020: Automatic migration of existing enterprise and FlexProtect customer accounts begins.


In this release:
• Restore default cache and delivery settings APIs added

• Heads Up: Change in website ACL API
• Heads Up: Change in edit cache and delivery settings APIs
New Features
None.
Enhancements
Restore default cache and delivery settings APIs added
The following APIs were added:
• DELETE /sites/{siteId}/settings/cache (Restore default cache settings)

• DELETE /sites/{siteId}/settings/delivery (Restore default delivery settings)
Settings are restored to the default state as they are when a new site is created (all options are turned off).
For details, see Cache Settings API Definition.
Fixes
None.
Known Issues
None.

Heads Up: Change in website ACL API
On May 31, 2020, we are starting a gradual rollout of the new Policy Management feature.

• Get site status


Heads Up: Change in edit cache and delivery settings APIs
On May 24, 2020, to better align with REST API best practices, the following APIs will be changed from POST to PUT
operations:
• /sites/{siteId}/settings/cache (Modify cache settings)

• /sites/{siteId}/settings/delivery (Modify delivery settings)
For details on cache and delivery APIs, see the Cache Settings API Definition.


In this release:
• New rule filter parameter: Site Average Request Rate

• Data Center API Update
• Cannot save incorrect log settings
• Heads Up: Change in website ACL API
New Features
None.
Enhancements
New rule filter parameter: Site Average Request Rate
The new Site Average Request Rate 1m parameter enables you to create rules that run based on the average RPS
(requests per second) rate of your website over a period of one minute.
For example, you can create a rule to divert traffic to a different server when the average request rate (i.e HTTP load)
over the past minute on this website exceeds a specified value.
Where it’s located: In the Cloud Security Console Rules page. For more details, see Rule Filter Parameters.
Data Center API Update
The following changes were made to the Data Center APIs:
• The response for the List Data Centers API now indicates if the data center is defined as the primary/active data
center (isStandBy=false) or the secondary/standby data center (isStandBy=true).
• The option to use the is_standby parameter in the Add Data Center API was removed. The is_standby
parameter was previously deprecated. If used, an error is now returned. To define a data center as Standby via
the API, use Edit Data Center.
For more details on the Data Center APIs, see Site Management API.

Cannot save incorrect log settings

When configuring the log integration using the push mode, your connection settings are tested and must pass
successfully before you can save your changes. The connection test ensures that Imperva can successfully connect
and write to the remote repository you specified.
What changed: Previously, the connection test was available to you to run on demand, but was not run automatically
before saving the configuration.
Where it’s located: On the Cloud Security Console sidebar, click Logs > Log Setup.
For more details on configuring logs, see Cloud WAF Log Integration.
Fixes
None.
Known Issues
None.

Heads Up: Change in website ACL API
On May 31, 2020, we are starting a gradual rollout of the new Policy Management feature.

• Get site status

To assist you in preparing for the change, documentation will soon be available and will include:
• What is Policy Management and how does it work?

• How do I create and manage policies?
• How do I work with the Policy Management API?

• What happens to my existing ACLs?
An announcement will follow in upcoming release notes.


In this release:
• Introducing Advanced Bot Protection

• Self-service interface for client certificate support
• Attack Analytics: Recommended actions for bad reputation IPs
• Attack Analytics and Reputation Intelligence open directly in the Cloud Security Console
• Forward requests to a specific port on the origin server
• Cache rule API update
• API Security opens directly in the Cloud Security Console
• Account Takeover (ATO) Protection events added to Audit Trail
New Features
Introducing Advanced Bot Protection
Release Date: April 27, 2020
Imperva’s best-in-class Advanced Bot Protection protects mission-critical websites, mobile apps, and APIs from
automated threats without affecting the flow of business-critical traffic.
Key capabilities
• Full visibility and control over human, good bot, and bad bot traffic
• Mitigation of all OWASP automated threats including account takeover, web scraping, and online fraud
• Superior technology identifies more bots and catches what others miss
• Real time updates leverage data from our global network
• Smart controls to easily manage your protection settings by specific threat or path
• Comprehensive, customizable, out-of-the-box reporting
Advanced Bot Protection is part of the Imperva Cloud Application Security suite.
To learn about what bad bots do, the tell-tale signs that you have a bot problem, and more, see Imperva Bad Bot
Report 2020: Bad Bots Strike Back.
To learn more about the product, see Advanced Bot Protection.
To get started, contact Imperva Sales.
Enhancements
Self-service interface for client certificate support
Independently configure client certificate support for the websites in your account directly from the Cloud Security
Console or via the new Certificate Manager API.
What changed: Previously, client certificate support required configuration by the Imperva Support team.

• In the Cloud Security Console:

• Upload a CA certificate to your account and assign it to your websites: Management > Client CA
Certificates.
• Configure client certificate settings for a specific website: Websites > Client CA Certificates.
• Via the API.
For details, see Client Certificate Support.

Attack Analytics: Recommended actions for bad reputation IPs
Attack Analytics now provides you with information on the specific IPs with bad reputations that are targeting your
sites and applications, along with recommended actions for mitigating the threat.
IP reputation data is based on calculations by Imperva Research Labs. Imperva’s Reputation Intelligence provides an
assessment of the risk level posed by an IP, based on the IP’s activity across the Imperva customer base. For more
information, see Reputation Intelligence.
What changed: A new Insight was added.
recommended actions for your account.


Attack Analytics and Reputation Intelligence open directly in the Cloud
Security Console
The Attack Analytics and Reputation Intelligence UI are now displayed directly in the Cloud Security Console.
What changed: Previously, these features opened in a separate browser window after clicking the Launch button.
Forward requests to a specific port on the origin server
The new Forward to Port action for custom rules enables you to dynamically forward requests that match your filter
criteria to a specific port.
You can specify the target origin port in two ways:
• Provide an arbitrary port value

• Provide the name of the request header that includes the port number in a specific format
What changed:
• The Forward to Port rule action was added to the Add/Edit Rule page.
• To maintain a streamlined user experience, the Forward to Data Center action and the new Forward to Port
action were moved under a Forward category.

• On the Cloud Security Console sidebar, navigate to Websites > Rules and click Add Rule. For details, see Create
Rules.
• The new functionality is also supported by the API. For details, see Rules API.
Cache rule API update
To better align with REST API best practices, the method for partially updating a custom cache rule was changed from
POST to PUT.
What changed:
POST /api/prov/v2/sites/{extSiteId}/settings/cache/rules/{ruleId}
was changed to:
PUT /api/prov/v2/sites/{extSiteId}/settings/cache/rules/{ruleId}
For details, see Application Delivery API.

API Security opens directly in the Cloud Security Console

API Security is now displayed directly in the Cloud Security Console, separately at the website level for each website in
the account.
What changed: Previously, API Security was available at the account level only and opened in a separate browser
window after clicking the Launch button. Details of all websites in the account were displayed on one page.
Where it’s located: On the Cloud Security Console sidebar, navigate to Websites > <your website> > API Security.
Account Takeover (ATO) Protection events added to Audit Trail

ATO Protection events are now tracked and displayed in the Audit Trail.
Where it’s located: On the Cloud Security Console sidebar, click Management > Audit Trail.

Fixes
None.
Known Issues
None.


In this release:
• DDoS for Networks: Analytics for network services

• Updated Cache and Delivery Settings API
• DDoS mitigation threshold limit increased
New Features
None.
Enhancements
DDoS for Networks: Analytics for network services
The DDoS for Networks (Infrastructure Protection) Analytics now displays top traffic patterns for services - the unique
combination of destination port, protocol, and IP address.
View advanced analytics for services running on your protected networks, monitored networks, and protected IPs:
• PPS and bandwidth metrics

• Peak or average values
• For legitimate (passed) or blocked traffic
Availability: Available for network traffic occurring after Apr 1, 13:30 UTC.
For more details on Analytics, see Analytics: DDoS Protection for Networks and IPs.
Updated Cache and Delivery Settings API
The following Version 2 APIs were added to the Performance Settings APIv2 and are currently being rolled out.
• Purge cache
• Delete cache rule
• Get XRAY access URL for debug headers

Imperva version 2 API introduces naming and formatting conventions for the HTTP requests that are consistent with
REST API standards and best practices. To learn more about Imperva v2 APIs for the Cloud Security Console, see API
Version 2/3 Overview.
DDoS mitigation threshold limit increased
Imperva enables you to set a DDoS threshold to determine when Imperva to activate DDoS mitigation rules for your
protected website.
What changed: Previously, the range of allowed values was between 10 and 5000 requests per second. The upper
limit is now 10,000.
Note: If you are activating a marketing campaign and expect a significant increase in traffic over a short period of
time, you may want to increase this value so it is not considered a DDoS attack. If you are setting a high threshold to
handle a temporary, significant increase in traffic, remember to adjust it when traffic returns to normal. Rates above
5000 RPS are considered high.
1. On the Cloud Security Console sidebar, click Websites > Settings > WAF.
2. Under DDoS, click Advanced Settings.
For details, see Web Protection - DDoS Settings.
Fixes
None.
Known Issues
None.



In this release:
• Attack Analytics: Filter incidents based on the action taken (Alert or Block)
• New rule filter parameter: Site Request Rate
• Updated cache and delivery settings API
• Two-factor authentication is disabled when logging in with SSO
• Suspected Bots statistic renamed and clarified
• Audit Trail and Role Management open directly in the Cloud Security Console
New Features
None.
Enhancements
Attack Analytics: Filter incidents based on the action taken (Alert or Block)
You can now filter incidents based on the action taken on the events in the incident.
For example, you can filter for incidents that include alerted events, while hiding incidents that include only blocked
events. This enables you to direct your attention to areas that may require configuration adjustments, such as
changing a policy from alert to blocking mode in your account’s WAF settings.
Action:
• All: All incidents

• Blocked events only: Incidents in which 100% of the events were blocked
• Has alerted events: Incidents that include both blocked and alerted events
Location Description
Dashboard
Under Action

Location Description
In the Advanced filter > Action
Incidents view
For more details on Attack Analytics, see Attack Analytics.

New rule filter parameter: Site Request Rate
The new Site Request Rate parameter enables you to create rules that run based on the current RPS (requests per
second) rate of your website.
For example, you can create a rule to divert traffic to a different server when the request rate (i.e. HTTP load) on this
website exceeds a specified value.

Where it’s located: In the Cloud Security Console Rules page. For more details, see Rule Filter Parameters.
Availability: The new parameter is being rolled out and will be available to all customers within the next two weeks.
Updated cache and delivery settings API
We are starting to roll out updated APIs for managing cache and delivery settings for websites in your account.
• Get/Change cache settings

• Create/Read/Update cache rules
• Get/Change delivery settings
Availability: The rollout process is expected to take two weeks.
Imperva version 2 API introduces naming and formatting conventions for the HTTP requests that are consistent with
REST API standards and best practices. To learn more about Imperva v2 APIs for the Cloud Security Console, see API
Version 2/3 Overview.
Two-factor authentication is disabled when logging in with SSO
If two-factor authentication is enabled for a user in the Cloud Security Console, it is no longer activated if the user logs
in with SSO.
When login is carried out via your organization’s SSO, the authentication flow is handled by the SSO provider.
Suspected Bots statistic renamed and clarified
For clarity and consistency, the Suspected Bots statistic was renamed and the displayed data was adjusted to more
accurately reflect the functionality.
What changed:
• Suspected Bots was changed to Suspected bots that triggered a CAPTCHA.

• The count of suspected bots is now always displayed on the Dashboard Security page, regardless of whether the
Require all suspected bots to pass additional challenges option on the Security Settings page is enabled or
disabled. Previously, it was listed as N/A on the Dashboard Security page when the “Require” option was
disabled.

The count is always relevant because suspected bots can be challenged with a CAPTCHA by the default Imperva
process, even when the “Require” option, which enforces a stricter policy against unknown clients, is disabled.
• In the Cloud Security Console, on the Websites > Dashboard > Security page:
For more details, see Website Dashboard.
• In the Weekly Report (which is sent by email when the option is enabled in your Account Settings):
Audit Trail and Role Management open directly in the Cloud Security
Console
The Audit Trail and Role Management UI are now displayed directly in the Cloud Security Console.
What changed: Previously, these features opened in a separate browser window after clicking the Launch button.

Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for DNS: DNSSEC support added
New Features
None.
Enhancements
DDoS Protection for DNS: DNSSEC support added
The Imperva DDoS Protection for DNS service now supports DNSSEC, providing you with enhanced security for your
DNS data.
DNSSEC (Domain Name System Security Extensions) adds a layer of authentication to DNS to boost protection against
MITM attacks, such as DNS cache poisoning and forged DNS responses.
For details on configuring DNS Protection and DNSSEC support, see Add/Edit a Protected DNS Zone.
Fixes
None.
Known Issues
None.


In this release:
• DDoS Protection for Networks: Analytics for Monitored Networks

• Attack Analytics: View the CVEs associated with your incidents
• GeeTest CAPTCHA support added for Advanced Bot Protection
New Features
DDoS Protection for Networks: Analytics for Monitored Networks
Analytics capabilities are now available for network traffic on monitored network ranges (via NetFlow/xFlow/IPFix
protocols).
Where it’s located: To display analytics for monitored networks:
1. In the Infrastructure Protection Dashboard, click Monitored Networks.

2. Select a network from the Ranges table.
3. Select a previous time period or a custom time period. (Analytics are not displayed in real-time view.)
Availability: Available for network traffic occurring after March 4, 2020 13:00 UTC.
For more details on analytics, see Analytics: DDoS Protection for Networks and IPs.
Enhancements
Attack Analytics: View the CVEs associated with your incidents
Attack Analytics now provides a list of the CVEs (Common Vulnerabilities and Exposures) that are associated with your
incidents.
CVE associations are based on ongoing investigation and monitoring by Imperva Research Labs. An incident is
associated with a CVE if one or more its events triggered a security rule determined by Imperva to be associated with
that specific CVE.
Note that an event may be blocked by general mitigation rules even though it was not found to be associated with any
specific CVEs.
What changed: You can now view associated CVEs for an incident, and filter your incidents according to all or specific
CVEs.

Location Details
In the Highlights widget, click the arrow to view the

associated incidents.
Attack Analytics Dashboard
Select and incident and view the details in the right

pane.
Incidents view
Click the CVE link to go to the CVE site for more
information.

Location Details
Filter to view incidents according to associated CVEs

using the advanced filter:

Location Details
Hover over a CVE tag to view details.
Click the CVE link to go to the CVE site for more

information.
Incident details view
For more details on Attack Analytics, see Attack Analytics.

GeeTest CAPTCHA support added for Advanced Bot Protection
Advanced Bot Protection customers can now opt to use GeeTest instead of the default reCAPTCHA used for bot access
control.
Availability: Applies to customers subscribed to both Cloud WAF and Advanced Bot Protection. We are rolling out the
feature over the next two weeks.
1. On the Cloud Security Console sidebar, navigate to Websites > Settings > Security.
2. Under Bot Access Control > CAPTCHA Provider, select GeeTest and choose the difficulty level setting.

For details, see Web Protection - Security Settings.
Fixes
None.
Known Issues
None.


In this release:
• DNS option added for domain ownership validation

• Removal of rule revision history
New Features
None.
Enhancements
DNS option added for domain ownership validation
When configuring SSL support for a site that is already onboarded to Imperva, you can now validate your domain
ownership by email or by adding a DNS record.
What changed: Previously, validation could be completed by email only.
Where it's located: In the Cloud Security Console, navigate to Website > Settings > General > SSL Support. Click
Configure and follow the onscreen instructions.

For more details on the SSL support configuration options, see Onboarding a Site – Web Protection and CDN.
Fixes
None.
Known Issues
None.

Removal of rule revision history
The option to view revision history and revert to previous versions of your custom rules was removed.
All rule changes are now tracked and available through the Imperva Audit Trail.
What changed:
• Rule revision history was removed from the Rules interface (Websites > Rules > More > Revisions).
• The corresponding APIs were also removed:
• Revert rule
• List rule revisions
• The option to revert to previous versions of rules is no longer available.



In this release:
• Regional data storage for Australia

• Attack Analytics: Change in aggregated mode
• Two-factor authentication for password reset
• Role Management API update
• DDoS for Networks: Dashboard views renamed
• Custom error page template update
• Removal of legacy audit events API
• Heads Up: Removal of rule revision history
New Features
None.
Enhancements
Regional data storage for Australia
Regional data storage is now available for Australia, in addition to the existing APAC, EU, and US regions. Imperva
provides the option to isolate data per region, per site, in accordance with data privacy requirements. For more
information on Imperva data storage, see Data Storage Management.
What changed: The Melbourne and Sydney data centers are now located separately under the AU data storage region,
and are no longer part of the APAC data storage region.
Note: Your current data regions will not be automatically changed or migrated to the AU region. You can manually
view or change the data storage region options for your account or for individual sites.
• The account-level data region setting sets the default storage region for new sites created in your account, and
also determines where network layer data is stored. On the Cloud Security Console sidebar, select Management
> Account Settings > Data Management. For details, see Account Settings.
• The site-level data region setting determines the geographical region for storing your Layer 7 (application layer)
Imperva data. On the Cloud Security Console sidebar, select Websites > Settings > General > Data Storage. For
Attack Analytics: Change in aggregated mode
On January 26, 2020 the aggregated analytics option was introduced into the Attack Analytics settings. In aggregated
mode, an attack that targets multiple sites in multiple sub accounts is clustered and presented as a single incident in
the parent account.
What changed:
• When aggregated mode was enabled, Attack Analytics data was available only in the parent account and not in
the sub accounts. Now, incidents are presented in both the parent account and in the sub accounts. An incident
in a sub account is based on events in the individual sub account only.

• In aggregated mode, you can access Attack Analytics from the Cloud Security Console from both the parent
account and from the sub accounts.
• When opened from the parent account, incidents from sites in the parent account and all sub accounts
are presented.
• When opened from a sub account, only incidents from the sites in the specific sub account are
presented.
For more details, see Account Configuration Settings.

Two-factor authentication for password reset
As an added security measure, two-factor authentication via SMS or Google Authenticator has been added to the
password reset process.
What changed: When you reset your password using the “Forgot your password?” link on the Cloud Security Console
login screen, two-factor authentication is activated. Previously, a password reset email was immediately sent to your
email address. Now, you must complete the two-factor authentication before the password reset email is sent.
Availability: This applies to users who have already configured and enabled two-factor authentication via SMS or
Google Authenticator on the User Preferences page in the Cloud Security Console. For details, see User Preferences.
Role Management API update
Role details that are returned by the APIs now include the email of the user, and the account or sub account ID.
For example, when requesting the list of users assigned to a given role, the following details are now returned for
userAssignment:
"userAssignment": [
{
"userEmail": "user1@example.com",
"accountId": 1234
},
{
"userEmail": "user2@example.com",
"accountId": 5678
},
],
What changed: Previously the details included the email only.
For more details, see Role Management API Definition.

DDoS for Networks: Dashboard views renamed
To improve the clarity of the user interface, the following name changes were made in the DDoS for Networks
(Infrastructure Protection) Dashboard.
Old Name New Name

IP Ranges Protected Networks

Old Name New Name
Monitored Ranges Monitored Networks
IP Protection Protected IPs
Fixes
Custom error page template update
A problem in the custom error page default template prevented the feature from working.
Problem: The feature was blocked due to the onload HTML event in the default template. The custom error page
template cannot contain script tags, iframe tags, or illegal HTML actions.
Solution: The onload HTML event was added to the list of illegal HTML event attributes and removed from the default
template.
ACTION REQUIRED: If you have already configured a custom error page for your website using the default template,
you need to use the updated default template and reintroduce your customizations.
For details on configuring a custom error page for your websites, see Custom Error Pages.
Known Issues
None.

Removal of legacy audit events API
The Get account audit events API was removed (/api/prov/v1/accounts/audit).
This functionality is now available as part of the new Audit Trail feature, which displays a log of actions performed in
your account by account users, system processes, and Imperva system administrators and support.
For details, see Audit Trail and the Audit Trail API Definition.

Heads Up: Removal of rule revision history

On March 1, 2020 the option to view revision history and revert to previous versions of your custom rules will be
removed.
Rule changes are now tracked and available through the Imperva Audit Trail.
Changes:
• Rule revision history will be removed from the Rules interface (Websites > Rules > More > Revisions).
• The corresponding APIs will also be removed:
• Revert rule
• The option to revert to previous versions of rules will no longer be available after the rule revision feature is
removed.



In this release:
• Imperva Security Mobile App

• Integration of Advanced Bot Protection security events
• Heads Up: Removal of legacy audit events API
New Features
Imperva Security Mobile App
View your Cloud Application Security dashboards on the go using our new iOS mobile app.
Cloud WAF customers can now take advantage of the Imperva Security mobile app, currently available for iPhone and
iPad.
Key features:
• Aggregated account-level view of all sites

• Single dashboard for visibility into Attack Analytics, CDN, DDoS, and WAF activity
• Push notifications on DDoS attacks, critical setting changes, and data overage
• Read-only view, no editing available
• Log in with your Cloud Security Console credentials
Where it’s located: The Imperva Security free mobile app is available in the Apple App Store: https://
apps.apple.com/us/app/imperva-security/id1479543020
Integration of Advanced Bot Protection security events
Advanced Bot Protection (formerly Distil Networks) security events are now supported by the Cloud Security Console
and the SIEM log integration. When the new Bad Bot (Advanced Bot Protection) security rule is triggered, the incidents
are now displayed along with all other types of security incidents targeting your websites and applications.
• Bad Bot (Advanced Bot Protection) security events are now displayed in the Website > Events page for your
protected websites.
• The Imperva SIEM log integration now indicates when the Bad Bot (Advanced Bot Protection) security rule is
triggered. For details, see Log File Structure.
Availability: Applies to customers subscribed to both Cloud WAF and Advanced Bot Protection.
Enhancements
None.
Fixes
None.

Known Issues
None.

Heads Up: Removal of legacy audit events API
On February 23, 2020, the Get account audit events API will be removed (/api/prov/v1/accounts/audit).
This functionality is now available as part of the new Audit Trail feature, which displays a log of actions performed in
your account by account users, system processes, and Imperva system administrators and support.
For details, see Audit Trail and the Audit Trail API Definition.


In this release:
• Set on/off times for custom rules

• Performance improvement in SIEM log push mechanism
• Dynamic Content Acceleration (Origin PoP) requirements
New Features
None.
Enhancements
Set on/off times for custom rules
The new Scheduler rule filter parameter enables you to configure fixed times and days for a custom rule to be active.
For example, you can use it to redirect requests to a backup site during scheduled maintenance to avoid downtime.
Where it’s located: On the Rules page, when adding a new custom rule.
For instructions on using the Scheduler parameter in a custom rule, see Scheduler.
Performance improvement in SIEM log push mechanism
This issue applies to customers using the push mode for uploading Imperva SIEM integration logs to an S3 or SFTP
repository.
In the event that a significantly slowed upload rate is detected over an extended period of time, you will be notified by
email. This notification enables you to verify your account's log integration settings, as well as check your repository's
availability and stability to resolve any issues that may be preventing proper upload.
Upload attempts will continue for the period of time specified in the email. If the issue is not resolved during that
time, another notification email is sent, informing you that log files may be partially or fully lost, without the
possibility of retrieval.
What changed: Previously, email notifications were sent and log files deleted only in the event of total upload failure.

Fixes
Dynamic Content Acceleration (Origin PoP) requirements
The Dynamic Content Acceleration service (Origin PoP) leverages the high-quality connectivity between Imperva
network PoPs to improve response time for dynamic resources.
As part of this service, Imperva utilizes connection pooling, maintaining and reusing TCP connections between the
selected Origin PoP and your origin server to optimize round-trip times. To support this, the Origin Connection Reuse
setting must be enabled.
What changed: Previously, when selecting an Origin PoP, a message was displayed indicating that the Origin
Connection Reuse setting was required, but it was not enforced in the UI or API. Rather, it was enabled in the
background to support activation of the Origin PoP service.
The following changes were implemented in the UI and API:
• To enable the Origin PoP setting, the Origin Connection Reuse option must first be enabled.
• You cannot disable the Origin Connection Reuse option if Origin PoP is enabled.
• In the Cloud Security Console:
Origin PoP: On the sidebar, click Websites > Settings > Origin Servers. For details, see Dynamic Content
Acceleration.
Origin Connection Reuse: On the sidebar, click Websites > Delivery. For details, see Delivery Settings.
• In the API. For details, see Site Management API.
Known Issues
None.


In this release:
• Terraform Provider for onboarding and configuring sites
New Features
Terraform Provider for onboarding and configuring sites
Manually onboarding and configuring a large number of sites can be resource-intensive, time-consuming, and error-
prone.
The Terraform Incapsula Provider enables you to carry out self-service provisioning of websites for Imperva Cloud
Application Security on a large scale, in a fraction of the time. Using Terraform configuration files, you can create and
configure sites, including managing load balancers, data centers, ACLs, and custom security and delivery rules.
What changed: Our Terraform provider, previously available as an open source plugin, is now officially approved and
tested by HashiCorp and listed on the official Terraform website: https://www.terraform.io/docs/providers/incapsula/
index.html
Where it’s located: The provider is available for download in the Terraform Provider Repository in github: https://
github.com/terraform-providers/terraform-provider-incapsula
Enhancements
None.
Fixes
None.
Known Issues
None.



In this release:
• Attack Analytics: Self-service activation of aggregated analytics

• Easily identify permissions that apply to both parent and sub accounts
New Features
None.
Enhancements
Attack Analytics: Self-service activation of aggregated analytics
View incidents from all sub accounts directly from the parent account
In an account with sub accounts, you can now choose to aggregate incidents from both the parent account and its sub
accounts. When this option is enabled, the incidents are clustered and presented together in the parent account.
In aggregated mode, an attack that targets multiple sites in multiple sub accounts is clustered and presented as a
single incident in the parent account. When the aggregated mode is turned off, the same scenario results in individual
incidents presented in each of the relevant sub accounts.
What changed: You can now enable this option directly in Attack Analytics. Previously, a request to the Support team
was required in order to enable the aggregated view.
Where it’s located: To enable this option, open Attack Analytics in the parent account and enable the following
setting:
1. On the Attack Analytics banner, click Settings to open the Account Configuration page:
2. Enable the Aggregate incidents from the parent account and all of its sub accounts option:

For more details, see Account Configuration Settings.

Easily identify permissions that apply to both parent and sub accounts
An icon was added to indicate permissions that apply to parent accounts and sub accounts. Permissions without the
icon are relevant to parent accounts only.
There is no change in functionality.
Example:
• If the Add sites permission is included in a role assigned to a user in a sub account, it enables the user to add
sites to the sub account.
(Note that If the same role is assigned to a user in the parent account, the user is not automatically granted the
Add sites permission in the sub accounts. The role must be explicitly assigned to the user in the relevant sub
accounts as well.)
• The Edit account settings permission is only relevant to a parent account. If it is included in a role assigned to a
user in a sub account, the user is still not granted this permission in the sub account.

• User management: On the Cloud Security Console sidebar, click Management > Users. Select a user and click
the View Permissions icon .

• Role management - when viewing and editing the permission list: On the Cloud Security Console sidebar, click
Management > Role Management > Launch Role Management.
Fixes
None.
Known Issues
None.


In this release:
• Attack Analytics integrates network level L3/L4 DDoS attacks

• API added for resuming traffic to active data centers
• New rule filter parameter identifies requests from mobile devices
• Brotli compression support
• Validation added to custom error page configuration
• Idle session timeout decreased for the Cloud Security Console
New Features
None.
Enhancements
Attack Analytics integrates network level L3/L4 DDoS attacks
You can now see L3/L4 DDoS attacks in Attack Analytics, in addition to the security incidents targeting your websites
and applications.
Volumetric DDoS attacks can often be used to divert attention from other simultaneous L7 WAF attacks. Attack
Analytics now provides greater visibility and insights into what is happening to your assets.
This L3/4 DDoS integration joins the API Security, Account Takeover Protection, and Reputation Intelligence
integrations with Attack Analytics to provide a single pane of glass for all types of attacks.
Availability: Changes will be displayed for DDoS attacks that occur as of this feature's release date.
• The Dashboard’s Incidents graph now also displays network level (layer 3/4) DDoS attacks that occurred during
the selected time period.

• Click the DDoS bar in the graph to view the related incidents, and additional statistics on the DDoS attack.
• View an analysis of the DDoS attack via the Network Traffic Dashboard.

For more details, see Volumetric DDoS Attacks.

API added for resuming traffic to active data centers
A new API was added for rerouting traffic back to your active data centers after an outage.
Scenario: If you have a multi-data center topology configured for Imperva load balancing, and all of your active data
centers go down, traffic is rerouted to your standby data center.
When at least one active data center is back up, you can manually reroute your traffic back to the active data center.
Traffic does not revert automatically to your active data centers.
What changed: Previously, this functionality was available only in the Cloud Security Console. The Resume Traffic to
Active DCs button is displayed on the Websites > Settings > Origin Servers page in the Cloud Security Console.
The following new APIs were now added:
• API v1: https://my.imperva.com/api/prov/v1/sites/dataCenters/resume. For details, see Site Management API.

• API v2: POST https://my.imperva.com/api/prov/v2/sites/{site_id}/dataCenters/resume?api_key={api_key}
&api_id={api_id}. For details, see Application Delivery API.
For details on API v2, see API Version 2/3 Overview.

New rule filter parameter identifies requests from mobile devices

A new rule filter parameter was added to identify requests coming from a mobile device. The Is Mobile parameter
distinguishes between requests coming from mobile devices and requests coming from desktop clients based on the
user-agent used in the request.
What changed: This functionality enables you to define custom delivery or cache rules to be triggered for either
mobile devices or desktop clients only. For example, as part of a strategy to optimize mobile content delivery.
Where it’s located: In the Cloud Security Console, when adding or editing a custom delivery or cache rule, under Rule
Filter.
Example: This rule is triggered when a request made for URL path “welcome.html” is sent from a mobile device.
Brotli compression support

Imperva now supports Brotli compression, providing increased protection for your websites.
What changed: Response content sent from your origin server in Brotli format is now decompressed and scanned,
enabling us, for example, to better identify and quarantine backdoors planted on your website.
Validation added to custom error page configuration
A validation was added to ensure that a custom error page does not include any script tag, iframe tag, or illegal HTML
action, such as these HTML event attributes: onerror, onmessage, onoffline, ononline, onchange, onfocus, oninput,
onsearch, onsubmit, onselect.
What changed: When configuring a custom error page template for your site that includes any of the above, it cannot
be saved. An error message is displayed when you use the preview function or try to save your changes.
Where it’s located: On the Cloud Security Console sidebar, click Websites > Delivery and scroll to the Custom Error
Page section.

Idle session timeout decreased for the Cloud Security Console

For enhanced security and compliance with PCI requirements, the idle session duration for the Cloud Security
Console was decreased from 60 minutes to 15 minutes.
This represents the amount of time that the browser session of a logged in user can be inactive before the session
times out and closes.
Fixes
None.
Known Issues
None.


In this release:
• Cache rule action renamed
New Features
None.
Enhancements
Cache rule action renamed
The Force User Authentication rule action for custom cache rules was renamed to Force Resource Validation to
better reflect the functionality of the action.
When this option is enabled, Imperva validates with the origin server that the resource has not changed before
returning the cached resource to the client.
1. On the Cloud Security Console sidebar, select Websites > Cache.
2. In the Custom Cache Rules section, click Add Rule.
3. Under Rule Action, select Force resource validation.
For more details on custom cache rules, see Cache Settings.
Fixes
None.
Known Issues
None.



In this release:
• Attack Analytics integrates Account Takeover Protection incidents

• Attack Analytics integrates API Security incidents with finer granularity
• DDoS Protection for Websites: Dashboard enhancements and advanced analytics
• Migration to Role Management
• User and Role Management API Updates
• Delete stored data
• Removal of Activity page
• Expanded limits on restricted IPs
New Features
None.
Enhancements
Attack Analytics integrates Account Takeover Protection incidents
Account Takeover (ATO) incidents are now displayed in Attack Analytics, providing you with a wider view of your
attack landscape. Only mitigated (blocked) ATO incidents are presented.
Availability: Only incidents that occur from this point forward will be displayed.
• Attack Analytics Dashboard: Account Takeover violations are displayed in the Top violations distribution
widget.

• Attack Analytics incidents view: The incident description indicates Account Takeover and the subtitle indicates
the activity that caused the accounts to be marked as compromised, such as brute force or credential stuffing.
• Attack Analytics incident details view: In the list of violations under Which violations were discovered?,
Account Takeover and the type are listed. Click the info icon for more details.

• Account takeover incidents are supported by the SIEM integration and API.
For more details on Attack Analytics and Account Takeover Protection, see:
• Attack Analytics Documentation

• Account Takeover Protection Documentation
Attack Analytics integrates API Security incidents with finer granularity
The specific API Security violation types are now displayed in Attack Analytics incidents, in order to help you better
understand the nature of the attack.
Possible values include:
• Invalid URL
• Invalid method
• Missing parameter
• Invalid parameter value
• Invalid parameter name
Availability: Only incidents that occur from this point forward will include this change.
What changed: Previously, incidents listed API violation without details of the specific API Security violation type.
• Attack Analytics incident view: The incident description indicates API violation and the subtitle indicates the
violation type.
• Attack Analytics incident details view: In the list of violations under Which violations were discovered?, the API
violation and type are listed. For an invalid parameter name or invalid parameter value violation, the parameter
name is also provided in the violation details.
Click the info icon for more details.

For more details on Attack Analytics, see the Attack Analytics Documentation.
DDoS Protection for Websites: Dashboard enhancements and advanced
analytics
This release introduces new dashboard and analytics capabilities for the websites in your account, enabling advanced
analysis of legitimate and malicious (DDoS) network layer traffic.

Where it’s located: On the Cloud Security Console sidebar, click Network Traffic.
Availability: Network traffic data for the websites in your account and advanced analytics data is available for traffic
occurring after January 7, 2020. If you choose to display data for a time range that starts before January 7th, the
website group data and analytics are not displayed.
Changes include:
• The new Website Group table displays data per website group.
A website group is a group of protected websites in your account that share a set of Imperva anycast IPs. Most
accounts typically have only one website group. Some of the protected sites might be grouped separately, when
a specific configuration is required. For example, when using a dedicated network or when network traffic
isolation is needed to meet regulatory requirements.

Expand the group to view the sites included in the group. The list of sites is available only when viewing data
from a previous or custom time period. It is not available in real-time view.
Click a Site ID to open a site’s Website Dashboard.
• To display advanced network traffic analytics:
1. Click the Website Group name.

2. On the analytics page that opens, select a previous time period or a custom time period. (Analytics are not
displayed in real-time view.)
3. Filter to display blocked or passed traffic.
For more details, see Network Traffic Dashboard.

Migration to Role Management
Starting on January 5, 2020, customer accounts will be migrated from the existing model of permission management
to the new Role Management model. Roles were recently introduced for new accounts, as described in the October 27,
2019 Release .
Role Management reduces administrative overhead and enables you to improve your organization's security by
granting users only the specific privileges they need to carry out their responsibilities.
• A role is a set of permissions granting a certain level of access to Imperva cloud assets and services.
• Role Management includes creating and managing roles, and assigning those roles to your account users.
Details on migration:
• Customer accounts will be migrated automatically over a period of several weeks, beginning on January 5,
2020. (Migration of an individual account takes only several minutes.)

• The migration process takes the set of permissions that are currently assigned to a user and groups them into a
role. The role is then assigned to the user.
• If multiple users have the same set of permissions, they will be assigned to the same role.
• Roles that are created during the migration process are displayed with the name “Automatically created role”
and a role ID. For example, [3] Automatically created role. We recommend that you change the role name after
migration, assigning a name that is more meaningful for your organization.
Note: This change does not impact user authorization/login to the Cloud Security Console.
For full details on Role Management, see Manage Roles and Permissions.
User and Role Management API Updates
The following improvements were made in the Role Management API:
• Add and delete role assignment were combined into a single API for updating role assignments: POST /v1/
assignments
• APIs to create, get, and delete a user were added: POST/GET/DELETE /v1/users
For more details, see Role Management API Definition.

Delete stored data
An option to permanently delete the data stored for your account is now available in the Cloud Security Console.
This option enables you to remove all potentially sensitive or personal data that is stored in our systems, such as IP
addresses. (Configuration and settings in the Cloud Security Console are not deleted.) For more details on the data
that is stored for your account and the deletion process, see Data Storage Management.
What changed: The deletion process was previously available via a Support ticket only.
Where it’s located: In the Cloud Security Console, navigate to Management > Account Settings and scroll to Data
Management. The option is available to the account admin user only
Note: The deletion process is carried out at the account level. If the account has sub accounts, data from the sub
accounts is also deleted.
• For an Enterprise plan account that was previously set up as a reseller account in order to implement sub
accounts, data can be deleted at the sub account level only. If this type of account has already been migrated to
the Sub Account model as described in Manage Account Resources, data is deleted at the account level.
• For reseller accounts, data can be deleted at the sub account level only.


Removal of Activity page
The Cloud Security Console Management > Activity page was removed.
The Activity page has been replaced by the new Audit Trail feature, which displays a log of actions performed in your
account by account users, system processes, and Imperva system administrators and support.
For details, see Audit Trail.
Fixes
Expanded limits on restricted IPs
As of December 8, 2019, IP addresses that are restricted from logging in to the Cloud Security Console are also blocked
from sending API requests.
Where it’s located: In the Cloud Security Console: Management > Account Settings > Allow login from the
following IP addresses only.
Known Issues
None.



New Features
Introducing Reputation Intelligence
Gain visibility into the reputation of the IPs attacking your sites to make more informed, data-driven decisions.
Leverage reputation data from across the Imperva customer base and 3rd party providers to help in incident
response.
For a given IP, Reputation Intelligence provides:
• Risk assessment: A score calculated by Imperva researchers to better understand the IP’s maliciousness level.
• Attack types and tools: The types of attacks originating from the IP and the tools it used to attack.
• Attacked industries, geographical targeting, and more.
• API: Consumable also via the Reputation API to support your in-house dashboards and workflows.
• From the Cloud Security Console: On the sidebar, click Reputation Intelligence > Launch Reputation
Intelligence.
• From Attack Analytics: When viewing incident details, click on the attacking IP to open Reputation Intelligence.
For more details, see Reputation Intelligence.

Enhancements
New rule action to rewrite error response
A new rewrite action is available for use when creating custom rules.

The Rewrite Response Error enables you to replace the default error response and error code that are returned to
the client when a request is blocked.
You can:
• Define the custom error response for all error types, or for a specific error type, such as Connection timeout or
Access denied.
• Select the response status code to return.
• Provide a custom response body in JSON or XML format.
• In the Cloud Security Console: On the sidebar, navigate to Websites > Rules and click Add Rule.
• Via the Rules API.
For more details, see Create Custom Error Response Rules.
Custom design the error page for your website
You can configure a custom error page to display to your website visitors in the event of an error.

What changed: In the Cloud Security Console, you can now configure a custom error page for individual websites in
your account. Previously, there was only the option of a single custom error page applied to every site in your account,
configured by Support.
How it works: You provide a custom HTML error page that will replace the default error page used by Imperva. Your
template must include $TITLE$ and $BODY$ placeholders to indicate the location of the information that is
dynamically inserted by Imperva depending on the type of error that occurs.
• In the Cloud Security Console Delivery Settings page. On the sidebar, click Websites > Delivery and scroll to
the Custom Error Page section.
• Site Management API > Modify Error Page to add or edit a custom error page for your site.
For details, see Custom Error Pages.
DDoS protection for individual IPs: New monitoring options
By default, the IP DDoS Protection over TCP/IP service uses ICMP for monitoring the connection to your origin server.
Options for monitoring over TCP and for disabling monitoring are now also available.
What changed: When onboarding an IP or editing the IP Protection settings, you can now choose the monitoring
method.
Where it’s located: On the Cloud Security Console sidebar, click Infrastructure > IP Protection Settings.
For details, see Settings: DDoS Protection for Individual IPs.
Additional attack details in logs
A new field was added to the Imperva logs, providing additional information on the violation that triggers a security
rule.

Detailed
Description CEF LEEF W3C
Description
Additional
information on the
Additional rule info cs11 cs11 cs-ruleInfo violation that
triggered the rule, in
JSON format.
This field is used for API Specification Violation events, and uses the following JSON structure:
{“api_specification_violation_type”:”<type>”,”parameter_name”:”<parameter name>”}
The possible values for api_specification_violation_type are:
• INVALID_URL
• INVALID_METHOD
• MISSING_PARAM
• INVALID_PARAM_VALUE
• INVALID_PARAM_NAME
The “parameter_name” is present only if the violation occurs in the context of a parameter. Its value is the relevant
parameter name.
Availability: This change is being rolled out during the week.
For more details, see Log File Structure.
Heads Up: Migration to Role Management
Starting on January 5, 2020, customer accounts will be migrated from the existing model of permission management
to the new Role Management model. Roles were recently introduced for new accounts, as described in the October 27,
2019 Release .
• A role is a set of permissions granting a certain level of access to Imperva cloud assets and services.
• Role Management includes creating and managing roles, and assigning those roles to your account users.
Details on migration:
• Customer accounts will be migrated automatically over a period of several weeks, beginning on January 5,
2020. (Migration of an individual account takes only several minutes.)
• The migration process takes the set of permissions that are currently assigned to a user and groups them into a
role. The role is then assigned to the user.
• If multiple users have the same set of permissions, they will be assigned to the same role.

• Roles that are created during the migration process are displayed with the name “Automatically created role”
and a role ID. For example, [3] Automatically created role. We recommend that you change the role name after
migration, assigning a name that is more meaningful for your organization.
Note: This change does not impact user authorization/login to the Cloud Security Console.
For full details on Role Management, see Manage Roles and Permissions.
Heads Up: Removal of Activity page
On January 5, 2020, the Cloud Security Console Management > Activity page will be removed.
The Activity page has been replaced by the new Audit Trail feature, which displays a log of actions performed in your
account by account users, system processes, and Imperva system administrators and support.
For details, see Audit Trail.

Fixes
None.
Known Issues
None.
Tip: Open the latest release notes directly from the Management Console's Help menu.


New Features
None.
Enhancements
Role Management improvements
Role Management was recently introduced for new customer accounts, as described in the October 27, 2019 Release
Notes.
The following enhancements to the feature were implemented over the past month:
• Restricted access: To grant a user permissions in a sub account without granting the user access to the parent
account, you do not assign a role to the user in the parent account. Instead, you assign a role to the user in one
or more sub accounts only. Several changes were made to support this functionality:
• The explicit Access parent account permission was removed.
• You can create a user without assigning a role to the user. Note that the user must be granted a role in
the parent account or in at least one sub account to be able to log in to the Cloud Security Console.
• Roles API: An API was added for creating and managing roles. For details, see Role Management API Definition.
• New default role added: In addition to the default Administrator role, a new Reader role was added. The
Reader role grants view-only permissions to the assigned user in the account or sub account.
• Improved audit trail: Each action performed to create and manage roles and user role assignments generates a
specific audit message. For more details, see Audit Trail.
• UI enhancements: Miscellaneous UI bugs were fixed.
For more details on Role Management, see Manage Roles and Permissions.
New rule action to rewrite response code
A new rewrite action is now available for use when you create custom delivery rules.
The Rewrite Response Code action modifies the status code in the response from the origin server before sending it
back to the client.

Where it’s located: On the Cloud Security Console sidebar, navigate to Websites > Rules and click Add Rule. For
more details, see Create Rules.
New filters added to Audit Trail
In addition to the existing time filter, multi-select filters were now added to the Audit Trail Type and Context columns,
enabling you to view audit events for a specific subset of activities.
API Security: Additional details added to the Events page
For the API Specification Violation threat type, additional details are now displayed on the Events page.
What changed:
The following details were added:
• Violation type. Possible values:

• Invalid URL
• Invalid method
• Missing parameter
• Invalid parameter value
• Invalid parameter name
• Parameter name. The name of the targeted parameter. Present only when the violation occurs in the context of
a parameter.

Where it’s located: On the Cloud Security Console sidebar, click Websites > Events. In the Event Details column, click
More to view details about the requests in the event.
Heads Up: Additional attack details in logs
On December 8, 2019, a new field will be added to the Imperva logs, providing additional information on the violation
that triggers a security rule.
Detailed
Description
Additional
information on the
Additional rule info cs11 cs11 cs-ruleInfo violation that
JSON format.
This field will initially be used for API Specification Violation events only. The following JSON structure will be used:
{“api_specification_violation_type”:”<type>”,”parameter_name”:”<parameter name>”}
The possible values for api_specification_violation_type are:
• INVALID_URL
• INVALID_METHOD

• MISSING_PARAM
• INVALID_PARAM_VALUE
• INVALID_PARAM_NAME
If the violation occurs in the context of a parameter, the “parameter_name” will be present, and its value will be the
relevant parameter name.
For more details on the Imperva Cloud Application Security log integration, see Cloud WAF Log Integration.
Fixes
None.
Known Issues
None.
The November 3, 2019 release notes announced the planned removal of the option to view and revert to previous
versions of your custom rules.
In response to significant customer request, the removal of this feature has been postponed.
• Rule changes are currently tracked and available through the Imperva Audit Trail. All relevant details of rule
changes will be added to Audit Trail before the rule revision feature is removed.
• The option to revert to previous versions of rules will no longer be available after the rule revision feature is
removed.
The date of implementation will be communicated in future release notes.



New Features
None.
Enhancements
Self-service onboarding to Account Takeover Protection
Account Takeover Protection's capabilities to detect and mitigate account takeover attempts start with behavior
detection on login pages. To get started with ATO Protection, you need to provide details about your site's login
process.
What changed: You can now configure a login endpoint for your site directly from the Account Takeover Protection
interface. Previously, onboarding required the involvement of an Imperva sales engineer.
Where it’s located: The onboarding wizard is available from the ATO Protection Settings page.
Availability: Self-service onboarding is rolling out during the week of November 4, 2019.
For full details, see Onboarding Your Website.

API key expiration
When creating or resetting an API key and setting the expiration period, the Never option was added and set as the
default option. For more details, see API Key Management.
DDoS Protection for Networks and Individual IPs: Dashboard Enhancements
Additional information was added to the Network Ranges / IP Lists table in the Dashboard, providing you with an at-
a-glance view of DDoS attack status.
• Status column added: Provides attack status information for each range / IP covering the last 90 days.
• More column added: Click the button to view Layer 3/4 traffic analytics for the range. For a range with a
previous attack or currently under attack, a focused view of analytics data for the attack is displayed.
Where it’s located: On the Cloud Security Console sidebar, click Infrastructure > Dashboard.

For more details on the DDoS for Networks Dashboard and Analytics, see:

Fixes
None.
Known Issues
None.
On December 8, 2019, the option to view and revert to previous versions of your custom rules will be removed.
Where it’s located: On the Cloud Security Console sidebar, Websites > Rules > More > Revisions.

The corresponding APIs will also be removed:
• Revert rule
For details, see Site Management API.
These changes are being introduced as a part of our continued effort to provide an improved, simplified, and
consistent interface.


New Features
Introducing Roles for improved permission management
Create and manage roles to provide the appropriate level of permissions to your account users.
A role is a set of permissions granting a certain level of access to Imperva cloud assets and services. Role
Management includes creating and managing roles, and assigning those roles to your account users.
Availability:
• Currently available for customer accounts created after October 27, 2019 only. User permissions for other
accounts are managed directly in the Users page. For details, see Account Users.
• Not available for reseller accounts.
• Existing accounts will be migrated to Role Management in the next few months. To request an earlier migration
date, contact Support.
For full details, see Manage Roles and Permissions.

Enhancements
API key expiration
An expiration date is now set when you create a new API key or reset an existing API key.
What changed: When you add or reset an API key, an expiration date is set. Previously, API keys did not expire.
The default time period is six months. You can select the following time periods for expiration:
• 3 months
• 6 months
• 1 year
Where it's located: In the Cloud Security Console, navigate to Management > Users. Click a user row to display the
settings pane and expand API keys. For more details, see API Key Management.
Grace period:
• Expired API key: When an API key has expired, you can still use it for a grace period of two weeks.
• Reset API key: When you reset an existing API key, the previous key will still work for a period of two weeks from
its expiration date or from the time it is reset - whichever comes first.
• Additional reset during the two week grace period: Resetting the key more than once within the grace period
cancels any earlier key resets. The grace period is valid for the last reset only. The keys generated by previous
resets are no longer valid.

Extending the validity period of the API key: Email notifications will be sent to you before the API key expires. The
email will include a link enabling you to extend the validity of the API key for two weeks.
SSL site onboarding improvement
When onboarding an SSL site to the Imperva Cloud WAF, a certificate needs to be generated or uploaded and installed
on the Imperva proxy servers, in addition to the certificate already installed on your origin servers.
If there is an issue with your origin server’s certificate, Imperva now displays additional details onscreen to identify
the specific issue to assist you in resolving it quickly. For example, the connection may have timed out, or the
certificate may be expired.
Note that a site will onboard successfully if the SSL handshake is successful during the onboarding process, even if the
certificate is expired. It is recommended to resolve any certificate issues promptly for optimal security.
For more details on the onboarding process, see Onboarding a Site – Web Protection and CDN.
Enhanced blocking of HTTP request smuggling
Smuggling attacks can enable attackers to gain unauthorized access to or otherwise compromise your site or
application. The following changes are being implemented to protect against smuggling attacks.
If an HTTP request contains one or more of the following, it will now be blocked:
• Multiple Content-Length headers with different values.

• Multiple Content-Type headers with different values.
• Spaces or tabs before the first header.
• A header in the following format: <header-name><header-value>, with no separating colon.
• \r or \n in a header name.
• Transfer-Encoding: chunked and Content-Length headers are both specified, but the total body length (raw,
including chunking metadata) does not match the Content-Length value.
• The Transfer-Encoding header contains an illegal value.
• Multiple Transfer-Encoding headers with different values.
Availability: The changes are being rolled out over the next week.
All HTTP method names are reported
Whenever HTTP methods are displayed in the Cloud Security Console, for example on the Events page, all method
types are now supported and displayed.
What changed: Previously, the method type was listed as GET, POST, or OTHER. Now each method type that would
have been displayed as OTHER is listed as its proper type, such as PUT or DELETE.
Enterprise parent accounts can now retrieve logs for sub accounts
Enterprise accounts can now activate logs for the account’s sub accounts, directly from the parent account.

What changed: Previously, the log integration for sub accounts could be activated and configured only from the sub
account. To retrieve the sub accounts' logs, you had to enter each sub account and configure the log integration. Now,
logs can be activated and configured from both the parent account and the sub account.
Where it’s located: On the Cloud Security Console sidebar, select Logs.
In the parent account, you now have the following options:
• Accounts Log Levels: (New) Activate logs for each sub account. Once activated, logs are collected for all sites in
the sub account and retrieved according to the method configured in the Logs Setup page for the account.
• Sites Log Levels: (No change) Activate logs for sites in the parent account. Activate logs on a per site basis.
Log page renamed in the Cloud Security Console
In accounts without sub accounts, or in sub accounts, the Log Levels page was renamed to Sites Log Levels. This
page enables you to activate logs for sites in your account. There is no change in existing functionality.
Fixes
None.
Known Issues
None.



New Features
None.
Enhancements
Attack Analytics Insights API
You can now retrieve a list of actionable insights using the API. The insights are recommended actions to follow based
on security incidents presented in Attack Analytics. For details, see Attack Analytics API.
For more details on Attack Analytics Insights, see Get Actionable Insights.
Audit Trail updates
The following updates were made to the Audit Trail:
• Audit history: Audit actions that were recorded by Imperva prior to the opening of the new Audit Trail feature
have been migrated and can now be viewed in the Audit Trail page.
• Audit events: A list of audit actions is now available in the documentation. For details, see Audit Trail Event
Types.
Origin access port rewrite
You can now rewrite the port number that is used to access the origin. This enables you to, for example, redirect
incoming requests to an origin port secured behind your firewall..
Where it's located: On the Cloud Security Console sidebar, navigate to Websites > Delivery. On the Delivery Settings
page, in the Network section, use the Rewrite Port option.

For more details, see Delivery Settings.
New rule actions added for origin responses
Two new rule actions were added to the Rules interface in the Cloud Security Console.
The Rewrite Response Header and Remove Response Header rule actions enable you to modify, add, and remove
headers from the response. When the defined rule criteria are met, Imperva receives the response from the origin
server, applies the relevant changes, and then returns the response to the client.
Where it’s located: On the Cloud Security Console sidebar, navigate to Websites > Rules and click Add Rule. For
The Add Rule and Edit Rule APIs were also updated with the new rule actions.
• RULE_ACTION_RESPONSE_REWRITE_HEADER
• RULE_ACTION_RESPONSE_REMOVE_HEADER
SEO support
To support recent changes made to Googlebot, the Google web crawler used to index web content for its search
engine, the following change was implemented:

The X-Robots-Tag: noindex HTTP header is now added to resources that are part of the Imperva Cloud WAF’s
JavaScript challenge mechanism.
This header indicates that these resources should not be crawled or indexed.
Heads Up: Rate limit on Get Visits API
To ensure maximum availability of service for our customers, a rate limit for the Get Visits API will be implemented
within the next several weeks. Details to follow.
For more details on the Get Visits API, see Traffic Statistics and Details API.
Documentation update
When website visitors are trying to access your site or application and encounter an error, Imperva displays an error
page with information to help you identify the error in your account in the Cloud Security Console. Details include:
• error code
• time stamp
• the source IP address of the request
• the IP address and internal ID of the Imperva proxy that handled the request
• the incident ID
A list of the error codes and troubleshooting suggestions is now available here: Cloud WAF Error Pages and Codes.
Fixes
None.
Known Issues
None.


New Features
None.
Enhancements
Audit Trail API
You can now retrieve audit activity for your account using the API. For details, see Imperva Audit Trail API Definition.
For details on viewing the Audit Trail page from the Cloud Security Console, see Audit Trail.
Google Authenticator security enhancement
Existing functionality: Google Authenticator is used for user authentication by Imperva as a part of several features:
• Login Protect: Google Authenticator is one of the methods used for authenticating visitors who are attempting
to access protected pages on your website. For more details on Google Authenticator configuration, see Web
Protection - Login Protect.
• Two-factor authentication: Google Authenticator is one of the available user authentication methods for login
to your account in the Cloud Security Console. For more details on two-factor authentication, see User
Preferences.
What changed:
• The Google Authenticator QR code that is generated and stored by Imperva is now encrypted. Once the code
has been scanned by the Google Authenticator app, it is no longer accessible. If Login Protect or two-factor
authentication needs to be reconfigured by the user, a new code is generated.
• As part of this change, Google Authenticator QR codes were reset. Visitors/users who choose to use Google
Authenticator as their authentication method will be required to reactivate it:
• Login Protect: On the next attempt to access protected pages on your website.
• Two-factor authentication: On the next login to the Cloud Security Console.
• A reset option is now available for the Google Authenticator QR code, if, for example, a user needs to enable it
using a new device.
Enhanced cache settings design
In our continued effort to further improve and simplify the Imperva Cloud Security Console, we are rolling out the
following design changes over the next few weeks.
These changes do not affect the caching functionality or your current cache settings.
• Cache modes were renamed:
From To Description
Resources are cached according
Disable caching Custom caching to custom cache rules only. If
there are no custom cache rules

From To Description
defined for the site, no caching is
performed.
Cache according to standard
Static only Standard caching
HTTP headers.
Dynamic pages are also profiled
to identify and cache static
Static and dynamic Smart caching
content that was not marked as
static.
All site content is cached for a
All resources Cache all
specified amount of time.
Note: In addition to caching according to the selected mode, content is also cached as specified by any custom
cache rules that are defined for your site.
• The Secure Resource options are now integrated directly with cache mode settings. These options are available
for SSL sites and enable you to define caching behavior for HTTPS resources.
For full details, see Cache Settings.
Duplicate headers blocked for enhanced security
To improve our mitigation capabilities against HTTP request smuggling attacks, requests with duplicate Content-
Type or Content-Length HTTP headers that contain different values are now blocked. Previously, such requests were
passed on to the customer origin servers.
Fixes
None.
Known Issues
None.


New Features
DDoS protection for individual IPs over IP-in-IP
The IP Protection service is now available over IP-in-IP encapsulation, providing DDoS protection at the IP level for
your cloud assets, such as websites or applications hosted on Google Cloud Platform.
IP Protection over IP-in-IP is deployed as an always-on service. Traffic flow is symmetric, where both ingress and
egress traffic flow through the Imperva network via an IP-in-IP tunnel. The service provides Layer 3/4 protection
against volumetric and protocol DDoS attacks, and is backed up by Imperva’s SLA.
Onboarding: Contact your Imperva sales representative to get started. Imperva assigns a sales engineer or solution
manager to take responsibility for the onboarding process, and to work with you to set up Imperva DDoS Protection
for individual IPs over IP-in-IP.
For details on onboarding and configuring IP Protection over IP-in-IP, see Onboarding IP Protection over GRE or IP-in-
IP.
After onboarding, you can view statistics for the Protected IP in the Security Dashboard: DDoS Protection for Networks
and IPs and in Analytics: DDoS Protection for Networks and IPs.
Enhancements
CRL support for client certificate validation
If client certificate support is enabled for your site, you can now upload a Certificate Revocation List (CRL) file via the
Imperva API to verify whether certificates are valid and trustworthy. A CRL is a list of certificate numbers that have
been revoked by the issuing CA, and should therefore be blocked.
For details, see Upload a CRL.
Log field changes
Request Headers and Response Headers fields were added to Imperva logs.
• They are supported by default for the W3C format only.

• Use of these fields for CEF and LEEF formats requires enablement by Imperva Support.
Description CEF LEEF W3C Details

Request headers in
JSON format, with
cs-
Request Headers additionalReqHeadersadditionalReqHeaders each field
additionalReqHeaders
represented as
name-value pair.
Response headers in
cs-
Response Headers additionalResHeadersadditionalResHeaders JSON format, with
additionalResHeaders
each field


represented as
name-value pair.
The following examples show the new fields added to the Imperva log file in the supported formats. The new fields
are displayed in bold.
Example of CEF Access and Security Events
CEF:0|Incapsula|SIEMintegration|1|1|Illegal Resource Access|3| fileid=3412341160002518171

sourceServiceName=site123.abcd.info siteid=1509732 suid=50005477 requestClientApplication=Mozilla/5.0 (Windows
NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 deviceFacility=mia cs2=true cs2Label=Javascript Support
cs3=true cs3Label=CO Support ccode=IL tag=www.elvis.com cn1=200 in=54 xff=44.44.44.44 cs1=NOT_SUPPORTED
cs1Label=Cap Support cs4=c2e72124-0e8a-4dd8-b13b-3da246af3ab2 cs4Label=VID
cs5=de3c633ac428e0678f3aac20cf7f239431e54cbb8a17e8302f53653923305e1835a9cd871db32aa4fc7b8a9463366cc4
cs5Label=clappsigdproc=Browser cs6=Firefox cs6Label=clapp ccode=IL cicode=Rehovot cs7=31.8969
cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=CEFcustomer123 start=1453290121336
request=site123.abcd.info/ requestmethod=GET qstr=p\=%2fetc%2fpasswd app=HTTP
act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 src=12.12.12.12 ver=TLSv1.2 ECDHE-
RSA-AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-
interaction-id":"1.1.1.1"}] additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}]
filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name
Example of CEF Access Event
CEF:0|Incapsula|SIEMintegration|1|1|Normal|0| sourceServiceName=site123.abcd.info siteid=1509732 suid=50005477

requestClientApplication=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
deviceFacility=mia ccode=IL tag=www.elvis.com cicode=Rehovot cs7=31.8969 cs7Label=latitude cs8=34.8186
cs8Label=longitude Customer=CEFcustomer123 ver=TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 start=1453290121336
request=site123.abcd.info/main.css ref=www.incapsula.com/lama requestmethod=GET cn1=200 app=HTTP
deviceExternalID=33411452762204224 in=54 xff=44.44.44.44 cpt=443 src=12.12.12.12 ver=TLSv1.2 ECDHE-RSA-
AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-
Example of LEEF Access and Security Events
LEEF:0|Incapsula|SIEMintegration|0|SQL Injection| fileId=3412364560000000008

sourceServiceName=test56111115.incaptest.co siteid=1333546 suid=300656 requestClientApplication=Mozilla/5.0
(Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 popName=mia cs2=true cs2Label=Javascript Support
cs3=true cs3Label=CO Support cs1=NA cs1Label=Cap Support cs4=936e64c2-bdd1-4719-9bd0-2d882a72f30d
cs4Label=VID
cs5=bab1712be85b00ab21d20bf0d7b5db82701f27f53fbac19a4252efc722ac9131fdc60c0da620282b02dfb8051e7a60f9
cs5Label=clappsig dproc=Browser cs6=Firefox cs6Label=clapp calCountryOrRegion=IL cicode=Rehovot cs7=31.8969
cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=siemtest start=1460303291788
url=test56111115.incaptest.co/ requestMethod=GET
qstr=keywords\=3%29%29%29%20AND%203434%3d%28%27%3amvc%3a%27%7c%7c%28SELECT%20CASE%203434%20WHEN%2
cn1=200 proto=HTTP cat=REQ_PASSED deviceExternalId=2323800832649 dst=54.195.35.43 dstPort=80 in=406
xff=127.0.0.1 srcPort=443 src=127.0.0.1 protoVer=TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 end=1566300670892
additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-interaction-id":"1.1.1.1"}]

additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}] fileType=12999,50999,50037,50044,

filePermission=37,20,1,1, cs9=,High Risk SQL Expressions,,SQL SELECT Expression, cs9Label=Rule name
Example of W3C Header for Each Log File
#Software: Incapsula LOGS API#Version: 1.0
#Date: 20/Jan/2016 14:22:15
#Fields: date time cs-vid cs-clapp cs-browsertype cs-js-support cs-co-support cs-clappsig s-capsupport s-suid
cs(User-Agent) cs-sessionid s-siteid cs-countrycode s-tag cs-cicode s-computername cs-lat cs-long s-accountname sr-
pop cs-uri cs-postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-status s-xff
cs-bytes cs-start c-port cs-rule c-ip cs-protver cs-end cs-additionalReqHeaders cs-additionalResHeaders cs-severity
cs-attacktype cs-attackid s-ruleName
Example of W3C Access and Security Events
"2016-01-20" "14:21:20" "14114780-8939-4a38-bf21-1c5fd4f528f7" "Firefox" "Browser" "true" "true"

"de3c633ac428e0678f3aac20cf7f239431e54cbb8a17e8302f53653923305e1835a9cd871db32aa4fc7b8a9463366cc4"
"NA" "50005518" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0"
"3412341160002581277" "1594476" "US" "" "Dover" "fullLevelW3C.test.co" "mia" "39.1588" "39.1588" "w3cFullName"
"fullLevelW3c.test.co/" "" "HTTP" "REQ_BLOCKED_SECURITY" "43524464361744448" "" "" "" "GET"
"p=%2cEXTRACTVALUE%28as%2cconcat%28" "" "" "443" "" "12.12.12.12" "TLSv1.2 ECDHE-RSA-AES128-GCM-
SHA256" "1566300670892" "{\"Accept\":\"*/*\"},{\"x-v\":\"1\"},{\"x-fapi-interaction-id\":\"1.1.1.1\"}]"
"[{\"Content-Type\":\"text/html; charset\=UTF-8\"}]" "0" "50999" "16" "High Risk SQL Expressions"
Example of W3C Access Event
"2016-01-20" "14:19:47" "" "" "" "" "" "" "" "555" "curl/7.33.0" "" "1177375" "IL" "" "Rehovot" "AccessLevelW3C.test.co"
"mia" "" "" "w3cACCESS" "accesslevelw3c.test.co/" "" "HTTP" "" "26210617967913034" "" "" "" "GET" "" "200" ""
"956" "443" "" "12.12.12.12" "TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256" "1566300670892" "{\"Accept\":\"*/*\"},
{\"x-v\":\"1\"},{\"x-fapi-interaction-id\":\"1.1.1.1\"}]" "[{\"Content-Type\":\"text/html; charset\=UTF-8\"}]" ""
"" "" ""
Fixes
None.
Known Issues
None.


2019-09-08 Release
New Features
None.
Enhancements
Password reset change
When resetting the password for an account user, a password reset link is displayed. The account admin can then
send the link to the user.
What changed: Previously, the new password was displayed onscreen.
Where it’s located: On the Cloud Security Console Account users page, click a user row and select Actions > Reset
password. This page is visible to account admin users and any user with the Manage users permission.
For more details, see Account Users.
New rule filter parameters added
The following new filter parameters were added to the Rules interface. These parameters can be used with Delivery
Rules, for example, to create a granular GeoIP based forwarding policy.
• City
• Epoch
• Latitude
• Longitude
• Postal Code
• Src port
• State
IP Protection egress traffic update
Egress traffic for IP Protection will now be included in the calculation of account bandwidth utilization, in accordance
with the existing bandwidth calculation method.
For more details on bandwidth calculation, see Account Bandwidth Calculation.
Where it's located: You can view bandwith usage and billing details on the Cloud Security Console Subscription page
(Management > Subscription).
• For existing Infrastructure Protection customers, the IP protection bandwidth is calculated as part of Always On
Infrastructure Protection Bandwidth:

• For Cloud WAF customers without Infrastructure Protection, the IP protection bandwidth is calculated as part of
Always On Bandwidth for Cloud WAF/DDoS Protection, and listed here as Edge IP bandwidth:
Egress traffic is displayed in the Infrastructure Protection Dashboard for Protected IPs, in addition to ingress traffic.
Where it’s located: You can view egress traffic in the Infrastructure Protection Dashboard, in both the graph and
table, as follows:
• Select Protected IPs view.

• Select Traffic > Passed.
Fixes
None.
Known Issues
None.

2019-09-01 Release
New Features
Introducing Audit Trail
Gain full visibility into the actions performed in your account by account users, system processes, and Imperva system
administrators and support.
Benefits:
• Provides full visibility at all times into which actions were performed, when they were performed, and by whom.
• Supports decision-making by providing visibility into change management.
• Speeds up troubleshooting - quickly see who did what, when, and where.
Availability: The feature is currently being rolled out and will be available to all Enterprise plan accounts within the
next several weeks. The Audit Trail will display account activity that occurs after the feature has been enabled for your
account.
Where it’s located: In the Cloud Security Console, navigate to Management > Audit Trail and click the launch button.
For full details, see Audit Trail.

Actionable Insights in Attack Analytics
Attack Analytics now provides recommended actions for mitigating attacks that have targeted your sites and
applications, and for proactively protecting against future attacks. Learn about the steps you can take to enhance your
security posture.
Benefits of Insights:
• Enhance your configuration settings and the organization's security policy

• Speed up mitigation and reduce false negatives
Availability: For Cloud WAF customers only. The insights are based on the analysis of attacks on your account in
conjunction with your account configuration settings, which are not currently linked to your on-premises WAF
settings. Therefore, recommended actions are currently supported for Cloud WAF only.
In the Attack Analytics Dashboard, click the Insights button in the banner to view the recommended actions for your
account.
For details, see Get Actionable Insights.

Enhancements
Attack Analytics Dashboard update
The Attack Analytics Dashboard now opens by default when you log in, enabling you to view the distribution of top
metrics and then drill down for a more detailed look. Previously, the Incidents View was the default.

Update in password policy
In addition to the changes in password policy announced in August 18, 2019 release notes, the following restrictions
are now implemented:
• Restriction on using 6 previous passwords

• 6 failed attempts to log in to the Cloud Security Console lock the user out for 30 minutes
Log field change
The following fields are being added to Imperva logs this week.
The Request Headers and Response Headers fields are added to support an upcoming feature. They are currently
added as placeholders only (empty) and relevant to the W3C format only.

The end time of the
Response End Time end end cs-end response to the
request, in UTC.


Request headers in
JSON format, with
cs-
Request Headers each field
represented as
name-value pair
Response headers in
JSON format, with
cs-
Response Headers each field
represented as
name-value pair
The following examples show the new fields added to the Imperva log file in the supported formats. The new fields
are displayed in bold.

RSA-AES128-GCM-SHA256 end=1566300670892 filetype=30037,1001, filepermission=2,1, cs9=Block Malicious
User,High Risk Resources, cs9Label=Rule name

cs8Label=longitude Customer=CEFcustomer123 ver=TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 start=1453290121336
request=site123.abcd.info/main.css ref=www.incapsula.com/lama requestmethod=GET cn1=200 app=HTTP
AES128-GCM-SHA256 end=1566300670892

cs4Label=VID

cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=siemtest start=1460303291788

fileType=12999,50999,50037,50044, filePermission=37,20,1,1, cs9=,High Risk SQL Expressions,,SQL SELECT
Expression, cs9Label=Rule name
#Date: 20/Jan/2016 14:22:15
pop cs-uri cs-postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-status s-xff
cs-bytes cs-start c-port cs-rule c-ip cs-protver cs-end cs-additionalReqHeaders cs-additionalResHeaders cs-
severity cs-attacktype cs-attackid s-ruleName

"3412341160002581277" "1594476" "US" "" "Dover" "fullLevelW3C.test.co" "mia" "39.1588" "39.1588" "w3cFullName"
"fullLevelW3c.test.co/" "" "HTTP" "REQ_BLOCKED_SECURITY" "43524464361744448" "" "" "" "GET"
SHA256" "1566300670892" "" "" "0" "50999" "16" "High Risk SQL Expressions"
"mia" "" "" "w3cACCESS" "accesslevelw3c.test.co/" "" "HTTP" "" "26210617967913034" "" "" "" "GET" "" "200" ""
"956" "443" "" "12.12.12.12" "TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256" "1566300670892" "" "" "" "" "" ""
Fixes
None.
Known Issues
None.


2019-08-25 Release
New Features
None.
Enhancements
View Account Takeover Protection events in the Cloud Security Console
What changed: For sites configured in Imperva Account Takeover (ATO) Protection, account takeover attempts are
now displayed in the Cloud Security Console Events page.
Where it’s located: In the Cloud Security Console, navigate to Websites > Events.
Heads up: Log field changes
The following fields will be added to Imperva logs in the coming weeks. Details to follow in subsequent release notes.
Request Headers and Response Headers fields:
• The header fields are being added to support an upcoming feature.

• When implemented, they will be supported by default for the W3C format only.
• Use of these fields for CEF and LEEF formats will require enablement by Imperva Support.

The end time of the
Response End Time end end cs-end response to the
request, in UTC.
Request headers in
cs-
Request Headers additionalReqHeaders
additionalReqHeaders JSON format, with
each field


represented as
name-value pair
Response headers in
JSON format, with
cs-
Response Headers additionalResHeadersadditionalResHeaders each field
represented as
name-value pair
Update in password policy
In addition to the changes in password policy announced in August 18, 2019 release notes, the following restriction is
now implemented:
6 failed attempts to log in to the Cloud Security Console now lock the user out for 30 minutes.
Fixes
None.
Known Issues
None.

2019-08-18 Release
New Features
None.
Enhancements
Enriched IP reputation information in Attack Analytics
Attack Analytics now provides you with richer detail on the IP addresses attacking your sites.
Drawing on additional sources of threat detection based on our customer base and crowdsourcing capabilities, we
have added more information on the attacking IPs to help you take more data-driven decisions when deciding
whether an IP and an incident are malicious or not.
What changed: IP Reputation information that is displayed in Attack Analytics now includes additional reputation
categories.
Where it’s located: In the Attack Analytics Incident Details view, under Which IPs did the attacker use?, IP
Reputation indicators are displayed.
Password policy change for Cloud user accounts
As an added security measure and to meet PCI compliance requirements, a maximum password age and stronger
policy has been implemented for users logging in to the Cloud Security Console.
Note: This change does not affect organizations that log in to the Cloud Security Console via SSO.
Your login password can now be used for 90 days, and must then be changed. If the password expires, you will not be
able to administer your account and sites before changing your password.
Password requirements:
• Minimum length of 8 characters

• Must include at least one of each of the following: numeric character, uppercase letter, lowercase letter, and
special character
This change is being rolled out over the next several weeks.
Additional changes in the password policy will include:

• restrictions on reusing previous passwords

• a limit on the number of failed login attempts within a given time limit that are allowed before the account is
locked
These changes will be communicated in subsequent release notes as they are implemented.
Fixes
None.
Known Issues
None.

2019-08-11 Release
New Features
None.
Enhancements
Enhanced cache settings design
In our continued effort to further improve and simplify the Imperva Cloud Security Console, we are rolling out the
following design changes over the next few weeks.
These changes do not affect the caching functionality or your current cache settings.
• Cache modes were renamed:
From To
Disable caching <no change>
Static only Standard caching
Static and dynamic Smart caching
All resources Cache all
• The Secure Resource options are now integrated directly with cache mode settings.
These options are available for SSL sites and enable you to define caching behavior for HTTPS resources.
For full details, see Cache Settings.
Cache rules filter logic enforcement
The following changes were made to the Add/Edit Rule page for Cache Rules.
• Only the rule filter parameters that are supported for cache rules are now displayed in the filter list. Other filters
were removed.
• The Cache Resource rule action cannot be used with some filters. These filters are marked with an asterisk.
• Additional validation checks were implemented to ensure that the selected filters can be used with the selected
action. Otherwise, the rule cannot be saved.

Improved visibility of graphs in the Infrastructure Protection Dashboard
In the Infrastructure Protection Dashboard, graphs now display data for up to 5 of the top PoPs or Ranges by default.
Previously, all data was displayed by default.
You can select additional PoPs or ranges or modify the selection using the legend below the graph.
Where it’s located: In the Infrastructure Protection Dashboard, select View by Ranges or View by PoP.
Up to 5 of the top PoPs or Ranges are displayed, according to max values of the selected view. For example, this graph
displays the top 5 ranges for total traffic.

Fixes
None.
Known Issues
None.

2019-08-04 Release
New Features
None.
Enhancements
Update of HTTP/2 options
The following changes were implemented for the HTTP/2 option. This option enables supporting browsers to take
advantage of the performance enhancements provided by HTTP/2 for your websites.
• A new http_2 parameter was added to the Advanced Caching Settings and Get Advanced Caching Settings
API. For details, see Site Management API.
• The Enable HTTP/2 site-level option was moved from the Websites > Settings > General page to the Websites
> Settings > Delivery page. For details, see Delivery Settings.
HTTP/2 support requires that SSL is configured for the site.
Option added for caching 404 responses
An option was added to enable Imperva to cache unavailable resources for a specified amount of time for your sites.
This can be useful to reduce load on your origin server if, for example, your site is getting too many hits on an
unavailable page.
• Cloud Security Console: Websites > Cache > Cache 404 Responses. The option is disabled by default. For
details, see Cache Settings.
• API: Site Management API > Modify Cache 404 Settings and Get Cache 404 Settings. For details, see Site
Management API
Support added for the HTTP Range request header
If your origin web server supports client requests using the HTTP Range header, and caching is enabled for your
Imperva protected site, the responses will now be cached by Imperva.
Note: The Range header must request the full range of data.
This change expands Imperva current caching capabilities by enabling caching of additional resources, such as small
videos.
Change in feature format
Heads up: Change in weekly report
Imperva produces a weekly report for every account that chooses to receive it. The report contains general
information on the account as well as all sites under the account.

What’s changing: The format of the weekly report email, which currently includes the contents of the report and a
link to download a PDF version of the report, will now include the link only.
Where it’s located: Cloud Security Console > Management > Account Settings.
Rollout: The change is expected to be implemented in the next several weeks.

Fixes
None.
Known Issues
None.

2019-07-28 Release
New Features
None.
Enhancements
Network layer data storage for Website DDoS Protection customers
What changed: As part of ongoing improvements to the Network Traffic Dashboard, we are starting to collect Layer 3
(network layer) data statistics.
Stored data includes network layer 3/4 headers, which contain IP addresses .
By default, the data storage region for this collected data is US. You can update the region in accordance with your
data privacy requirements, such as GDPR.
Where it’s located: To check or modify this setting, log in to your account in the Cloud Security Console, and navigate
to Management > Account Settings > Data Management.
Note: The account-level data region setting determines where network layer data is stored, regardless of site-level
data region settings.
For more details on regional data storage, see Data Storage Management.
XRAY debug headers added for cache rules
To further enhance visibility into Imperva caching behavior and assist you in troubleshooting, the following XRAY
debug headers were added for cache rules:
incap-cache-tags: Lists the tags added to the resource by cache rules. The list includes tags that were defined by the
Create Tag and Enrich Cache Key cache rules. It does not contain tags defined by the origin.
incap-cache-rules: Lists the IDs of cache rules triggered by the request.
For more details, see XRAY Debug Headers.

Fixes
None.

Known Issues
None.

2019-07-21 Release
New Features
None.
Enhancements
View ATO Protection username data in cleartext
To protect the privacy of your users, username fields containing personally identifiable information (PII) are encrypted
by default and displayed as an encoded string in the Account Takeover Protection console.
What changed: To access the username details for the users who attempt to log in to your protected sites, you can
now configure Account Takeover Protection settings to display username data in cleartext.
Where it’s located: ATO Protection Dashboard > Settings > Personally Identifiable Information (PII) Management.
For more details, see View Username Data.
Improved interface for purging the cache
Recent changes to the Purge Specific Resources dialog box provide you with an improved user experience, including
an autocomplete enabled drop-down list of your custom-defined tags to assist you in purging the cache according to a
specific tag.
Where it’s located: On the Cloud Security Console Cache Settings page, click Purge Specific Resources.
For more details, see Cache Settings.
Redirect parameters added to API
The following parameters were added to the Advanced Caching Settings and Get Advanced Caching Settings APIs:
Redirect HTTP requests to HTTPS requests by

redirect_http_to_https
sending an HTTP 301 response.
Redirect requests from your website's naked domain
redirect_naked_domain_to_full to its full domain by sending and HTTP 301
response.
For more details, see Site Management API.
Custom certificate status available by API
If your site is using a custom certificate, you can retrieve details on the certificate’s status using the Get site status
and Upload custom certificate APIs.
The details are displayed in the ssl.custom_certificate section of the response.

Mask sensitive data using hashing
What changed: You can now enable the hashing method for masking data fields in your logs and in the Events page,
instead of the default (XXX) data masking.
Use the hashing method and add a salt value to add increased protection for your sensitive information.
Where it’s located: On the Cloud Security Console sidebar, navigate to Websites > Settings > General. Under Data
Storage and Privacy, enable the Mask data by hashing option. For more details, see Web Protection - General
Settings.
You can also configure the data masking settings using the API. For details, see Masking Settings API.
Luhn algorithm for data masking
We are currently starting rollout of the Luhn algorithm as the default method for data masking. The Luhn algorithm is
a formula used to validate identification numbers, such as credit card details.
What changed: Luhn replaces our in-house algorithm, improving our ability to identify identification numbers, such
as credit card details. It helps reduce false positives that we currently see when we incorrectly identify parameters as
credit card details and mask them.
Rollout: The rollout process is expected to take about two weeks.

Change in feature format
Heads up: Change in weekly report
Imperva produces a weekly report for every account that chooses to receive it. The report contains general
information on the account as well as all sites under the account.
What’s changing: The format of the weekly report email, which currently includes the contents of the report and a
link to download a PDF version of the report, will now include the link only.
Where it’s located: Cloud Security Console > Management > Account Settings.
Rollout: The change is expected to be implemented on August 4, 2019.

Fixes
None.
Known Issues
None.


2019-07-14 Release
New Features
None.
Enhancements
Cache Shield enabled by default
Cache Shield is now enabled by default for new sites added to FlexProtect Plus and Premier plan accounts. Previously,
you needed to manually enable each site in the Cloud Security Console.
Cache Shield adds an intermediate cache between other Imperva PoPs and your origin servers to protect your servers
from redundant requests.
For more details, see Cache Shield.
New APIs for caching and delivery settings
The following new APIs are now available, enabling you to retrieve information on your cache and delivery settings for
a specific site.
• Get caching mode

• Get cached response headers
• Get header to tag responses by
• Get stale content settings
• Get advanced caching settings
• Is Cache Shield enabled
SIEM integration with LogRhythm
A SIEM integration package for LogRhythm is now available in GitHub.
Where it’s located: A link to the package is located in the Cloud Security Console’s Logs Setup page.
For details, see Cloud WAF Log Integration.
Attack Analytics log integration update
The following new fields were added to the Attack Analytics logs:
Attack Analytics Corresponding

CEF Field Description
Field
The dominant attack type
cs7 Dominant attack type
identified for the incident.
cs7Label Label of attack type. ImpervaAAAttackType

Attack Analytics Corresponding

CEF Field Description
Field
Top 10 dominant external site IDs
cs8 Top 10 external site IDs
attacked in the incident.
cs8Label Label for top 10 dominant site IDs. ImpervaAADominantSiteIds
For more details, see Attack Analytics Logs.
GeeTest CAPTCHA added to Login Protect for client requests from China
We are currently rolling out new functionality enabling Login Protect to work in China with GeeTest CAPTCHA.
The GeeTest CAPTCHA will be presented by Login Protect to clients from China, based on the client’s IP geolocation.
New rule filter parameters added
To support recent changes to caching capabilities and to allow improved tuning of application security, the following
new rule filter parameters are now available:
Parameter Description
Checks for the specified string patterns in the cookie
Cookie Value
name and value in the client request.
Checks for the specified cache tag in the client

Has Cache Tag
request.

Fixes
None.
Known Issues
None.


2019-07-07 Release
New Features
None.
Enhancements
Attack Analytics API Updates
The following updates were made to the Attack Analytics API:
• The response structure of the waf_origins_of_blocks, waf_origins_of_alerts, and waf_origins_entities

response parameters was modified.
• For fields containing key/value lists, such as blocked_events_timeseries, value was changed to count in the
response.
• New: A new API resource was added: /v1/incidents/{incidentId}/sample-events - enables you to retrieve raw
data for a sampling of events in the incident, to examine parameter or HTTP header values, and use them to
identify attack vectors.
For details, see Attack Analytics API.

Fixes
Disabling caching closes cache-related toggles
The following fix is being rolled out over the next few weeks.
Problem: When you disable caching, toggles for the following options remained on, although the actual functionality
was turned off.
• Use the Same Cache For Full and Naked Domains

• Cache Shield
• Cache Empty Responses
• Cache 3xx Responses
• Cache HTTP 1.0 responses
• Enable Client-Side Caching
• Send Age Header
Solution: When you select Disable caching cache mode, the toggles listed above, as well as the other relevant
toggles which are already disabled, are all now turned off in the UI and cannot be modified.
If Disable caching was already selected for your site, the toggles will now be set to off. There is no change to actual
behavior - the functionality was already turned off.
Where it’s located: In the Cloud Security Console > Website > Cache Settings page.
Note: This behavior occurs only when there are no cache rules defined for the site. If there are cache rules, there is no
change to these toggles, and caching is carried out according to the custom rules you have defined.

Known Issues
None.

2019-06-23 Release
New Features
None.
Enhancements
New DDoS mitigation Service Level Agreement
A new SLA is applicable to Imperva Cloud Application Security customers who joined or renewed the service on or
after June 1st, 2019.
What changed:
Imperva previously offered a 10-second DDoS mitigation time, which is now reduced to 3 seconds for “Always On”
services.
To download the full SLA, log in to your account in the Cloud Security Console, and navigate to the Subscription page:
Management > Subscription.
DDoS attack notifications for Website DDoS Protection customers
This release introduces email notifications for Layer 3/4 DDoS attacks targeting your account.
What changed:
In addition to listing DDoS start and end events in the Network Traffic Dashboard, you will now also receive email
notifications for the start and end events.
For more details on system notifications, see Notifications.
Note:
This enhancement is being rolled out.
New rule filter parameters operators
To provide more granularity and control, there are new options to the Param Value rule filter that support numeric
values.
What changed:
The existing Param Value parameter can now have the following operators:
• > greater than

• < less than
• >= greater than or equal to
• =< less than or equal to
These operators are used to compare numeric values

Under Website Protection > Site > Rules, when adding or editing a rule.

Fixes
None.
Known Issues
None.

2019-06-16 Release
New Features
None.
Enhancements
Create and view simplified redirect rules in the Cloud Security Console
You can now create and view simplified redirect rules on the Cloud Security Console Rules page.
Simplified redirect rules enable you to create up to 20,000 redirect rules with restricted settings per site in your
account. This is in addition to existing functionality that enables you to create up to 500 delivery and security rules per
site.
What changed:
• In addition to creating simplified redirects rules using the API, an option was added to create and view them on
the Rules page.
• When this option is enabled for an account, rules created via the API are also displayed on the Rules page.
For guidelines on creating simplified redirect rules, see Create Simplified Redirect Rules.
Fixes
None.
Known Issues
None.
Change in availability of the Dynamic Content Acceleration service
During the beta period for Dynamic Content Acceleration we enabled the capability for all Imperva customers at no
additional cost.
Now, as the capability is mature and stable, we are disabling it for non-Enterprise customers who were able to take
advantage of the service at no additional cost.
What changed: The Dynamic Content Acceleration service was disabled for non-Enterprise plan customers who had
already enabled the feature. The functionality was turned off for these accounts and the Origin PoP option is now
read-only.
If you are using Imperva’s Enterprise subscription, there is no change in functionality.
If you’d like to upgrade to an Enterprise plan and keep using Dynamic Content Acceleration, please contact us.


2019-06-02 Release
New Features
Introducing Account Takeover Protection
Release Date: May 30, 2019
Account Takeover (ATO) Protection detects and mitigates account takeover attempts to protect your web applications
against volumetric and low and slow ATO attacks.
Benefits include:
• Real-time login protection with no added latency

• Maximal mitigation, minimal false positives
• Minimal user configuration and interaction
• Clear visibility into attack attempts, users at risk, and compromised user accounts
Imperva Account Takeover Protection is part of the Imperva Cloud Application Security suite.
For more details, see the Account Takeover Protection.
Introducing API Security
Release Date: May 28, 2019
Imperva is excited to announce that its solution to further support Defense-in-Depth now includes API Security. Please
note that from this past Tuesday, May 28th, API Security became available for self-service trials within the Cloud
Security Console and will be inclusive within FlexProtect Pro, Plus, and Premier tiers.
Imperva API Security is part of the Imperva Cloud Application Security suite, allowing you to protect your APIs.
Benefits include:
• Leveraging of the SaaS infrastructure and the CDN and DDoS capabilities of Imperva Cloud Application Security
suite, and uses the same management portal.
• Positive security model that is automatically created and enforced from your Open API specification document
(i.e. Swagger).
• New security event for positive security model event – “API Specification violation”.
• API Specification violation events are part of the Attack Analytics tool.
• Automatic disabling of Captcha cookie challenge and Javascript challenge on API traffic.
• Integration with API management platforms through designated APIs and open source tools, making security an
integral part of API lifecycle management.
Introducing DDoS protection for a single IP over TCP/IP
The new IP Protection service provides complete DDoS protection at the IP level.

IP Protection over TCP/IP is deployed as an always-on service. Traffic flow is symmetric, where both ingress and egress
traffic flow through the Imperva network via an allocated anycast Edge IP.
Benefits include:
• Out-of-the-box Layer 3/4 volumetric DDoS protection

• Backed up by our SLA
• Easy, self-service onboarding
• Minimal configuration
The IP Protection for TCP/IP service supports onboarding using your origin IP address or by allowing Imperva to
dynamically resolve the domain name or CNAME.
After onboarding, you can view statistics for the Protected IP in the Security Dashboard: DDoS Protection for Networks
and IPs and in Analytics: DDoS Protection for Networks and IPs.
You can also onboard and edit IP Protection settings using the Imperva API. For details, see DDoS Protection for
Networks API.
For details on the free trial, onboarding, and configuring IP Protection over TCP/IP, see Onboarding IP Protection over
TCP/IP.
Enhancements
Change required in your Attack Analytics configuration
As of Monday, June 3, 2019, customers using the Imperva on-premises WAF must manually enable Attack Analytics so
that alerts will be sent to the cloud. This is required for the Attack Analytics service.
What changed: A new setting was added to Attack Analytics enabling you to turn on or off the sending of alerts to the
cloud.
If you are an on-premises WAF customer and are already using Attack Analytics or want to get started, you need to
enable the new setting in Attack Analytics.
For instructions, see Open Attack Analytics.

Infrastructure Protection Analytics Updates
What changed: Two new widgets were added to Infrastructure Protection Analytics:
• New Connections Per Second: Incoming connections from clients to the customer origin and outgoing
connections from the origin.
• Concurrent connections: The number of incoming connections over time. Available for Protected IPs only.
Where it’s located: In the Management Console, open Analytics: DDoS Protection for Networks and IPs.
MaxMind GeoIP ASN database for IP to ASN mapping in rule filters
Imperva Cloud Application Security is now using MaxMind GeoIP ASN database for IP to ASN mapping, used in rule
filters. MaxMind replaces an internal mechanism previously used, leading to improved accuracy.
Availability: Implementation is currently being rolled out to the Imperva global network and will be completed within
a few weeks.
Enhanced SSO Settings
What changed: A new option was added to SSO Settings, enabling you to send the Subject element in the SAML
request to identify the authenticated user.
Where it’s located: On the Management Console sidebar, navigate to Management > SSO Settings > Advanced
Configuration and select the Send Subject element in SAML request option.
Simplified redirect rules improvement
The use of host name in the From field of simplified redirect rules is now supported.

For guidelines on creating simplified redirect rules, see Create Simplified Redirect Rules.
Fixes
None.
Known Issues
None.
additional cost.
Now, as the capability is mature and stable, we’ll be disabling it for non-Enterprise customers who were able to take
Heads up: On June 16, 2019, the Dynamic Content Acceleration service will be disabled for non-Enterprise plan
customers who have already enabled the feature. The functionality will be turned off for these accounts and the
Origin PoP option will be read-only.
If you’re using Imperva’s Enterprise subscription, you’ll see no change.
If you’d like to upgrade to an Enterprise plan and keep using Dynamic Content Acceleration, please contact us.

2019-05-26 Release
New Features
None.
Enhancements
New and Improved API
To better align with REST API standards and best practices, Imperva is gradually rolling out a new version of APIs,
available for your use in managing your Cloud Application Security sites.
Note: All existing (v1) APIs continue to be supported.
The new APIs either provide an alternative to existing APIs or provide APIs with new functionality.
What changed:
• Naming and formatting conventions for the HTTP requests are consistent with REST API standards and best
practices. For example:
• The resource to operate on, such as the rule ID, is included in the core HTTP request and not as an
additional parameter.
• Parameters are sent in JSON format in the body of the request, and not as form data.
• In addition to POST, other common HTTP methods are used (GET, POST, PUT, DELETE).
• In addition to reporting error codes in the response body, proper HTTP response status codes are now also
returned.
• Rule APIs - you can now:
• Retrieve rule details for a single rule.
• Overwrite a single rule.
For details on working with the new APIs, see API Version 2/3 Overview.
Fixes
None.
Known Issues
None.
additional cost.
Now, as the capability is mature and stable, we’ll be disabling it for non-Enterprise customers who were able to take

If you’re using Imperva’s Enterprise subscription, you’ll see no change.
What changed:
• As of this release, the Origin PoP option is disabled for non-Enterprise customers (Incapsula Free, Pro, and
Business web plans) who did not previously enable the feature.
• Heads up: On June 16, 2019, the Dynamic Content Acceleration service will be disabled for non-Enterprise
plan customers who have already enabled the feature. The functionality will be turned off for these accounts.
• If you’d like to upgrade to an Enterprise plan and keep using Dynamic Content Acceleration, please contact us.

2019-05-19 Release
New Features
Cache Shield protects origin servers from redundant requests
Our new Cache Shield service protects your origin servers from redundant requests, further enhancing our caching
capabilities beyond the existing PoP level cache.
Cache Shield designates a specific PoP to serve as an origin shield, a CDN capability that adds an intermediate cache
between our PoPs and your origin servers.
Currently, each of our PoPs can access the origin server directly, and as a result, can overwhelm it with requests.
When the new functionality is enabled, all requests to the origin go through an intermediate PoP automatically
selected by the system. If another PoP does not have the requested content in its cache, it must query the Cache
Shield PoP to determine if the resource is already cached there.
Benefits:
• Reduces spikes on the origin during high request periods, such as after cache purge
• Increases likelihood of cache hits as all requests will go through one PoP
• Reduces outgoing traffic from your public cloud origin and decreases your monthly bill
Availability:
Cache Shield requires the appropriate FlexProtect licensing.
You can enable Cache Shield per site in your account:
1. On the Management Console sidebar, select Websites > Cache to open the Cache Settings page.
2. Expand the Advanced section.
3. In the Response section, enable the Cache Shield option.
For more details, see Cache Shield.
You can also enable Cache Shield using the API. For details, see Site Management API.
Enhancements
New rule filter parameters
To provide more granularity and control we introduced new rule filter parameters to distinguish between query string
and post data, available when creating custom rules.

What changed:
The existing Param Exists parameter checks for a specified string pattern in the parameter names in both the query
string and the post data. Two new parameters were added to check in either the query string or body of the request
separately:
• Query String Param Exists

• Body Param Exists
The existing Param Value parameter checks for a specified string pattern with a specific parameter value in both the
request query string and the post body. Two new parameters were added to check in either the request query string or
post body of the request separately.
• Query String Param Value

• Body Param Value
Under Rule Filter, when adding or editing a rule.
Site redirect options moved
To align with recent changes in Management Console settings, the following redirect options were moved from the
General Settings page to the Delivery Settings page.
Fixes
None.
Known Issues
None.


2019-05-05 Release
New Features
Attack Analytics API
You can now access your Attack Analytics data using an API.
• List incident: Retrieve a list of all incidents that occurred within a specified time frame.
• Get incident statistics: Retrieve full details about a specific incident.
For details, see Attack Analytics API.

Enhancements
Differentiate cache key by geolocation
You can now choose to cache resources separately based on geolocation of the request.
What changed: A new action was added to cache rules.
Where it’s located: In the Management Console Cache Settings page, under Cache Rules. When you add or edit a
cache rule, under Rule Action, select Differentiate Cache Key > Geolocation.
For details, see the Cache Rules section in Cache Settings.
Create up to 20,000 simplified redirect rules
A new redirect rule action is now available, enabling you to create up to 20,000 redirect rules with restricted settings
per site in your account. This is in addition to existing functionality that enables you to create up to 500 delivery and
security rules per site.
What changed:
• You can create and manage simplified redirect rules using the standard Site API rule operations: Add Rule, Edit
Rule, Enable/Disable Rule, Delete Rule, List Rules.
• A new action, RULE_ACTION_SIMPLIFIED_REDIRECT, was added to the Add Rule and Edit Rule operations.
This action redirects the client request to a different URL, responding with a 30X response.
• The List Rules API response now returns details of the current number of rules defined for the site, and the
remaining number of rules that can be added.
For details, see Create Simplified Redirect Rules.
Optimize caching for HTTPS traffic
As part of recent changes made to our cache settings, you can now control how HTTPS secured resources are cached
on the Imperva edge.

What changed: Previously, you could not control how HTTPS resources were cached without contacting Imperva
support. Now, you can independently select the desired cache mode for secured resources in the Management
Console or using an API.
Problem: For sites that had the All Resources cache mode selected and did not change the Secured Resources
setting after April 28, 2019, HTTPS resources that were previously cached are no longer cached, and the Do not cache
HTTPS resources option is selected. (Prior to April 28, 2019, the default option was Use default HTTPS caching. Also
cache HTML pages.)
There was no change to cache behavior for sites using No Cache, Static Only, or Static + Dynamic cache modes, or
explicit cache rules.
Solution: If you would like to cache HTTPS resources, navigate to the Cache Settings page and select the desired
setting, or add explicit cache rules.
Where it’s located: On the Management Console sidebar, select Websites > Cache > Advanced > Secure Resources.
Fixes
None.
Known Issues
None.

2019-04-21 Release
New Features
None.
Enhancements
Introducing Attack Analytics SIEM Log Support
Integrate Attack Analytics logs into your SIEM. Retrieve your logs from the Imperva cloud repository or push the logs
to your remote storage location.
1. Log in to your account in the Cloud Security Console.

2. On the sidebar, click Logs > Attack Analytics Logs to activate logging and configure the log integration.
For full details, see Attack Analytics Logs.
Error page responses now available in JSON or XML format
By default, error responses that are returned to clients when a request is blocked are provided in HTML format. A new
option is available to return error responses in JSON or XML format, based on the Accept or Content-type HTTP
request headers.
1. On the Management Console sidebar, select Websites > <your site> > Settings > General.
2. Under Additional Settings, enable the Enable content based error responses option.
For more details, see Error Responses.
New caching options added
Two new caching options are available in the Management Console, on the Cache Settings page:
• Enrich Cache Key: Add custom text to the cache key as a suffix. Use this option to add specific logic to the cache
key calculation.
• Ignore All Parameters: If the same resource is returned regardless of request parameters, you can opt to ignore
all parameters when determining a cache key match.
For more details on cache settings, see Cache Settings.
New APIs added for caching
API operations are now available for all caching options, including all new caching settings and custom cache rules
that were recently added to the Cache Settings page in the Management Console.

Extended rule filter length
A rule filter can now contain up to 2028 characters.
What changed: Rule filters were previously limited to 400 characters.
Where it’s located: On the Management Console sidebar > Rules page.
Change in log file fields
Each entry in the log file provides information about a single request.
Previously, the entry included details of the source client IPs and protocol version that were used in the session to
which the request belongs.
To provide more precise information, each log file entry now lists the client IP and protocol version used by the
specific request.
Description CEF LEEF W3C What changed?
• The
description
name was
changed to
Client IP. (No
impact on log
files.)
• The field now
Main Client IP src src c-ip lists the client
IP used by the
specific
request.
• The field was
moved to a
new location
in the log
entry.
• The field was

Additional Client IPS caIP caIP s-caip removed from
log files.
• The field now

Protocol Version ver protoVer cs-protver lists the
protocol
version used

Description CEF LEEF W3C What changed?

by the specific
request.
• The field was
moved to a
new location
in the log
entry.
Examples:
CEF format before the change.

cs3=true cs3Label=CO Support src=12.12.12.12 caIP=13.13.13.13 ccode=IL tag=www.elvis.com cn1=200 in=54
xff=44.44.44.44 cs1=NOT_SUPPORTED cs1Label=Cap Support cs4=c2e72124-0e8a-4dd8-b13b-3da246af3ab2
cs4Label=VID
cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=CEFcustomer123 ver=TLSv1.2 ECDHE-RSA-AES128-
GCM-SHA256 start=1453290121336 request=site123.abcd.info/ requestmethod=GET qstr=p\=%2fetc%2fpasswd
app=HTTP act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 filetype=30037,1001,
filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name
CEF format after the change.

act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 src=12.12.12.12 ver=TLSv1.2
ECDHE-RSA-AES128-GCM-SHA256 filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk
Resources, cs9Label=Rule name
W3C format - file header before the change.
date time cs-vid cs-clapp cs-browsertype cs-js-support cs-co-support c-ip s-caip cs-clappsig s-capsupport s-suid
pop cs-protver cs-uri cs-postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-
status s-xff cs-bytes cs-start c-port cs-rule cs-severity cs-attacktype cs-attackid s-ruleName

W3C format - file header after the change.
date time cs-vid cs-clapp cs-browsertype cs-js-support cs-co-support cs-clappsig s-capsupport s-suid cs(User-Agent)
cs-sessionid s-siteid cs-countrycode s-tag cs-cicode s-computername cs-lat cs-long s-accountname sr-pop cs-uri cs-
postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-status s-xff cs-bytes cs-
start c-port cs-rule c-ip cs-protver cs-severity cs-attacktype cs-attackid s-ruleName
For more details on logs, see Log File Structure and Example Logs.
Fixes
None.
Known Issues
None.

2019-04-14 Release
New Features
None.
Enhancements
Enhanced caching control
Create custom cache rules using any of the expansive list of built-in filter parameters. This enhancement provides you
with greater control over which specific resources are cached and under what conditions.
For example, you can create a caching rule for the following scenario:
If the client type is recognized by our client classification mechanism as a crawler, such as Google crawler, and the
request is from Google, cache the resource for 1 day.
IF ClientType == Crawler & ASN == 15169 THEN Cache resource and set TTL = '1 days'
What changed: Previously, custom rules could be created based on URL only.
Availability: We are rolling out the changes over the next several weeks, with full rollout to all customers expected by
April 28th.
Where it’s located: From the Management Console sidebar, navigate to Websites > <your site> > Cache.
Change in log file client IP fields Heads up
The following changes will be implemented on April 21, 2019:
The entry currently includes details of the source client IPs and protocol version that were used in the session to
To provide more precise information, each log file entry will list the client IP and protocol version used by the specific
request.
Description CEF LEEF W3C What will change?
• The
description
name will be
Main Client IP src src c-ip
changed to
Client IP. (No
impact on log
files.)


• The field will
list the client
IP used by the
specific
request.
• The field will
be moved to a
new location
in the log
entry.
• The field will

Additional Client IPS caIP caIP s-caip be removed
from log files.
• The field will

list the
protocol
version used
by the specific
Protocol Version ver protoVer cs-protver request.
• The field will
be moved to a
new location
in the log
entry.
Examples:

cs4Label=VID


For more details on logs, see Log File Structure.

Fixes
None.
Known Issues
None.


2019-04-07 Release
New Features
User authentication using single sign-on (SSO)
Single sign-on for login to the Management Console is now available. SSO provides multiple benefits, including an
improved user experience and centralized user authentication management.
SSO is currently supported for SAML 2.0 only.
For details, see Single Sign-On (SSO).

Enhancements
Incapsula has moved
As part of our mission to better protect the pulse of your business, we have simplified our product portfolio and
officially retired the Incapsula.com website.
As a result, we have implemented the following product changes:
• Management Console login: A new login page is available at my.imperva.com/admin/login. However,

my.incapsula.com is still available and there is no impact on APIs and existing deployments.
• Error pages: The default error page presented to clients have a new design aligned with the new Imperva
brand. This change does not impact customers using custom error pages.
• Incapsula Website Seal: The option to display the Incapsula Website Seal of Security on your site has been
removed.
request.
• The
description
name will be
Main Client IP src src c-ip
changed to
Client IP. (No
impact on log
files.)


• The field will
list the client
IP used by the
specific
request.
• The field will
be moved to a
new location
in the log
entry.
• The field will

from log files.
• The field will

list the
protocol
version used
by the specific
• The field will
be moved to a
new location
in the log
entry.
Examples:

cs4Label=VID



Fixes
None.
Known Issues
None.


2019-03-31 Release
New Features
None.
Enhancements
Custom rate rules
Create custom rates to use in security and delivery rules. A rate filter triggers the rule when the rate passes a specified
threshold.
For example, you can now create a security rule for the following scenario:
If a client accesses /login.html from China more than 20 times per minute, block it.
This new functionality boosts our ability to mitigate brute force or scraping attacks, which use a high rate of activity to
gain unauthorized access to resources.
Custom rate rules are an extension of our existing mitigation capabilities in which you can create custom security or
delivery rules to meet a specific need.
What changed: A new Rate action is available in rules. A rate rule counts the number of requests received that match
your specified criteria within a specified amount of time. Rate rules are run after redirect rules.
Once the rate rule is created, you can create a new security or delivery rule, using the rate in the rule filter.
Where it’s located: Management Console sidebar > Websites > Rules.
For more details, see Create Rate Rules.
(Note that there is an addition to the changes reported in the March 24 release notes: Protocol Version.)

request.
• The
description
name will be
changed to
Client IP. (No
impact on log
files.)
• The field will
Main Client IP src src c-ip list the client
IP used by the
specific
request.
• The field will
be moved to a
new location
in the log
entry.
• The field will

from log files.
• The field will

list the
protocol
version used
by the specific
• The field will
be moved to a
new location
in the log
entry.
Examples:



cs4Label=VID


Fixes
None.
Known Issues
None.

Removed Features
Incapsula Website Seal Heads up
On April 7, 2019 the Websites > General Settings > Show Seal option will be removed and the functionality
discontinued. This option enables you to display the Incapsula Website Seal of Security on your site.

2019-03-24 Release
New Features
None.
Enhancements
New caching and delivery capabilities
We are starting to roll out new caching and delivery capabilities and an enhanced user interface.
What changed: New Cache and Delivery setting pages have been added to the Management Console and now
include a more comprehensive set of capabilities. They replace the settings previously located in Website
Performance Settings.
Highlights:
• Purge by tag. Identify resources based on tags in the resource headers, and then purge the specific resources
according to tag name.
• Expanded caching options for caching HTTPS resources, client-side caching, tagging responses according to
origin response header value, cache key, and more.
• New delivery options to further enhance performance.
Availability: We are rolling out the changes over the next several weeks, with full rollout to all customers expected by
April 7.
Note: There are no changes to default options or to your current configuration.
On the Management Console sidebar > Websites > Cache or Delivery.

For more details on the new settings, see:
• Cache Settings
• Delivery Settings
The entry currently includes details of the source client IPs that were used in the session to which the request
belongs.
To provide more precise information, each log file entry will list the client IP used by the specific request.
• The
description
name will be
changed to
Main Client IP src src c-ip Client IP. (No
impact on log
files.)
• The field will
list the client
IP used by the


specific
request.
• The field will
be moved to a
new location
in the log
entry.
• The field will

from log files.
Examples:
CEF format before the change. The highlighted fields will be removed:

cs4Label=VID
CEF format after the change. The highlighted field will be added:

app=HTTP act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 src=12.12.12.12
filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name

W3C format - file header before the change. The highlighted fields will be removed:
W3C format - file header after the change. The highlighted field will be added:
cs-sessionid s-siteid cs-countrycode s-tag cs-cicode s-computername cs-lat cs-long s-accountname sr-pop cs-protver
cs-uri cs-postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-status s-xff cs-
bytes cs-start c-port cs-rule c-ip cs-severity cs-attacktype cs-attackid s-ruleName

Fixes
None.
Known Issues
None.
Removed Features
Incapsula Website Seal Heads up

2019-03-17 Release
New Features
None.
Enhancements
Change of default SAN settings in Imperva generated certificates
The default setting for the SAN types that are added to the Imperva SSL certificate have changed.
What changed: The default setting for Business and Pro Plan accounts has changed from wildcard domain SAN
(*.example.com) to full domain SAN (such as www.example.com).
For Enterprise plan accounts, the wildcard SAN continues to be the default option.
You can override the default settings as follows:
• Account level settings: Account admins can change the default settings that will be used for new sites created
in the account. For details, see Account Settings.
• Site level settings: You can override the default settings when creating a new site or enabling SSL for an
existing site. For details, see Onboarding a Site – Web Protection and CDN.
These options are also available using the API. For details, see Account Management API and Site Management API.
Fixes
None.
Known Issues
None.
Removed Features
Incapsula Website Seal


2019-03-10 Release
New Features
None.
Enhancements
Compare performance with and without Dynamic Content Acceleration
If Dynamic Content Acceleration is enabled for your site, you can use the origin_pop=disabled parameter to
bypass the functionality when sending a request to the site.
For example:
Via the Origin PoP: https://example.com/product/widget.html
Bypassing the Origin PoP: https://example.com/product/widget.html?origin_pop=disabled

Fixes
None.
Known Issues
None.
Removed Features
Incapsula Website Seal

2019-03-03 Release
New Features
None.
Enhancements
Improved algorithm for DNS resolution yields improved performance
Until now, when a client would try to access your site, DNS queries would resolve to the IP of the Imperva PoP closest
to the client (end user). However when the closest PoP is located in another country, better performance is seen using
the PoP in the same country, although it may be located farther away.
What changed: Moving forward, when the closest PoP to a client is located in another country, and there is a PoP in
the same country, the DNS query will give higher priority to the IP of the PoP in the same country as the client.
Fixes
None.
Known Issues
None.

2019-02-17 Release
New Features
None.
Enhancements
Control the SANs in Imperva generated certificates
What changed: You can now choose which SAN types are added to the Imperva SSL certificate. This certificate is
generated when you onboard a new SSL site, or enable SSL for an existing protected site.
• Select wildcard or full domain SAN.
For example: For www.example.com, the wildcard SAN is *.example.com and the full domain SAN is
www.example.com.
Default option: Wildcard is added to the certificate
• Add naked domain SAN. For sites with the www prefix, you can choose to also add the naked domain to the
certificate.
For example: For www.example.com, the SAN example.com is added to the certificate in addition to the
wildcard or full domain SAN.
Default option: Naked domain is added to the certificate
• Account level settings: Account admins will be able to change the default settings that will be used for new
sites created in the account. For details, see Account Settings.
• Site level settings: The default settings can be overridden when creating a new site or enabling SSL for an
existing site. For details, see Onboarding a Site – Web Protection and CDN.
These options are also available using the API. For details, see Account Management API and Site Management API.
Within a few weeks we will update the default settings according to account plan. An update on this change will be
announced in the Release Notes.
• Enterprise plan accounts: The wildcard SAN will continue to be the default option.
• New Business and Pro plan accounts: The full domain SAN will be the default option, instead of the wildcard
domain SAN that is used currently.
Only suspicious requests will be displayed in Events page
What changed: Requests that are not suspicious and do not trigger alerts will no longer be displayed on the website
Events page. The reduced volume of items enables you to more easily focus in on the suspicious events.
This change is being rolled out over the next several weeks.

1. On the Management Console sidebar, click Websites and select a website from the list.
2. Click Events.
3. In the Event Details column, click More to view details about the requests in the event.
Infrastructure Protection Analytics - View additional details for source IPs
What changed: In order to streamline the analysis process, additional details are now available in Infrastructure
Protection Analytics for Source IP addresses, including country of origin and autonomous system number (ASN).
1. To view the Analytics, open the Infrastructure Protection Dashboard and select an IP range, a time range, and
filter for blocked or passed traffic.
2. Click a source IP address to display a popup with additional details.
For more details on Infrastructure Protection Analytics, see Analytics: DDoS Protection for Networks and IPs.
Fixes
None.
Known Issues
None.
docs.incapsula.com/Content/release-notes.rss

2019-02-10 Release
New Features
None.
Enhancements
Infrastructure Protection: Static routing configuration displayed in the Management Console
What changed: If your Infrastructure Protection connection is configured for static routing, you can now see the
configuration setup in the Management Console.
Where it’s located: On the Infrastructure Protection Network Settings page, under Routing Options, the Type column
displays Static Route. Click the connection name to view additional routing details.
Fixes
None.
Known Issues
None.

2019-02-03 Release
New Features
None.
Enhancements
Control the SANs in Imperva generated certificates
Within the next several weeks, we will introduce new options for the Imperva SSL certificate that is generated when
you onboard a new SSL site, or enable SSL for an existing protected site.
The new options will enable you to choose which SAN types are added to the certificate:
• Select wildcard or full domain SAN.
For example: For www.example.com, the wildcard SAN is *.example.com and the full domain SAN is
www.example.com.
• Add naked domain SAN. For sites with the www prefix, you can choose to also add the naked domain to the
certificate.
For example: For www.example.com, the SAN example.com is added to the certificate in addition to the
wildcard or full domain SAN.
Default settings according to account plan
• Enterprise plan accounts: The wildcard SAN will continue to be the default option.
• New Business and Pro plan accounts: The full domain SAN will be the default option, instead of the wildcard
domain SAN that is used currently.
Settings
• Account level settings: Account admins will be able to change the default settings that will be used for new
sites created in the account.
• Site level settings: The default settings can be overridden when creating a new site or enabling SSL for an
existing site.
Attack Analytics
You can now filter the dashboard data according to targeted host.
For more details on the Dashboard, see Attack Analytics Dashboard.

Fixes
EDNS Compliance
To meet new standards for EDNS, major DNS software and service providers agreed to remove accommodations for
non-compliant DNS implementations on or around February 1. To learn more about the DNS changes, see https://
dnsflagday.net/.
In preparation for these DNS Flag Day changes, the ISC provided an EDNS Compliance Tester: https://
ednscomp.isc.org/ednscomp.
Problem: Incapsula DNS is fully EDNS compliant. However, tests run on incapdns.net and some customer domains
using our name server protection were not completing successfully.
Solution: We are rolling out a fix over the next week that enables the tests to pass.
Known Issues
None.

2019-01-27 Release
New Features
Topology view for Infrastructure Protection
View a graphical representation of your Infrastructure Protection connections and BGP peering topology.
Where it’s located: In the Management Console, navigate to Infrastructure > Network Settings and click Topology
view.
You can also click the arrow to access the new Settings view for a view of the connection settings.
TLS 1.3 support
Support for TLS 1.3 is now being rolled out and will be completed over the next several weeks.
Enhancements
TLS update
To enhance TLS security, client-initiated TLS renegotiation is being disabled and will be completed over the next
several weeks.

Text change in Incapsula default error page
The default error page, which is presented to clients when a web page cannot be displayed, will be updated on 28/1.
The text "Powered by Incapsula" is being changed to "Powered by Imperva". The link remains the same. This may be
relevant if you have a script that identifies the error page according to this text, for example.
Infrastructure Protection configuration details now displayed in the Management Console
What changed: You can now view the following details of the connections between Incapsula and your origin
network:
• Origin Connectivity: Maximum transmission unit (MTU) available for GRE connections. Click the connection
name to view the connection settings.
• Routing Options: Your account’s BGP peer configuration.
• ASN configuration: The autonomous systems that Incapsula uses for communication between Incapsula’s
network and your origin network.
Where it’s located: In the Management Console, navigate to Infrastructure > Network Settings.
Change in Imperva CDN benchmarks on the Cedexis website
We have identified an issue in the Cedexis test and have therefore temporarily removed the Imperva Dynamic CDN
platforms (under Dynamic Object Delivery) from view in the Cedexis Country Report.
We will update once the issue is resolved and the platforms are available again.
The following CDN platforms continue to be available:
• Imperva CDN (under CDN Response Time)

• Imperva CDN TLS (under Secure Object Delivery Response Time)
Fixes
None.
Known Issues
None.

2019-01-13 Release
New Features
Troubleshooting Connectivity Report
A new report is available to help resellers troubleshoot connectivity issues for their customers. The report is available
per site and provides information such as ping, dig, trace, and cURL, to assist resellers with initial debugging.
Availability: The report is being rolled out to resellers over the next few weeks. When the feature has been enabled
for an account, a banner displays when logging in to the Management Console.
1. In the Management Console, navigate to the Websites > Dashboard > Performance tab.
2. Scroll down to view the Connectivity Report section.
3. Select a PoP from the list and click Run Report.
Up to 6 previous reports are saved.

Enhancements
Expanded capabilities for user-defined security rules
This release introduces many new parameters to use when creating custom rules.
What changed: In addition to the existing filter parameters for bot protection, protection against ATO, application
hardening, rate limiting, and advanced access control, here are a few highlights of what the new parameters have to
offer:
• Advanced options for handling sophisticated bot scenarios

• Logic based on popular technologies such as Drupal, PHP, Joomla, Wordpress and others, in order to simplify
complex expressions by encapsulating the tech detection and rates within a single command
• Client certificate info, such as CN
Where it’s located: On the Management Console sidebar, click Rules to access. When you add or edit a rule, filter
parameters are listed in the Rule Filter section in the If field.
For details on all the filter parameters, see Rule Filter Parameters.
Improved rules interface
The new Rules page announced last week in the 2019-01-06 Release is now implemented for all customers.
Create site without automated DNS check
What changed: The option to add a site to your account without the automated DNS check for the origin IP is now
available in the Management Console. This enables you to prepare the site but configure its DNS records at a later
time.

• In the Management Console: On the Websites page, click Add Site to access the “add site” wizard. Select
Advanced configuration to configure the options. For more details, see Onboarding a Site – Web Protection and
CDN.
• Via the API (existing functionality): When adding a site using the Site Management API > Add site operation, use
the site_ip parameter to manually set your web server IP/CNAME and skip the automated DNS check. For more
details, see Site Management API.
Change in log file names for log integration “push” mode
The naming convention for the log files that are pushed to your repository has changed, as announced last week in
the 2019-01-06 Release .
Imperva CDN benchmarks now publicly available on the Cedexis website
The following CDN platforms are available through the Cedexis Country Report (no login required).:
1. Imperva CDN (under CDN Response Time)

2. Imperva CDN TLS (under Secure Object Delivery Response Time)
3. Imperva Dynamic CDN (under Dynamic Object Delivery)
1. (DSA AP-Origin)
2. (DSA EU-Origin)
3. (DSA US-Origin)
Infrastructure Protection Dashboard Improvements
• Total traffic view removed from Infrastructure Protection Dashboard: The redundant Total option for viewing
overall traffic for your IP Ranges has been removed from the Traffic filter. The All option continues to display
passed and blocked traffic in the graphs.
• Significant performance improvements have been made to the Infrastructure Protection Dashboard.
Fixes
None.
Known Issues
None.


2019-01-06 Release
New Features
None.
Enhancements
Improved performance with Dynamic Content Acceleration
The new Dynamic Content Acceleration service is designed to improve response time to your origin server by
leveraging Incapsula’s high-quality connectivity between Incapsula network PoPs.
When this service is activated, client requests are sent over the Incapsula network from the receiving PoP to the PoP
with the best connectivity time to your origin server, resulting in improved performance.
What changed: Enterprise plan customers can now opt-in to the Dynamic Content Acceleration Service via the
Management Console.
Where it's located: A new Origin PoP setting is available in the Management Console’s Website Settings > Origin
Servers section, under the Server IPs or Data Center settings.
To activate the service, select the Origin PoP with the lowest round-trip time. A list of recommended PoPs is available
to assist you in selecting the best PoP for a location. For full details, see Dynamic Content Acceleration.
You can also configure the option using the Set Data Center Origin PoP and Get Data Center Recommended Origin
PoP Site Management API operations. For details, see Site Management API.
Improved rules interface
What changed: IncapRules and Delivery Rules are now configured and managed on one page in the Management
Console. The new Rules page is based largely on the Delivery Rules page with some minor modifications:
• IncapRules are now named Security rules and listed under the Security section. Note that priority is not listed
for security rules (IncapRules). This is because all security rules are run, as opposed to other rule types where
the rules are run according to priority order until the first match for that rule type is found.
• Tabs were added enabling you view all rules of each type separately.
Availability: The new UI is currently being rolled out and will be available to all customers over the next few weeks.
Why the change:
• The page was redesigned to improve the user experience. Easily create and manage all rules in one location,
with a consistent UI. The IncapRules were brought into the more mature UI used for Delivery Rules.
• All rules are displayed in one location, providing you with a clearer view of how the rule mechanism works. For
example, redirect rules are evaluated first. If there are no matches, the security rules are then evaluated, then
rewrite rules, and finally, forward rules.
• The new tabs provide a faster way to view the information you’re looking for. For example, if you’re interested in
Forwarding rules, you don’t need to page through all of the other rules to get to them.
Where it’s located: The new Rules tab is now available on the sidebar after selecting a website.

For more details, see Rules.
Attack Analytics
Multiple enhancements were recently introduced to Attack Analytics.
• Mark an incident as a false positive

• View incident and event trends
• Export the dashboard to PDF
• More drill down functionality added to the Dashboard
• Advanced filter options added
• View attack reputation among Imperva customers
For details on each of these enhancements, see Attack Analytics Release Notes.
Updated Graylog content pack for SIEM integration
An updated Graylog SIEM integration package is now available.
Changes include:
• A new, comprehensive Incapsula dashboard template

• Updated log field names (Regex parsing rules were not changed)
• Missing field entries added (PoP name, longitude, delivery rules)
You can download the package via the Management Console Logs Setup page, or directly from github: https://
github.com/imperva/incapsula-siem-package-graylog/
Recommended for new SIEM integration setups only.
For more details on SIEM integration, see Cloud WAF Log Integration.
Monitoring of HTTPS sites over HTTPS using port 443 by default
Previously, monitoring was performed over HTTP (over port 80) for all sites. This resulted in servers for HTTPS sites
being unnecessarily reported as down when communication failed. As a workaround, our Support team manually
configured sites to use HTTPS (over port 443) for monitoring when necessary.
Moving forward, HTTPS over port 443 will be the default protocol and port for monitoring HTTPS sites. The change
will be implemented for existing HTTPS sites over the next several weeks.
Note that a server that is currently reported with a “down” status may return to an “up” status when the change is
implemented. This can result in traffic being directed to such a server by our load balancing mechanism after a period
of inactivity.
Change in log file names for log integration “push” mode
This change affects the push mode of SIEM integration, in which your logs are pushed to your pre-defined SFTP or
Amazon S3 repository,

On January 13, 2019 we will implement a change in our log push process, which required a change in the naming
convention for the log files that are pushed to your repository.
Current format: <configid>_<filenumber>.log
New format: <configid>_<unique_identifier>.log

Fixes
None.
Known Issues
None.


2018-12-09 Release
New Features
None.
Enhancements
Delete stored data
You can now permanently delete the data stored for your account. This enables you to remove all potentially sensitive
or personal data that is stored in our systems, such as IP addresses.
The deletion process is carried out at the account level. If the account has sub accounts, data from the sub accounts is
also deleted.
Note:
• For an Enterprise plan account that was previously set up as a reseller account in order to implement sub
accounts, data can be deleted at the sub account level only. If this type of account has already been migrated to
the new Sub Account feature as described in Manage Account Resources, data is deleted at the account level.
• For reseller accounts, data can be deleted at the sub account level only.
For more details, see Data Storage Management.
Download Infrastructure Protection Analytics in CSV format
You can now download Analytics data from all top traffic pattern tables at the same time.
For more details, see Analytics: DDoS Protection for Networks and IPs.
Fixes
None.
Known Issues
None.


2018-12-02 Release
New Features
None.
Enhancements
Improved Network Traffic Dashboard
The enhanced Network Traffic Dashboard introduces an improved user interface and improved performance,
including a breakdown by passed and blocked Layer 3/4 traffic.
Where it's located: On the Management Console sidebar, click Network Traffic.
For more details, see Network Traffic Dashboard.
Create site without DNS configuration via the API
The option to add a site to your account without configuring DNS is now available via the API. This enables you to
prepare the site but configure DNS at a later time.
Where it’s located: When adding a site using the Site Management API > Add site operation, use the site_ip
parameter to manually set your web server IP/CNAME and skip the automated DNS check.

Fixes
None.
Known Issues
None.

2018-11-18 Release
New Features
None.
Enhancements
New Purge Cache Permission
A new permission was added for purging the cache for a protected website. This new permission introduces greater
granularity, enabling the account administrator to grant this permission only to developers that require purge
functionality without the ability to modify site security and other settings.
The Purge cache permission enables a user to purge the site’s cache, or purge specific resources in the site cache.
What changed:
The Purge cache permission, and not the Modify site settings permission, is now required for the following
functionality:
• Management Console: Website > Settings > Performance > Purge Cache and Purge Specific Resource
• Site Management APIs: Purge Site Cache and Purge Resources
Backward compatibility:
The Purge cache permission has been enabled by default for:
• All account admins.

• Any user who currently has the Modify site settings permission.
Where it's located:
For instructions on changing user permissions, see Account Users.

Fixes
None.

Known Issues
None.

2018-11-04 Release
New Features
None.
Enhancements
New API to retrieve subscription details
Use the new Get Account Subscription API operation to get subscription information for your account, including
details of your plan, usage, and subscribed services.
For details, see Account Management API.
User isolation in a sub account
Note: This functionality was originally introduced on September 2, 2018 and then temporarily disabled to address an
issue that was identified. The feature has now been reopened.
Reduce the workload on your team by safely delegating the onboarding and management of applications to their dev
owners, while limiting user access to the parent account (which includes the Subscription, Users, and other sections
that might require limiting access).
What changed: The Access Parent Account user permission was added to Enterprise plan accounts. This permission
enables users with sub account access to also access the parent account. It is enabled by default.
To limit a user’s access to their assigned sub accounts only, remove this permission. When it is not selected, all other
permissions are disabled.
Where it's located: Log in to the parent account in the Management Console. On the sidebar, click Management >
Users. Click a user row to open the Settings panel.
This permission is visible in the parent account only.

New Attack Analytics dashboard provides an at-a-glance view of the attacks on your system
What changed: A new dashboard for Attack Analytics was added. The dashboard displays the distribution of top
metrics, enabling you to quickly identify problem areas and drill down for a closer look.
See the distribution of incidents by:
• quantity and severity of events and incidents

• country of origin
• violation types
• tool types used in the attacks
• resources that were attacked
Note: A majority of the dashboard functionality is delivered in this release, while additional drill-down functionality is
scheduled to be added in the coming weeks.
Where it's located: On the Attack Analytics banner, click Dashboard.

For more details, see Attack Analytics Dashboard .

Fixes
None.
Known Issues
None.

2018-10-28 Release
New Features
None.
Enhancements
Change in alert notifications for website DDoS attacks
What changed: If your website’s DDoS mitigation mode is set to On or Off, DDoS alerts are no longer logged when an
attack is detected or has ended:
• Alerts are not listed in Websites > Dashboard > Activity Log.
• Email notifications are not sent.
Alerts continue to be logged and sent for DDoS attacks if your site is set to Automatic mode.
Where it’s located: Your website’s DDoS settings are located in the Management Console Websites > Settings > WAF
> DDoS:
Fixes
None.
Known Issues
None.

2018-10-21 Release
New Features
None.
Enhancements
Open source SIEM packages now hosted in GitHub
What changed: SIEM application packages for the Incapsula log integration, previously stored in Incapsula, are now
publicly available and hosted in GitHub. These packages are the responsibility of and can benefit from contributions
by the open source community.
Packages for the following platforms are now hosted in GitHub:
• ArcSight Enterprise Security Manager

• McAfee Enterprise Security Manager
• Graylog Enterprise Log Management
Where it’s located: Links to these SIEM packages in GitHub, as well as links to other SIEM packages for integration
with Incapsula, are located in the Management Console Logs page.
For more details, see Cloud WAF Log Integration.

Fixes
None.
Known Issues
None.

2018-10-14 Release
New Features
None.
Enhancements
Self-service trial for Attack Analytics
What’s changed: Enterprise plan customers can now launch a free, 14-day trial of Attack Analytics directly from the
Management Console. Attack Analytics correlates and distills thousands of security events into a few readable security
narratives.
Where it’s located: On the Management Console sidebar, click Attack Analytics and then Start Trial.
For more details on Attack Analytics, see Imperva Attack Analytics and Attack Analytics Documentation .
Improvement in email notification for the end of a DDoS attack
When a DDoS attack has ended, Infrastructure Protection customers are notified by email. The email now includes
additional useful information:
• Attack duration.
• Maximum (peak) blocked traffic during the attack.
For more details on email notifications, see Notifications.

Fixes
None.
Known Issues
None.

2018-10-07 Release
New Features
None.
Enhancements
Modify the Reference ID field
What changed: The existing Reference ID field is now open for editing by Resellers and Enterprise plan customers.
Reference ID is a free-text field that enables you to add a unique identifier to correlate an object in our service, such as
a protected website, with an object on the customer side.
Where it’s located: This field is available when creating or editing an Incapsula account or website.
• Account-level setting: The Reference ID field is located in Account Settings or Sub Account Settings.
• Site-level setting: The Reference ID field is located in Websites > Settings > General, under Additional
Settings.
API: The ref_id parameter was added to the Modify Account Configuration and Modify Site Configuration operations,
enabling you to set the Reference ID field for an account or site.
Attack Analytics: Decode/encode query string functionality added
What changed: Easily decode/encode a URL in an event’s raw data sample.
Where it’s located: In the Attack Analytics Incident Details, under Events Sample, double-click an event. The encode,
decode, and copy buttons are located next to relevant fields.
Example:
Fixes
None.
Known Issues
None.


2018-09-16 Release
New Features
None.
Enhancements
None.
Fixes
Removing quarantined URLs from the backdoor protection list
A fix was implemented for the Modify Site Security Configuration API parameter that controls quarantined URLs.
You can now use the quarantined_urls parameter to remove a URL from the backdoor protection list.

Known Issues
None.

2018-09-02 Release
New Features
None.
Enhancements
User isolation in a sub account
Update 2018-09-09: An issue was discovered. To avoid any further inconvenience, the feature has been temporarily
disabled. When fixed, it will be reopened.
Reduce the workload on your team by safely delegating the onboarding and management of applications to their dev
owners, while limiting user access to the parent account (which includes the Subscription, Users, and other sections
that might require limiting access).
What changed: The Access Parent Account user permission was added to Enterprise plan accounts. This permission
enables users with sub account access to also access the parent account. It is enabled by default.
To limit a user’s access to their assigned sub accounts only, remove this permission. When it is not selected, all other
permissions are disabled.
Where it's located: Log in to the parent account in the Management Console. On the sidebar, click Management >
Users. Click a user row to open the Settings panel.
This permission is visible in the parent account only.
Client classification documentation
The list of client types and IDs in our client classification database is now published in the online help. This can be
useful when defining IncapRules or Delivery Rules. For details, see Client Classification.
Fixes
None.
Known Issues
None.


2018-08-19 Release
New Features
None.
Enhancements
None.
Fixes
Client application fields fixed in W3C format
As part of a recent fix to synchronize log file formats, the values of the Client App field (cs-clapp) and the Browser Type
field (cs-browsertype) in W3C format were temporarily switched between the fields. Based on customer feedback, the
fields have been reverted to their original states. This fix is being gradually rolled out to customers starting today.
The fields are now as follows:
Field Description
The name of the client application, such as Firefox
cs-clapp
or Chrome.
The type of client application, such as browser,
cs-browsertype
search bot, or hacking tool.
Known Issues
None.

2018-07-30 Release
New Features
None.
Enhancements
Infrastructure Protection Analytics
See top traffic patterns for traffic flowing through the Incapsula Infrastructure Protection service.
The Infrastructure Protection service previously provided visibility at the IP range level.
The new Infrastructure Protection Analytics provides significantly enhanced visibility. Destination details identify
specific targeted servers and services, while source details shed light on the attack and attacker.
• View statistics on traffic by source or destination IP, by source or destination port, or by packet size for your
protected network.
• View blocked (DDoS) traffic or clean traffic.
• View historical attack data from the previous 90 days to analyze behavior over time and better understand
traffic patterns affecting your network.
• Easily identify false positives and review specific characteristics of an attack to pinpoint actionable details.
Note: As the Analytics service has just recently started aggregating data, only a limited amount of Analytics data will
be initially visible.
Access Infrastructure Protection Analytics via the Infrastructure Dashboard. For details, see Analytics: DDoS Protection
for Networks and IPs.

Fixes
None.
Known Issues
None.

2018-07-22 Release
New Features
None.
Enhancements
New Data Storage Region APIs
The following API operations were added:
• Set site regions by origin geolocation: Sets the data storage region for each new site based on the geolocation
of the origin server.
• Check site regions by origin geolocation: Checks if the data storage region for each new site is based on the
geolocation of the origin server.
For full details on the new operations, see Site Management API.
To learn more, see Data Storage Management.
Attack Analytics: Direct link added from violations to your site settings in the Incapsula Management Console
To enable you to easily adjust your security settings, a direct link was added from violations in the Attack Analytics
Console to your website settings in the Incapsula Management Console.
In the Attack Analytics Console, on the incident details page, under Which violations were discovered? click the info
icon next to a violation.
Note: The link is available only on incidents that occurred after the new functionality was added.
Click a link in the Site list to open the Incapsula Management Console.

For more details on Attack Analytics, see the Attack Analytics Documentation.
Fixes
None.
Known Issues
None.

2018-07-15 Release
New Features
None.
Enhancements
Change in Data Storage Region Configuration
To simplify configuration of the data storage location, the new Default data storage region setting was introduced for
selecting the data storage region for all services, including WAF (website) events, logs, DDoS attack data, and IP
addresses.
If you want the system to automatically select the WAF event storage location for each website independently, you
can opt-in by selecting the Override site event data region by origin geolocation option.
Fixes
None.
Known Issues
None.


2018-07-01 Release
New Features
None.
Enhancements
None.
Fixes
Account Resources (Sub Accounts)
Sub account creation is now fully restored.
Problem: An issue was detected for some customers using sub accounts. When moving a site from a parent account to
a sub account, or between sub accounts, security events that occurred before the move were saved but were no
longer displayed in the Management Console’s Events page. To mitigate this issue, new accounts created on or after
May 13, 2018 could not create sub accounts.
Solution: The site move issue was fixed in the 2018-06-24 release. In this release, sub account creation is re-enabled
for new accounts created on or after May 13, 2018.
Known Issues
None.

2018-06-24 Release
New Features
None.
Enhancements
API Update - Add/Edit Data Center
Add Data Center operation:
• The is_standby parameter is deprecated. The functionality was incorrectly labeled. A corrected is_standby
parameter will be added at a later date.
• The is_enabled parameter was added.
Edit Data Center operation:
• The is_enabled parameter was added.
For more details on these operations, see Site Management API.

Fixes
Problem: An issue was detected for some customers using sub accounts. When moving a site from a parent account to
a sub account, or between sub accounts, security events that occurred before the move were saved but were no
longer displayed in the Management Console’s Events page.
Solution: This issue is fixed. For existing customers/accounts that have implemented sub accounts, you can now
move sites between accounts or sub accounts. Note that customers who already moved their sites cannot see events
that occurred before the move.
Known Issues
An issue was detected for some customers using sub accounts. When moving a site from a parent account to a sub
account, or between sub accounts, security events that occurred before the move were saved but were no longer
displayed in the Management Console’s Events page.
This issue has been fixed - see Fixes above.
To prevent any further inconvenience, new accounts created on or after May 13, 2018 cannot currently create sub
accounts. This functionality will be restored in the coming weeks.


2018-06-17 Release
New Features
None.
Enhancements
API Key Management
Create and manage API keys with granular permissions and sub account access.
API Key Management enables you to integrate Incapsula into your environment and streamline processes while
enforcing permission based access control and sub-account access, resulting in the reduced risk of human error. For
example, an API key can have permissions to make changes to a specific sub account without being able to access
other sub accounts that are outside of the user’s area of responsibility.
Overview
• API keys inherit the user's permissions and sub account access.
• The account admin or any user with the appropriate permissions (Manage users and permissions and Manage
API keys) can create and manage keys for all account users.
• Any user with the Manage API keys permission can create and manage their own API keys (up to five keys per
user account).
• Add a name and description to an API key to indicate what it is used for.
• Export the API key list. This action exports details such as user, name, description, and status in csv format. It
does not export the key itself.
For more details, see API Key Management.
Attack Analytics
For incidents that have a predominant source IP, you can now view the list of all incidents that include this IP as a
source.
In the Attack Analytics Console, select an incident and view the details in the right pane. Click the Find all incidents
icon next to the IP address to view all associated incidents.

For more details on Attack Analytics, see https://docs.imperva.com/management/attack_analytics.

Fixes
None.
Known Issues

The following changes have been implemented on a temporary basis to prevent any further inconvenience until the
problem is resolved:
• For new accounts created on or after May 13, 2018: You cannot create sub accounts.
• For existing customers/accounts: You cannot move sites between accounts or sub accounts.
A fix is in progress. Updates will follow.

2018-06-10 Release
New Features
None.
Enhancements
Regional Data Storage for Infrastructure Protection Data
By default, data collected by Incapsula Infrastructure Protection is stored in the US. You can now select an alternative
data storage region for Infrastructure Protection data.
Stored data includes network layer 3/4 headers, which contain IP addresses.
For details, see Data Storage Management.

Fixes
None.
Known Issues

2018-06-03 Release
New Features
None.
Enhancements
New Network Settings page for Infrastructure Protection customers
The details of connections between Incapsula’s network and a customer's origin network were previously displayed in
the Management Console under Infrastructure > Protection Settings. The origin connection details are now
displayed on the Infrastructure > Network Settings page.
Fixes
None.
Known Issues

2018-05-29 Release
Introducing Attack Analytics: Speed up the security investigation of WAF
alerts
Attack Analytics uses artificial intelligence to automatically consolidate thousands of security alerts to help you
prioritize which critical events to address.
Attack Analytics provides a comprehensive view of attacks and attackers targeting your resources.
The service aggregates and analyzes your account’s security alerts, identifies common characteristics, and groups
them into meaningful security incidents.
The sophisticated analysis can help you achieve the following objectives:
• Enhance security mechanisms.

• Enable fast response to emerging threats.
• Easily understand the security value provided by Incapsula by seeing the volume and severity of attacks that are
intercepted.
Attack Analytics is now available. For more details, see:
https://www.imperva.com/products/application-security/attack-analytics/
https://docs.imperva.com/management/attack_analytics


2018-05-27 Release
New Features
None.
Enhancements
Change in TLS version support
As of May 27 2018, Incapsula will set TLS 1.2 as the minimum supported version, by default, for connectivity between
clients (visitors) and the Incapsula service. Enforcement will be gradually rolled out to customers during the week.
PCI-DSS v3.2 compliance requires disabling the use of TLS 1.0 as of July 1, 2018. To comply with this requirement, and
due to the known vulnerabilities in TLS 1.1, Incapsula has defined TLS 1.2 as the default minimum supported version.
This also applies to the Incapsula Management Console and the Incapsula API.
For our Enterprise and Business plan customers who require continued support of TLS 1.0 or TLS 1.1 while they
prepare their customers, applications, or tools to support TLS 1.2 only, an option to maintain current functionality has
been added to the UI and API.
For more information, see:
• Incapsula documentation: Web Protection - SSL/TLS

• Incapsula blog: How We Use TLS 1.2 To Improve Your Website Visitors’ Security .
Fixes
None.
Known Issues


2018-05-21 Release
New Features
None.
Enhancements
Change in response time calculation
To improve the accuracy of response time, a change was made to the calculation. Response time for requests sent
from Incapsula to your sites is calculated as follows:
• Previous definition of response time: From the time the Incapsula proxy finishes sending request headers to the
origin, until the origin starts sending the response to the proxy.
• Current definition of response time: From the time the Incapsula proxy has decided to send a request to the
origin (before opening a connection to the origin), until the origin finishes sending the response to the proxy.
Due to this change, the Average response time graph may display increased values.
The Average response time graph is displayed in the Incapsula Management Console for each protected site under
Websites > Dashboard > Performance. Each data point in the graph represents the average of the last 10 minutes.
(This has not changed.)
New log fields
The following fields were added to Incapsula logs and are being gradually rolled out to customers starting today:
• Source Port: The client port used to communicate the request.

• Protocol Version: The TLS version and encryption algorithms used in the request.
• PoP Name: The Incapsula PoP that handled the request.
For more details on log fields, see Log File Structure.

Fixes
Changes in log file format
For consistency between the different file formats, the following changes were made in the format of log fields that
are provided in each log entry:
Format Previous behavior New behavior
For fields that can have multiple

The field values are not
values, the values were
encapsulated in square brackets.
encapsulated in square brackets.
CEF, LEEF
Example: caIP=192.34.32.3
Example: caIP=[192.34.32.3]
ccode=IL
ccode=[IL]
For fields that can have multiple

Fields with multiple comma-
values, the values were comma
separated values have a space
separated, with no space between
W3C between values.
values.
Example: "192.34.32.3, 1.2.3.4"
Example: "192.34.32.3,1.2.3.4"
The Latitude field was listed

Both Latitude and Longitude are
W3C twice, instead of Latitude and
listed.
Longitude.
The order is reversed. The Client

The Client App field had the
App field has the format “<type>”
format “<name>” “<type>”.
“<name>”.
W3C
Example: "FireFox"
Example: “clientAppType.Browser"
"clientAppType. Browser "
"FireFox"
If an attack related field is empty,

it is not listed. Exception: the cs9
Attack related fields were listed field is relevant to the
even when empty. filePermission field. If the
filePermission field is populated,
CEF, LEEF
Example: fileType=5 cs9 field is listed even if it is empty.
filePermission= cs9=
cs9Label=Rule name Example:
• When the filePermission

field is irrelevant neither the

Format Previous behavior New behavior

filePermission field or the
cs9 field are listed.
• When the filePermission

field is relevant but the cs9
field is empty:
fileType=3 filePermission=4
cs9= cs9Label=Rule name
• When both the

filePermission field and the
cs9 field are relevant:
fileType=3 filePermission=4
cs9=Test description
cs9Label=Rule name
Known Issues

2018-05-13 Release
New Features
None.
Enhancements
New CAPTCHA approved for China
When Incapsula security rules require it, visitors to an Incapsula protected website are presented with a CAPTCHA
challenge. However, Google’s reCAPTCHA technology used by Incapsula is blocked in China.
In this release, we introduce an additional CAPTCHA mechanism, which is licensed and approved for China. This new
CAPTCHA will be presented to visitors from China, when required.
The new functionality will be rolled out to customer sites during the coming weeks.
Note: For customers using a custom challenge page, there is no change in functionality.
Fixes
None.
Known Issues

2018-04-29 Release
New Features
None.
Enhancements
Updated Log Values
To further clarify definitions of blocked events in Incapsula logs, we have replaced the generic Normal value with
more descriptive names that reflect the reason for the block or the outcome of the event.
Values of the Rule Name field have been changed in the following instances:
1. For requests that were suspended in order to present a bot challenge to the client:
Request Result field: REQ_CHALLENGE_<COOKIE/JAVASCRIPT/CAPTCHA>
Rule Name field:
▪ Previous value: Normal

▪ New value: Suspicious Bot
2. For requests that were not necessarily suspicious or malicious but were part of a blocked session or visitor:
Request Result field: REQ_BLOCKED_SESSION or REQ_BLOCKED_VISITOR
Rule Name field:
▪ Previous value: Normal

▪ New value: Blocked
For more details on log fields, see Log File Structure.

Fixes
None.
Known Issues
None.


2018-03-25 Release
New Features
Regional Data Storage APIs
New operations were added to view and manage data storage regions for accounts and sites.
The account level operations enable you to view and set the default region for new sites created in the account:
• Get default data storage region

• Set default data storage region
The site level operations enable you to view and set the data storage region for a site:
• Get site data storage region

• Set site data storage region
For details on data privacy, see Data Storage Management.

Enhancements
Disable sending of account activation email
When creating a new account, resellers can now choose to delay sending the activation email. This enables you to
customize and configure a new account before sending the email to your end-user customer.
A Send Automatic Activation Email option was added to the Add New Account dialog box, and is selected by
default. To send the mail at a later time, clear this option.
When you are ready to send the activation mail, use the Resend now link under Misc in Account Settings.
Fixes
None.
Known Issues
None.


2018-03-18 Release
New Features
Regional Data Storage
Regional data storage is now available, providing regional data isolation and control at the site level. Data can be
isolated per region, per site, in accordance with data privacy requirements. The available regions are APAC, EU, and
US.
Data that is collected for a site is assigned to its designated regional PoPs (data centers). By default, Incapsula assigns
a region to a site based on geolocation of the origin server registered for the site.
You can view the region to which a site is currently assigned, and the account administrator can override the default
region. In the Management Console, navigate to Websites > <your site> > Settings > General > Data Storage.

Enhancements
None.
Fixes
None.
Known Issues
None.

2018-03-11 Release
New Features
None.
Enhancements
Change in TLS version support
As of April 29, 2018, Incapsula will set TLS 1.2 as the minimum supported version, by default, for connectivity between
clients (visitors) and the Incapsula service.
PCI-DSS compliance requires disabling the use of TLS 1.0 as of July 1, 2018. To comply with this requirement, and due
to the known vulnerabilities in TLS 1.1, Incapsula has defined TLS 1.2 as the default minimum supported version. This
also applies to the Incapsula Management Console and the Incapsula API.
For our Enterprise and Business plan customers who require continued support of TLS 1.0 or TLS 1.1 while they
prepare their customers, applications, or tools to support TLS 1.2 only, an option to maintain current functionality has
been added to the UI and API.
For more information, see Web Protection - SSL/TLS.

Fixes
None.
Known Issues
None.

2018-03-04 Release
New Features
None.
Enhancements
Change in reseller email notification options for customers exceeding bandwidth
Notifications of excess bandwidth usage for an account can now be sent to customers, to resellers, or to both.
Previously, resellers could receive notifications only if the customer option was enabled.
The setting is available to resellers in the Management Console under Management > Account Settings > Email
Settings:
Fixes
None.
Known Issues
None.

2018-02-18 Release
New Features
None.
Enhancements
Email threat alert notifications
The content of threat alert notifications sent via the Incapsula Management Console has been modified.
As announced in the 2017-08-06 Release Notes, a single mail is sent for all alerts occurring within a 5-minute interval.
This release introduces richer sample data in the mail and a more efficient design.
The mail contains:
• Up to three session samples, including details on the session ID, client, user agent, entry page, and number of
requests.
• For each session, up to three request samples including details on threat type, action, URL, query string, and
attack pattern, depending on the threat type.
Fixes
None.
Known Issues
None.

2018-02-11 Release
New Features
Manage Account Resources (RBAC)
Group your resources to simplify the management of enterprise accounts and manage user access.
The new sub accounts feature enables you to group and manage sites together based on department, function, or
other business criteria, and assign users to only those resources they are responsible for managing or require access
to.
For details, see Manage Account Resources.
This feature is available for Enterprise plan accounts only. There is no change to Reseller accounts.
New Sub Accounts API
To support sub accounts, the following new operations were added to the Incapsula API:
Account Management API:
• Add new sub account

• List account's sub accounts
• Delete sub account
Site Management API:
To enable you to move a site to a sub account or between sub accounts, the new Move site API operation was added.

Enhancements
None.
Fixes
None.
Known Issues
None.


2018-02-04 Release
New Features
None.
Enhancements
CAA Compliance
As of September 2017, the CA/Browser Forum Baseline Requirements require all Certificate Authorities (CAs) to check
for Certificate Authority Authorization (CAA) records before issuing or renewing certificates. A CAA record enables
domain owners to specify on their DNS which CAs are authorized to issue certificates for their domain.
To ensure the successful issuing of certificates, Incapsula now checks for and requires CAA compliance when
onboarding a new SSL site or enabling SSL support for an existing site. This applies to Incapsula generated certificates
(including multi-domain SAN certificates) only.
If your DNS zone file currently contains CAA records, but does not contain a record for the CA you are requesting
a certificate from, that CA cannot issue or renew a certificate for your domain.
For details on compliance requirements, see CAA Compliance.
CAA API
• The Check CAA compliance operation was added to enable you to check your site's associated SANs for CAA
compliance.
• A new value for the validation_status parameter was added to the Get Site Status operation:
pending_caa_records_change.
Upload a custom certificate without a private key
To remove the security overhead of managing and sending private keys over the web, you can now upload a custom
certificate for your site to Incapsula, without providing a private key.
A new API enables you to generate a CSR to submit to the CA, while Incapsula manages the private key.
For more details, see Upload a Certificate without a Private Key.
SIEM integration with Sumo Logic
A link to the SIEM integration package for Sumo Logic is now available from the Logs Setup page in the Management
Console. For details on configuring the Incapsula App for Sumo Logic, see Installing a SIEM Package.
Fixes
None.

Known Issues
None.

2018-01-28 Release
New Features
None.
Enhancements
Reduced number of monitoring requests to origin
Previously, load balancing monitoring was conducted by each proxy. To reduce the monitoring load on your origin
servers, Incapsula now conducts monitoring per PoP, significantly reducing the number of monitoring requests sent to
your system.
Dedicated IP renamed
The Dedicated IP service was renamed to Dedicated Network. This change is reflected in the Management Console
Subscription page.
Fixes
None.
Known Issues
None.

2018-01-21 Release
New Features
None.
Enhancements
Digitally signed emails
All email sent by the Incapsula management system is now digitally signed. You can take advantage of this
enhancement and boost your email authentication process by verifying DKIM signatures.
Fixes
None.
Known Issues
None.

2018-01-14 Release
New Features
None.
Enhancements
Infrastructure Protection Statistics and Events APIs
Two new Infrastructure Protection APIs enable you to get information for an account, IP, or IP range on:
• statistics such as traffic type, showing a breakdown of traffic by packet type, or the global distribution of all
incoming traffic across Incapsula PoPs
• events such as origin connection or IP protection status
For more details, see the Get Infrastructure Protection Statistics and Get Infrastructure Protection Events
operations in the Traffic Statistics and Details API.
SIEM integration with Sumo Logic
A SIEM integration package for Sumo Logic is now available. For details on configuring the Incapsula App for Sumo
Logic, see Installing a SIEM Package.
Digitally signed emails
On January 21, 2018 we will implement DKIM digital signing on all email sent by the Incapsula management system.
You can take advantage of this enhancement and boost your email authentication process by verifying DKIM
signatures.
Fixes
None.
Known Issues
None.

2018-01-07 Release
New Features
None.
Enhancements
Infrastructure Protection Test Alert APIs
The new Infrastructure Protection Test Alert APIs enable you to send dummy notifications for DDOS attack status,
Infrastructure Protection connection status, IP Protection status, and Infrastructure Monitoring status. For details, see
Infrastructure Protection Test Alerts API.
Documentation Updates: IncapRules Use Case Examples
Examples of IncapRules for some common use cases were added to the documentation, including screenshots and
code snippets illustrating how to implement each of the scenarios. For examples of how to manage scrapers and
comment spammers, block account takeover attempts, implement rate limiting and more, see Security Rule Use Case
Examples.
Fixes
None.
Known Issues
None.


2017-12-03 Release
New Features
None.
Enhancements
API updates
The following changes were implemented:
• List Rules: Pagination parameters were added to the List Rules operation (/api/prov/v1/sites/incapRules/list),
enabling you to configure pagination options for the response. This change impacts the response output of the
API call. The default response contains 50 items per page.
Previously, all items were returned. After the change, only the first 50 are returned. To return the complete list,
you need to iterate using the page_size and page_num parameters.
• List Account Rules: The List Account Rules operation (/api/prov/v1/sites/incapRules/account/list) was
deprecated. The functionality is still available using the List Rules operation.
• Add/Edit Rule: New debugging information was added for IncapRules API Add Rule and Edit Rule operations.
The debug_info field, which is included in the API responses, now contains a list of validation errors for the filter
parameter. The validation_errors field indicates when there is an error in the syntax of the filter, and can provide
you with information as to why a call has failed.
Changes to the Dynamic Resource Caching Algorithm
The heuristics algorithm that handles dynamic resource caching was changed to prevent the risk of inadvertently
returning HTML resources that may contain personal information, such as PII, ePHI, and PAN data.
To support this change, the Apply acceleration setting also to HTTPS option, located in the Management Console
under Websites > Settings > Performance > Advanced Settings, was removed. Customers who use the Static +
Dynamic caching mode and had previously enabled the Apply acceleration setting also to HTTPS option may see a
change in caching heuristics for certain resources. Specifically, some dynamic resources, such as HTML in https, which
may previously have been cached, will no longer be cached. For more details on the default behavior for caching
HTTPS traffic or to configure explicit caching rules, see Cache Settings.
The corresponding API parameter was also removed from the Advanced Cache Settings API operation: Site
Management API > Advanced Caching Settings > accelerate_https. There is no API breakage but using the
parameter will have no effect.
Updated Account Users Page
The Account Users page has been redesigned and relocated. To view and manage the list of users who have access to
your account, log in to the Management Console and navigate to Management > Users. For more details, see Account
Users.
Fixes
None.

Known Issues
None.

2017-11-05 Release
New Features
None.
Enhancements
New Infrastructure Protection Dashboard
A revamped Infrastructure Protection Dashboard with major improvements is now available in the Management
Console.
Feature highlights
• Improved user experience

• New menu bar. Select options for the type of metrics and traffic you want to see in the graphs from one
consolidated control.
• Side-by-side view. View Bits Per Second and Packets Per Second graphs side by side.
• IP Range selection
• View a breakdown by IP range in the graphs, enabling you to compare between ranges.
• Filter the data displayed in the graphs according to IP range.
• Real-time graph improvements
• Zoom in to get a closer look at a section of the graph.
• Use the new graph navigator to quickly drag the view to different sections of the graph.
• Description column added to the Ranges table
• Faster load times
For full details or to view the quick start slideshow, see Security Dashboard: DDoS Protection for Networks and IPs.
Available for Infrastructure Protection or IP Protection customers only.
API updates
The following changes are planned for the 2017-12-03 release:
• Pagination parameters will be added to the List Rules operation (/api/prov/v1/sites/incapRules/list), enabling
you to configure pagination options for the response. This change will impact the response output of the API
call. The default response will contain 50 items per page.
Currently, all items are returned. After the change, only the first 50 will be returned. To return the complete list,
you will need to iterate using the page_size and page_num parameters.
• The List Account Rules operation (/api/prov/v1/sites/incapRules/account/list) will be deprecated.

Fixes
None.
Known Issues
None.


2017-10-29 Release
New Features
None.
Enhancements
New DDoS mitigation Service Level Agreement
A new SLA is applicable to customers who joined or renewed the Incapsula service on or after October 5, 2017.
Incapsula previously offered a 5-minute DDoS mitigation SLA. This is now updated to 10 seconds. See the SLA for
more details.
To download the full SLA, log in to your account in the Management Console, and navigate to the Subscription page:
Management > Subscription.
Fixes
None.
Known Issues
None.

2017-10-22 Release
New Features
None.
Enhancements
Changes to the Dynamic Resource Caching Algorithm
Within the next few weeks, we are planning to remove the Apply acceleration setting also to HTTPS option, located
in the Management Console under Advanced Settings on the Performance Settings page.
Customers who use the Static + Dynamic caching mode and activated the Apply acceleration setting also to HTTPS
option may see a change in caching heuristics for certain resources. Specifically, some dynamic resources, such as
HTML in https, which may previously have been cached will no longer be cached.
To control explicit cache behavior, configure caching rules on the Performance Settings page. For details, see Cache
Settings.
Fixes
Change in CEF log file format
The values of the Attack Severity field in the CEF log file format were changed to align with the W3C format.
The values represent the different attack types. Incapsula uses the field as it is part of the default CEF and W3C format,
but the values do not represent higher or lower severity.
Name Old value New value

ACL 3 -1
SQL Injection 9 0
Cross Site Scripting 8 1
Illegal Resource Access 9 3
Bot Access Control 5 4
DDoS 6 8
Backdoor Protect 10 9
Remote File Inclusion 8 10
IncapRules 4 11
Correction in output of Get Site Status API
In two weeks, on November 5th, the response output of the Get Site Status API will be updated as follows:
From "compress_jepg" to "compress_jpeg".

Known Issues
None.


2017-10-01 Release
New Features
None.
Enhancements
New Infrastructure Protection Dashboard – Early Availability
We are starting to roll out a revamped Infrastructure Protection Dashboard.
Try it out!
On the Management Console’s Infrastructure page, click the Sneak Peek link.
Feature highlights
• Improved user experience

• New menu bar. Select options for the type of metrics and traffic you want to see in the graphs from one
consolidated control.
• Side-by-side view. View “Bits Per Second” and “Packets Per Second” graphs side by side.
• IP Range selection
• View a breakdown by IP range in the graphs, enabling you to compare between ranges.
• Filter the data displayed in the graphs according to IP range.
• Real-time graph improvements
• Zoom in to get a closer look at a section of the graph.
• Use the new graph navigator to quickly drag the view to different sections of the graph.
• Description column added to Ranges table
• Faster load times
Click Dashboard to return to the previous version of the dashboard.

Available for Infrastructure Protection or IP Protection customers only.

Fixes
None.
Known Issues
None.

2017-09-24 Release
New Features
None.
Enhancements
New variable added for Delivery Rules
The $asn variable was added to the available variables for use in Delivery Rules. It represents the Autonomous System
Number, and can be used to send the client's ASN to the origin in a header. For more details, see Create Rules.
Redesigned user interface - update
All customer accounts that were still using the classic Incapsula Management Console interface have now been
switched over to the redesigned interface.
Need help navigating the new interface?
The Incapsula Documentation is fully updated to reflect the redesigned Management Console.
Fixes
None.
Known Issues
None.

2017-09-03 Release
New Features
None.
Enhancements
Redesigned user interface - update
On September 17, 2017, all customer accounts that are still using the classic Incapsula Management Console interface
will be switched over to the redesigned interface.
Client certificate support
Client certificates are now supported for SNI sites only. We do not support client certificates for non-SNI sites.
Fixes
None.
Known Issues
None.


2017-08-20 Release
New Features
None.
Enhancements
New general API response code
Two changes were made in our general API error response:
1. When an API call times out, the server now returns a JSON response instead of an HTML response.
2. The JSON response has error code 4.
For example:
{
"res": 4,
"res_message": "Operation timed-out or server unavailable",
"debug_info": {}
}

Fixes
None.
Known Issues
None.

2017-08-13 Release
New Features
None.
Enhancements
New general API response code
In the next few weeks we are planning to make two changes in our general API error response:
1. When an API call times out, the server will return a JSON response instead of an HTML response.
2. The JSON response will have error code 4.
For example:
{
"res": 4,
"res_message": "Operation timed-out or server unavailable",
"debug_info": {}
}
New variable for Delivery Rules added
$epoch was added to the variables available for use in Delivery Rules. $epoch represents the Unix timestamp - an
integer value representing the number of microseconds that have elapsed since the beginning of the Unix epoch
(January 1, 1970).
Fixes
None.
Known Issues
None.

2017-08-06 Release
New Features
Client certificate support
Client certificate support is now available. For details, see Client Certificate Support.
Enhancements
The method and content of threat alert notifications sent via the Incapsula Management Console have been modified.
Previously, a mail was sent for each threat alert. After the change, a single mail is sent for all alerts occurring within a
5-minute interval. The mail will include a sample of up to three of the generated alerts, and details of the total number
of alerts and visits. Detailed information on the threats can be found in the Management Console's Events page for
each site.
In addition, the site's activity log will reflect this change (Website > Dashboard > Activity Log). The number of Visits
and Threats for the specified time interval are now displayed, instead of information on individual threats. You can
then drill-down to the more detailed information displayed in the Events page.
Redesigned User Interface - Update
The feedback button used to submit feedback and defects on the redesigned Management Console was removed.
Fixes
Delivery Rules "Allow caching" option was removed
The Delivery Rules Allow caching option has been removed (Websites > Delivery Rules > Add Rule/Edit Rule). The
Allow caching option was originally implemented to handle an uncommon rewrite and caching use case. Because we
have modified the process and now perform cache key calculation after the rewrite action, this option is no longer
required.
Known Issues
None.

2017-07-30 Release
New Features
None.
Enhancements
Update to bandwidth consumption displayed in the Sub Accounts table
For managed accounts/resellers: The bandwidth usage displayed in the Sub Accounts table (Management Console
sidebar > Sub Accounts) was split and now displays Always-on BW and On-demand BW consumption of the last 30
days separately.
The information is the same as presented for each account in Management > Subscription.
For details on account bandwidth calculation, see Account Bandwidth Calculation.
New variable for Delivery Rules added
The $src_port variable was added to the available variables for use in Delivery Rules. $src_port represents the
client's outgoing port number. It can be used, for example, to distinguish users behind NAT.
Fixes
None.
Known Issues
None.

2017-07-23 Release
New Features
None.
Enhancements
Connecting to an SNI site that does not have a valid certificate
To align with internet standards, a change will be implemented within the next few weeks for users browsing to an
Incapsula-protected site that is using SNI but does not have a valid certificate.
Instead of indicating in the browser that there is no valid certificate while enabling the session to continue, the
connection will be blocked, and an error will be displayed. For example:
Fixes
None.
Known Issues
None.

2017-07-16 Release
New Features
Debug headers – XRAY
Gain visibility into Incapsula CDN and caching behavior. XRAY provides a look into Incapsula edge behavior using
predefined response headers, such as the Incapsula POP that handles the request, the cache hit or miss reason, and
the cache key.
The feature is activated by copying an access token from the Management Console to a browser. Once activated, the
XRAY debug headers are available for 10 minutes or until you close the current browser session.
The XRAY access token is available in the Management Console under Websites > <your site> Settings >
Performance.
For full details, see XRAY Debug Headers.

Enhancements
Change in default notification settings for new sites
When a new site is added to Incapsula, notifications will now be sent by default for DDoS and Backdoor Protect
security events only. Notifications will not be sent for other event types. This change does not affect existing sites.
To change notification settings, in the Management Console, navigate to Websites > <your site> > Settings
> Notifications > Real-time Notifications:
Update to the Pro service plan
On July 23, 2017 we are updating the Pro service plan.

Going forwards, all new and existing Pro sites which utilize an Incapsula SSL certificate will be served by Server Name
Indication (SNI) SSL mode.
You can read more about SNI certificates here: https://en.wikipedia.org/wiki/Server_Name_Indication
If you need to support non-SNI compliant browsers for HTTPS content, we recommend upgrading to a Business or
Enterprise plan.
Fixes
None.
Known Issues
None.

2017-07-09 Release
New Features
Direct Protection
We are gradually rolling out changes in the Management Console to support Direct Protection.
Incapsula Direct Protection is a premium Infrastructure Protection feature that allows organizations to connect
directly to Incapsula over a private, high-quality medium. The Direct Protection offering adds 2 new connectivity
options between protected networks and our scrubbing centers:
• Direct Protection - Cross-Connect: A dedicated physical connection to the Incapsula scrubbing center.
• Direct Protection - ECX (Equinix Cloud Exchange): A dedicated virtual connection over a shared fabric using
Equinix Cloud Exchange.
The changes in the Infrastructure > Protection Settings page include:
• The Data Centers table is removed.

• The GRE Tunnels table is replaced by the Origin Connectivity table to support all connection types. For
existing tunnels, the data center name is displayed in the Description column.
Enhancements
Within the next several weeks, we will be modifying the method and content of threat alert notifications sent via the
Incapsula Management Console.
Currently, a mail is sent for each threat alert. After the change, a single mail will be sent for all alerts occurring within a
5-minute interval. The mail will include a sample of up to three of the generated alerts, and details of the total number
of alerts and visits. Detailed information on the threats can be found in the Management Console's Events page for
each site.
API documentation
The Incapsula API documentation is now available on the documentation site: Cloud Application Security API
Reference. The documentation is publicly available and does not require a login.
Fixes
None.
Known Issues
None.

2017-06-25 Release
New Features
None.
Enhancements
Change in activation process for new accounts
For managed accounts/resellers: When adding a new account in the Management Console, the account activation URL
is no longer displayed on screen. Instead, an activation link, valid for one month, will be sent to the account’s email.
The recipient then clicks the activation link in the email and follows the online instructions as usual. The Send
Automatic Activation Email option was removed from the Add New Account dialog box.
Cache is not automatically purged after cache settings are changed
Changes made to cache settings no longer trigger a purge of the cache. To manually purge the cache from the
Incapsula Management Console, navigate to the Website Settings Performance page.
Bandwidth usage displayed in the Sub Accounts table
For managed accounts/resellers: The bandwidth usage displayed in the Sub Accounts table (Management Console
sidebar > Sub Accounts) will now show the always-on total bandwidth consumption of the last 30 days. The
Bandwidth column shows the rate of data transferred, in bits per second, between visitors and Incapsula, according
to the 95th percentile, and includes clean traffic only. Previously, both clean and blocked bandwidth were displayed.
Note: The correct data will be displayed starting Monday June 26, 2017.
Redesigned User Interface – Updates
Check DNS functionality was added, enabling you to verify your DNS configuration.
In the Management Console > Websites page, click the status icon of a site that is not configured or only partially
configured. The Instructions link provides more details on making changes to your DNS configuration. After making
the required changes, you can click Check DNS to verify that the changes were successfully applied.
Fixes
None.
Known Issues
None.


2017-06-18 Release
New Features
None.
Enhancements
Redesigned User Interface - Updates
• An enhancement was made to provide support for mobile devices.

• The second-level navigation menu can now be collapsed to provide a wider screen display area.
Fixes
None.

Known Issues
None.

2017-06-11 Release
New Features
None.
Enhancements
IncapRules: Rule Name and Revision Comments Cannot Contain Special Characters
Due to an enhanced security policy for IncapRules, the Rule Name and revision comments can no longer contain
special characters. Only alphanumeric, space, period (“.”), and underscore (“_”) characters are allowed. The change
affects existing rules only when they are modified.
Account Bandwidth Information in Account Subscription
On the Subscription page in your account, we have added the option to view the account bandwidth consumption for
the current and two previous billing cycles. (Management > Subscription > Download Bandwidth History).
Creation Date is Displayed on the Websites Page
On the Websites page, Creation Date information is again available, replacing Cached Bandwidth. (Cached bandwidth
data is still available in the website's Dashboard page.)
Fixes
None.
Known Issues
None.

2017-06-04 Release
New Features
Push SIEM logs via Amazon S3 or SFTP
Incapsula Log Integration enables you to receive your Incapsula access and event logs from the Incapsula cloud
repository and to archive or push these events into your SIEM solution.
New functionality was added to support automatic log integration via SFTP or AWS S3 buckets.
When logs are created, they are pushed to your pre-defined repository - an AWS S3 bucket or an SFTP folder.
For details, see Cloud WAF Log Integration.
Redesigned User Interface
The Incapsula Management Console was redesigned to improve the user experience through easier navigation. The
new interface is now implemented for all customers.
Key enhancements include:
• Navigation controls in the left pane

• All pages are now displayed in the same browser tab
• Uniform view and in-app navigation experience for all users (account admins and resellers)
• Enhanced and improved Sites and Accounts pages
• Sites > Websites
• Accounts > Sub Accounts (resellers only)
• Responsive design ensures that the management console automatically adjusts with your screen resolution and
layout

Send us your feedback.
You will see a small feedback label on the right side of the new interface. Click to submit your feedback or to report
any issues you encounter.
Enhancements
None.
Fixes
None.
Known Issues
None.

2017-05-14 Release
New Features
Redesigned User Interface.
The Incapsula management console was redesigned to improve the user experience through easier navigation. We
plan to enable the new interface gradually, reaching all of our customers over the next few weeks.
Key enhancements include:
• Navigation controls in the left pane

• All pages are now displayed in the same browser tab
• Uniform view and in-app navigation experience for all users (account admins and resellers)
• Enhanced and improved Sites and Accounts pages.
• Sites > Websites
• Accounts > Sub Accounts (resellers only)
• Responsive design ensures that the management console automatically adjusts with your screen resolution and
layout
Try it out!
To switch to the new interface:
1. In the Incapsula Management Console, click Account at the top of the page.
2. On the Details page, under Personal Details, select the Use new UI (beta) option.

3. Click Save.
4. Log out of your account. When you log in again, the new interface will be displayed.
To return to the old interface:
1. In the Incapsula Management Console, click the user icon and select My Profile.
2. Under Personal Details, clear the Use new UI (beta) option.

3. Click Save.
4. Log out of your account. When you log in again, the old interface will be displayed.
Send us your feedback.
You will see a small feedback label on the right side of the new interface. Click to submit your feedback or to report
any issues you encounter.
Enhancements
Change of Default Operator for Rate Filter in Delivery Rules or IncapRules

The default operator for rate filters was changed from “==” to “ >= “.
Fixes
None.
Known Issues
None.

2017-05-07 Release
New Features
None.
Enhancements
reCAPTCHA v2
We are currently making the transition to reCAPTCHA V2, “No CAPTCHA reCAPTCHA”, used in our challenge and Login
Protect pages when other user authentication methods fail. V2 introduces improved usability - just click the checkbox.
When accessing the Incapsula site during the transition, you may encounter either reCAPTCHA V1 or V2. The transition
to reCAPTCHA V2 is expected to be completed within the next few weeks.
SIEM Integration with IBM QRadar
The IBM Security Qradar DSM for Incapsula has been released. The RPMs are available for download through Auto
Updates or through IBM Fix Central:
IBM Security QRadar DSM for Imperva Incapsula

Fixes
None.
Known Issues
None.

2017-04-02 Release
New Features
None.
Enhancements
Visualization Change in Infrastructure Protection and Network Traffic Graphs
The Infrastructure Protection and Network traffic graphs have been enhanced.
Before the change:
After the change:
API responses for "Get Site Status" and "Get statistics"

The "action_text" field was update from "Block" to "Block Request".
To get up-to-date texts of keys and IDs that are returned in API responses, please use the "Get Texts API" call
(documented in the Integration section).
Fixes
None
Known Issues
None.

2017-03-26 Release
New Features
None.
Enhancements
New IP Address Ranges
The Incapsula service has added new IP address ranges to its network. In case your firewall has restricted access and
is configured to receive traffic only from Incapsula IP ranges, please add the following IP ranges to your firewall
settings.
• 45.60.0.0/16
• 45.223.0.0/16
This change will be effective as of May 1, 2017.

Fixes
None
Known Issues
None.

2017-03-12 Release
New Features
None.
Enhancements
Incapsula Service Level Agreement (SLA)
The Incapsula SLA is now available for download (PDF file) for Enterprise level accounts. The SLA can be accessed
from the account plan view page (Account => Plan).
Fixes
Delivery Rules - Can’t add Header Value Filter
While creating or editing Application Delivery rules, it is not possible to add a Header value filter (Rule Filter => If =
Header value).
This issue is fixed in the current release.

Known Issues
None.

2017-03-05 Release
New Features
None.
Enhancements
IncapRules and Delivery Rules Header Value Filter is Non Case-sensitive
Filter header values used within Incap rules or Delivery rules are now non case-sensitive.
Customers that are affected by this change were notified separately.

Fixes
None.
Known Issues
Delivery Rules - Can’t add header value filter
While creating or editing Application Delivery rules it is not possible to add a Header value filter (Rule Filter => If =
Header value).
We are working to provide a fix in the coming releases.

2017-02-26 Release
New Features
None.
Enhancements
Weblogs - Changes in LEEF Format
The following changes related to the LEEF format for web logs were implemented:
1. The “Server IP” field name was changed from “src” to “dst”
2. The “Server Port” field name was changed from “srcPort” to “dstPort”
Customers already using this format received a separate communication two weeks ago.
Fixes
None.
Known Issues
None.

2017-02-19 Release
New Features
API Support for IncapRules
Enterprise customers can now use a new set of APIs to manage their Rules.
The following new APIs can be found under the Site Management API section: https://my.incapsula.com/api/docs/v1/
sites
• List Rule Revisions

• Add Rule
• Edit Rule
• Enable or Disable a Rule
• Delete Rule
• List Rules
• List Account Rules
• Revert Rule
Enhancements
None.
Fixes
None.
Known Issues
None.

2017-02-12 Release
New Features
None.
Enhancements
Dashboard Time Frame Changes
The "Today" time frame selection option was changed to “Last 24 hours” to more accurately describe the displayed
time period.
OCSP Stapling Support
Incapsula proxies now serve SSL certificates with OCSP stapling, which eliminates the need for clients to contact the
CA in order to check the revocation status of the certificate.
This can improve performance for SSL sites using the Incapsula Web Protection service.
Fixes
None.
Known Issues
SIEM Logs - W3C Format
In cases where there is no value defined in the "cs-rule" field, the returned structure does not include this field, rather
than returning an empty string as expected.
This issue is planned to be fixed in the 19/2/2017 release.

2017-01-29 Release
New Features
None.
Enhancements
Time frame for data presented in Site Dashboard and Events page
Under Site=> Dashboard: Traffic , Security, Performance and under Site => Events the data presented for the
predefined time frames - "Today", "last 7 days", "last 30 days", "last 90 days" - are now aligned between the different
views.
In all cases the time frame begins at the current time and collects data for the relevant period.
For example, if a request is made at 9:30 AM, the "Today" time frame will present data for the last 24 hours (e.g., from
9:30 AM on the previous today until the current time) and "last 7 days" time frame will present data from the last 168
(7x24) hours.
IP ranges classification visible in IP Ranges table
Under Account => Infrastructure Protection => Infra. Protect Settings the classification of the IP Range type is
presented in the IP Ranges table under “Bandwidth Type” with possible values of “On demand” or “Always on”.
Fixes
None.
Known Issues
None.

2017-01-22 Release
New Features
New APIs
Enterprise plan customers can now use a new set of APIs to manage origin servers, data centers and delivery rules.
The new APIs can be found under the Site Management API section - https://my.incapsula.com/api/docs/v1/sites
The new APIs are:
APIs for Server:
• Add server
• Edit server
• Delete server
APIs for Data Center:
• Add data center
• Edit data center
• Delete data center
• List data centers
APIs for Delivery Rules:
• Add custom rule
• Edit custom rule
• Enable or disable a rule
• Delete custom rule
• List custom rules
• List account custom rules
• Revert custom rule
• Set rule priority

Enhancements
W3C File Format Changes for SIEM and Weblogs
The following is an example of an Incapsula log file in W3C format.
The header remains the same, i.e., nothing has been removed or added. The fields marked in red are the ones
influenced by this change.
W3C Header:
#Fields: date time cs-vid cs-clapp cs-browsertype cs-js-support cs-co-support c-ip s-caip cs-clappsig s-capsupport s-
suid cs(User-Agent) cs-sessionid s-siteid cs-countrycode s-tag cs-cicode s-computername cs-lat cs-long s-
accountname cs-uri cs-postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-
status s-xff cs-bytes cs-severity cs-attacktype cs-attackid s-ruleName
1. ACL use case
Previous format:
When a request triggers an ACL rule, the current value of the cs-severity field was the ACL rule name.
Example: "2017-01-08" "09:03:11" "76900a6e-85e2-4873-b702-03b45ace3edd" "Chrome" "Browser" "true"

"true" "31.154.10.196"
" "c3b8b024ea0269c7004e14c94ef1c0c348d85560b89fe0d8cffc3a56bb4abad0724ec379205eac390bbf6420367bd6e158775edccf
"NA" "50121341" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/55.0.2883.95 Safari/537.36" "3412660920000000124" "1004291" "IL" "" "Tel Aviv"
"WebLogs5.incaptest.co" "32.0667" "32.0667" "WebLogs" "weblogs5.incaptest.co/" "" "HTTP"
"REQ_BLOCKED_ACL" "704598177480" "" "" "" "GET" "" "" "" "" "1483866191150" "" "Blocked IP" "" "" ""
New format:
When a request triggers an ACL rule, the value of the cs-severity field is set to -1
The ACL name will be the value of s-ruleName field.
Example: "2017-01-08" "08:57:48" "76900a6e-85e2-4873-b702-03b45ace3edd" "Chrome" "Browser" "true"

"true" "31.154.10.196" ""
"c3b8b024ea0269c7004e14c94ef1c0c348d85560b89fe0d8cffc3a56bb4abad0724ec379205eac390bbf6420367bd6e158775edccf1
"REQ_BLOCKED_ACL" "99007788736" "" "" "" "GET" "" "" "" "" "1483865868807" "" "-1" "" "" "Blocked IP"
2. Redundant double quotes
Previous format:
When a normal request is logged, the cs-severity field contains an empty string represented by four double
quotes.

Example:"2017-01-08" "09:17:49" "76900a6e-85e2-4873-b702-03b45ace3edd" "Chrome" "Browser" "false"

"true" "31.154.10.196" ""
"REQ_CACHED_FRESH" "1859944380104" "" "" "" "GET" "" "200" "" "535" "1483867069405" "" """" "" "" ""
New format:
When a normal request is logged, the cs-severity field will contain an empty string, represented by two double
quotes.
Example:"2017-01-08" "09:50:33" "76900a6e-85e2-4873-b702-03b45ace3edd" "Chrome" "Browser" "true"

"true" "31.154.10.196" ""
"REQ_CACHED_FRESH" "3565046396649" "" "" "" "GET" "" "304" "" "535" "1483869033361" "" "" "" ""
3DES Ciphers Deprecation
Following the discovery of CVE-2016-2183 (Sweet32), it has been advised that DES/3DES ciphers are no longer secure
and it is recommended not to use them.
To ensure our customers' security, we have decided to remove support for these ciphers from our solution as of
February 5, 2017. No action is required from the customer side and
the change is transparent to most modern clients. If following the change customers receive reports that clients
cannot establish an SSL connection to your site, it will be possible to re-enable the ciphers by contacting the
Incapsula support team.
Fixes
None.
Known Issues
None.

2017-01-15 Release
New Features
Encryption of Mail Sent by Incapsula
Mail sent to users by the Incapsula management system will be encrypted by default (encryption in transit TLS).
In cases where the customer's server does not support this encryption method, system mail will continue to be sent
as before (i.e., not encrypted).
This feature will gradually be rolled out during the week.

Enhancements
None.
Fixes
None.
Known Issues
None.

2017-01-08 Release
New Features
Detailed Plan View
Users can now see their plan details with add-on usage and bandwidth consumption by going to: Account -> Plan
Detailed explanation on the calculation of the account's bandwidth can be found in here.
Enhancements
None.

Fixes
“Pass to Origin” Value in “Traffic” Dashboard
The “Pass to Origin” value in the site traffic dashboard located at: Site -> Dashboard => Traffic presents the amount
of traffic passed from Incapsula to the origin server. Until now, for historical reasons, this value was calculated based
on the amounts of cached traffic, blocked traffic and other relevant factors. For purposes of simplicity, we are
replacing this calculation with a measurement of the actual traffic passed to the origin server.
Please note that in extreme cases this change may result in minor differences to past values that were displayed prior
to this change.
Known Issues
None.

2017-01-01 Release
New Features
Weblogs Now Include Delivery Rules data
For each request with delivery rules information, the following details will be provided:
Detailed
Description
JSON describing all
actions that were
Delivery Rule Details cs10 cs10 cs-rule
applied to a specific
request
The full JSON structure description can be found here

Enhancements
None.
Fixes
None.
Known Issues
None.


2016-11-20 Release
New Features
Application Delivery Rules
Application Delivery Rules enable customers to improve site performance and control by manipulating requests
arriving to their origin servers through Incapsula.
Application Delivery Rules are available for Enterprise customers as part of the Load Balancer add-on. Rules are
defined per site under Site=>Settings=>Delivery Rules.
Useful Links:
• Create Rules
• Delivery Rule Use Case Examples
• Blog: Incapsula vs. NGINX Load Balancer: Top 10 Differences https://www.imperva.com/blog/incapsula-
application-delivery-rules/
Enhancements
Infra Protect Monitoring - Notification for NetFlow/Sflow Start
Notification will be sent to the account admin in case a valid NetFlow/Sflow traffic is being monitored by Infra protect
monitoring service.
This is enabled by default for monitored accounts in addition to the existing stop / incorrect traffic notifications.
Notifications would be sent based on the current account configuration by: system message, email, SMS, or phone.
Fixes
None.
Known Issues
None.

2016-11-06 Release
New Features
Native Support for AMP
Google Accelerated Mobile Pages (AMP) have been gaining substantial traction especially among publishing and news
sites. The promise of AMP includes better page load times and higher SEO ranking. In addition, Google labels AMP
pages with a special promotional icon on Google’s mobile search:
One of AMP’s requirements is the lack of 3rd party JavaScript, therefore Incapsula client classification JavaScript
injection is breaking AMP pages which pushes customers to turn-off Inapsula’s JavaScript injection completely.
Incapsula now supports AMP pages natively, which means no injections will be made into AMP pages, for all sites on
all plans by default.
In order for a specific html page to be identified as an AMP page it should starts with “<html amp” or “<html ▪”. Pages
starting with “<html blabla ▪” will not be identified as AMP pages.

Enhancements
Infrastructure Protection Dashboard Enhancements

Enhanced Infrastructure Protection (Infra Protect, Infra Monitoring and IP Protection) dashboard located under
Account => Settings => Infrastructure Protection.
Starting today the new dashboard is the default one.
The previous dashboard will remain available for the next few weeks. (link is available in the page below)

Fixes
None.
Known Issues
None.

2016-10-09 Release
New Features
None.
Enhancements
Infrastructure Protection Dashboard Enhancements
Enhanced Infrastructure Protection (Infra Protect, Infra Monitoring and IP Protection) dashboard located under
Account => Settings => Infrastructure Protection.
The new dashboard can be accessed by clicking on the link in the blue ribbon at the top of the dashboard screen.
The new dashboard offers the following enhancements:
• 15 second resolutions instead of 10 minutes

• Max value instead of average
• Separate view per range (by clicking on each of the ranges in the table)
The previous dashboard will remain available for the next few weeks.
Fixes
None.
Known Issues
None.

2016-10-02 Release
New Features
None.
Enhancements
Incapsula->Origin default connection protocol is now TLS v1.2
Incapsula connections to origin servers now use the higher and more secure version of TLS v1.2 by default.
In case your origin server doesn’t support TLS v1.2, there will be an automatic fallback to TLS v1.1 and TLS v1.0,
respectively.
This change takes effect immediately, and gradually all new connections will use the higher protocol version.
Connections to origin servers that don’t support protocol fallback will not be affected and will continue to use TLS
v1.0.
If for any reason you'd prefer that your origin server will not use TLS v1.2 by default when connecting to Incapsula –
please contact Incapsula support.
Fixes
None.
Known Issues
None.

2016-09-04 Release
New Features
None.
Enhancements
Origin Server Maintenance Mode
In order to support origin server maintenance windows, a new Disabled/Enabled option was added in Site => Settings
=> Origin Servers => Server IPs.
The available combinations are:
• Active Server + Enable: Traffic passes to origin

• Active Server + Disable: New sessions will not pass to origin and will be directed to another server in the data
center (maintenance mode)
• Standby Server + Enable: Traffic will pass to this server only when an active server in the data center is not
available
• Standby Server + Disable: Traffic will not pass to this server even if another server in the data center is not
available (maintenance mode)
Once a server is disabled, no new connections will be opened to this server. Existing connections will be maintained
until the server becomes unresponsive or a connection idle timeout occurs.
Fixes
None.

Known Issues
None.

2016-08-21 Release
New Features
None.
Enhancements
Trial for Add-ons
Enables Incapsula admin or reseller to add a trial feature on a specific service for an enterprise customer
Supported services:
• IP Protection (1 IP)
• SIEM Logs (Unlimited)
• Site (10 sites)
• Load Balancer (2 DC)
• Monitoring for BGP (A single router)
• Login protect users (5 users)
• Zones (1 Zone)
Additional services will be supported in the future.
Activated from Account => Settings => Plan => Start Trial: (Sites for example)

Once Start Trial for a specific service is selected, the user is prompted with a duration message:
If there are unused items from that service, the user will be prompted with the following error message:

Once the trial is set, its end date is indicated on the screen:

The trial duration is set for 2 weeks by default and can be extended if needed by pressing on the date.
An email notification will be sent to the customer with the details of the trial, similar to the email sent in trial account
creation.
Once the customer purchases the SKU, its plan will be updated.
In the event that the trial expires without the customer purchasing the SKUs, the resources allocated for the trial will
be automatically removed.
Fixes
None.
Known Issues
None.

2016-07-03 Release
New Features
None.
Enhancements
Reseller Accounts – New Permissions Settings
Ability to allow \ disallow view permissions for infrastructure protection settings and dashboard for newly created sub
accounts and their users. (Account –> Settings -> New Account Settings)
This applies to accounts which purchased IP Protection \ Infrastructure Protection \ Infrastructure Monitoring services
or trail accounts.
Only users \ accounts with view permissions will able to grant view permissions to their sub-accounts.
In case view permissions are not allowed, the infrastructure protection link will not be visible.
Fixes
None.
Known Issues
None.

2016-06-26 Release
New Features
None.
Enhancements
SIEM Integration - Changes to CEF Format
Changed CEF format to align to the CEF RFC standard:
Server port: sport -> spt
Log publication in this new format started June 19th 2016.
Customers who use the CEF format and the Splunk package, do not required to replace their Splunk package.
Customer who use other logs processing scripts, need to adjust their scripts accordingly.
RSS Support for Release Notes
The documentation site makes it easier to get updates about weekly releases by providing RSS feed subscriptions.
To subscribe to updates about weekly releases add the following feed link to your RSS Feed reader:
https://docs.incapsula.com/Content/release-notes.rss
Updates will be sent via RSS on every new release when the page for this model is updated.
Fixes
None.
Known Issues
None.

2016-06-05 Release
New Features
None.
Enhancements
Modification in Reseller Accounts Plan Editing Permissions
Ability to remove web-plans (not enterprise) sub-accounts at any time, as long as monthly (not yearly) payment
method is used in that specific account.
Removed the ability to “Lock Account” for enterprise sub-accounts plans.
Removed the ability to downgrade enterprise sub-account to web-plans accounts.
The above applies both to actions perform using the UI or via API.
Fixes
None.
Known Issues
None.

2016-05-22 Release
New Features
None.
Enhancements
Logs - New Format - “LEEF”
Added the ability to receive the Web-Logs in LEEF format. (Account => Settings => Logs => Logs Setup=>
Configurations => Log File Format)
Logs - New Siem Package – QRadar
Added a new SIEM package - QRadar. This package requires the use the “LEEF” format. (Account => Settings => Logs
=> Logs Setup => Configurations => SIEM Packages)
Logs - Enhanced UI
Enhanced UI is now available for Logs. Functionality remains the same. (Account => Settings => Logs => Logs Setup)
Infrastructure Protection - Enhanced UI
Enhanced UI is now available for IP Protection \ Infrastructure Protection services.
Removed the view of the settings page, while all other functionality remains the same.
(Account => Settings => Infrastructure Protection=>Infrastructure Protection Configuration)

Fixes
None.
Known Issues
None.

2016-05-08 Release
New Features
None.
Enhancements
Enabled Resellers to Access their Sub-Account's Infrastructure Protection Dashboards
Enabled the option for resellers to enter to their sub accounts Infrastructure Protection, IP Protection, and
Infrastructure Monitoring dashboards and settings ( Account =>Sub Account=> Settings => Infrastructure
Protection => New Infrastructure Protection Configuration).
Fixes
None.
Known Issues
None.

2016-05-01 Release
New Features
Enhanced Request Headers
When enabling the Enhanced Request Headers feature, Incapsula will add new headers to every request reaching your
website.
You can use this data to classify user sessions based on the new properties.
You can enable one or more request headers for each of your sites (Account => Site => Settings => General
=>Incapsula Headers)
1. TLS Version
2. Request ID
To read more about this, go to: https://docs.incapsula.com/Content/management-console-and-settings/web-

protection-general-settings.htm
Enhancements
Web Logs - Deactivate
Added the ability to completely disable and delete all logs for all sites of an account (and for all accounts of a reseller)
under the Logs Setup page (Account => Settings => Logs => Logs Setup)
Web Logs - API Key/ID
The API Key/ID which is used for the logs will not be presented under the list of API Keys for the account (Account =>
Settings => API). Viewing or replacing this API can only be done from the Logs Setup page.
Fixes
None.
Known Issues
None.

2016-04-24 Release
New Features
None.
Enhancements
API improvements for supporting custom certificates management:
1. Get Site Status and Upload Custom Certificate APIs now also provide custom certificate information and
errors
2. Get Site Status API now provides DNS instructions in case a custom certificate is present or a certificate
generation process has been started
3. Remove Custom Certificate API has been added
Fixes
None.
Known Issues
None.

2016-04-17 Release
New Features
Web Logs - General Availability
The SIEM integration capability was enhanced to support the collection of all web logs.
The initial setup and configuration is done in the page used for Security Logs (Account => Security Logs => Logs
Configuration).
For resellers, a new configuration page (Account => Settings => Security Logs => Log Configuration) is available
that allows resellers to configure the accounts for which the logs will be collected (the collection is done for all logs
including Security logs). For each account, it is mandatory to set the sites for which logs will be collected and to
choose whether to collect all logs or Security logs only.
The configuration process is also supported via API
https://my.incapsula.com/api/docs/v1/sites#addSite
https://my.incapsula.com/api/docs/v1/sites#modifySiteLogLevel
https://my.incapsula.com/api/docs/v1/accounts#addAccount
https://my.incapsula.com/api/docs/v1/accounts#modifyAccountLogLevel
The SIEM packages now include also “Graylog” support (in addition to Splunk, ArcSight and MacAfee)

protection-log-integration.htm
Enhancements
SIEM Integration - High Level Scripting to Replace Connector
One of the Incapsula SIEM solution components is the SIEM Connector, which is provided as a standalone installation
package for different operating systems. Incapsula has decided to decouple the SIEM connector from environment-
specific restrictions and adopt a more flexible and supportable approach.
Incapsula introduces a new “logs-downloader" script that can be found at GitHub. The script is written in Python and
is licensed under an open source license.
Incapsula recommends migrating old SIEM Connector implementations to one of the following alternatives:
1. Download and implement Incapsula’s new open source “logs-downloader” script

2. Implement your own connector based on Incapsula APIs
The old SIEM connector will be supported through the end of the subscription term and no later than February 10,
2017, provided that the customer continues to use the same environment and technical setup. If a change to the
environment or to a specific technical setup requires migration to one of the new alternatives during the current
subscription term, Incapsula's support team will assist with migration to the new script.

In addition, please note that the SIEM configuration page (Account => Settings => Security Logs => Logs
Configuration) now reflects the above changes with some additional user experience improvements.

protection-log-integration.htm
Login Protect - Enable to Exclude Resources
The Login Protect setup (Site => Settings => Login Protect), now includes the option to exclude resources defined in
the “Protected Pages” section from being protected by "two-factor authentication". The configuration for these pages
is done in the “Excluded Pages” section.
Example:
Protected Pages rule is : “URL is: http://example.com/images “
Excluded Pages rule is : “URL is: http://example.com/images/ping.png“
In this case, all resources under images will require "two-factor authentication" except from ping.png.
Fixes
None.
Known Issues
None.

2016-04-03 Release
New Features
None
Enhancements
SIEM Integration - New “Splunk” Package and Changes in CEF Format
A new Splunk package is available under the SIEM configuration page (Account => Settings => Security Logs => Logs
Configuration). The package supports the following changes in CEF format in order to align with the CEF RFC
standard:
1. deviceExternalID —> deviceExternalId

2. requestmethod —> requestMethod
3. fileid —> fileId
4. filetype —> fileType
5. filepermission —> filePermission
The publishing of logs in this format will start next week on April 10th.
Customers that use the CEF format and Splunk package are kindly requested to replace their existing Splunk package
with the new version. The new package supports both the new and old CEF format.
Customers that use other log processing scripts need to adjust their scripts accordingly.
New User Permissions
When a new user is added to an account, their default permission settings are disabled (Account => Settings => Users
=> Add User).
Fixes
None.
Known Issues
None.

2016-03-06 Release
New Features
None
Enhancements
Reseller accounts - removal of sub accounts
The ability to remove sub accounts in a reseller account was removed.

Fixes
None.
Known Issues
None.

2016-02-21 Release
New Features
HSTS - Strict transport security
Strict transport security (HSTS) ensures that any attempt by visitors to use the unsecure version (http://) of a page will
be forwarded automatically to the secure version (https://).
This feature is relevant only for SSL supported sites.
The implementation is done by adding a header, for example:
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
There are three levels of restrictions for HSTS. Implementing all three restriction levels might not be appropriate for
all sites.
1. Max-Age (TTL) - Time to apply HSTS in browser.

2. Include sub-domains - Enforce HSTS on sub-domains. Page listed on xxx.ddd.com uses resources from
images.ddd.com; with HSTS for sub-domains the images are also covered. Site admin needs to make sure the
site and all sub-domains support HTTPS. Otherwise, HSTS will break an internal resource when rendering the
page.
3. Pre-load - The most secure way to enforce HSTS. Ensures the first request goes out in a secure tunnel, since the
browser already has that URL in the preload list. The domain needs to be listed at https://
hstspreload.appspot.com/.
Each level relies on the enforcement of the previous one.
Configuration is done via Site Settings -> General -> Strict Transport Security section.
Resellers (managed accounts) can determine whether or not created sites will have the HSTS option enabled by
default.
Configuration is done via Settings => New Account Settings => “Enable HSTS for newly created SSL sites” field.
Enhancements
None.
Fixes
None.
Known Issues
None.

2016-02-14 Release
New Features
API Key/ID
For accounts which support API calls (Enterprise plans and managed accounts), the account administrator (or user
who has equivalent permissions) can now manage the account API Key and ID.
This includes:
• Create new IP Key/ID

• Reset IP Key or revoke it
The API settings are available for:
• Managed accounts under Account => API

• Enterprise accounts under Account => Details => API settings section.
Enhancements
Add Site - SSL support
Enhancements have been made to the "Add Site" flow in the SSL support step.
In cases where the site failed the SSL support test, additional information is presented, which indicates the reason for
failure and provides instructions on how to solve the problem.
The following cases are supported:
1. Site has a certificate that was not issued to its domain

2. Site cannot be reached
3. No certificate installed on server or server has incompatible SSL configuration
In addition, the user has the option to select a different port and rerun the test.
Fixes
None.
Known Issues
None.

2016-01-03 Release
New Features
None.
Enhancements
Login Page
The user interface of the Incapsula Login page has been modified. Its functionality remains the same.
https://my.incapsula.com/admin/login
Get Events API
From December 31, 2015 and onwards, the Get Events API is no longer supported (deprecated).
We recommend using the Security Logs API calls from now on, which provide the same functionality as the Get
Events API and more.
The Security Logs API calls can be accessed at https://my.incapsula.com/api/docs/v1/data.

Bug Fixes
None.
Known Issues
None.


2015-12-06 Release
New Features
Upload Custom Certificate API: This new operation uploads a custom certificate for your site. The following SSL
certificate file formats are supported: PFX, PEM and CER.
For a full description of SSL certificates in Incapsula, go to: Web Protection - SSL
To read more about this API, go to: https://my.incapsula.com/api/docs/v1/sites#uploadCustomCertificate

Enhancements
None.
Bug Fixes
None.
Known Issues
None.

2015-11-22 Release
New Features
• Origin Lock: This feature associates a certain IP to a specific account and prevents other accounts on the
Incapsula service from setting up sites that forward traffic to that origin.
Enhancements
Additional fields were added to the Get Visits API command, as follows:
• httpVersion: Specifies the HTTP version number. The value can be 1.0, 1.1 or 2.0.
• httpStatus: Is the HTTP response status code that was received from the origin server. This field is optional.
• securityRuleAction: Indicates the action taken to mitigate the threat.
For a description of the Get Visits API, go to https://my.incapsula.com/api/docs/v1/data#getVisits.

Bug Fixes
None.
Known Issues
None.

Recently Mitigated CVEs

Out-of-the-box coverage was recently added for the following list of Common Vulnerabilities and Exposures (CVEs).
The CVSS score (Common Vulnerability Scoring System) represents the severity of the vulnerability, with a low of 0
and a high of 10.
A CVE without an official CVE ID is a vulnerability that was identified and mitigated by Imperva that does not yet have
a CVE allocated to it
October 2, 2022
CVE ID Description CVSS Score

Telesquare SDT-CW3B1 1.1.0 is
affected by an OS command
injection vulnerability that allows
CVE-2021-46422 9.8
a remote attacker to execute OS
commands without any
authentication.
September 18, 2022

Apache Struts Showcase App 2.0.0
through 2.3.13, as used in Struts 2
before 2.3.14.3, allows remote
CVE-2013-1965 attackers to execute arbitrary 9.3
OGNL code via a crafted parameter
name that is not properly handled
when invoking a redirect.
September 11, 2022

The OGNL extensive expression
evaluation capability in XWork in
Struts 2.0.0 through 2.1.8.1, as
used in Atlassian Fisheye, Crucible,
and possibly other products, uses
a permissive whitelist, which
allows remote attackers to modify
CVE-2010-1870 5
server-side context objects and
bypass the "#" protection
mechanism in
ParameterInterceptors via the (1)
#context, (2) #_memberAccess, (3)
#root, (4) #this, (5) #_typeResolver,
(6) #_classResolver, (7)


#_traceEvaluations, (8)
#_lastEvaluation, (9)
#_keepLastEvaluation, and
possibly other OGNL context
variables, a different vulnerability
than CVE-2008-6504.
Apache Struts Showcase App 2.0.0
through 2.3.13, as used in Struts 2
before 2.3.14.3, allows remote
CVE-2013-1965 attackers to execute arbitrary 9.3
OGNL code via a crafted parameter
name that is not properly handled
when invoking a redirect.
Apache Struts 2 before 2.3.14.2
allows remote attackers to execute
arbitrary OGNL code via a crafted
request that is not properly
CVE-2013-2115 handled when using the 9.3
includeParams attribute in the (1)
URL or (2) A tag. NOTE: this issue is
due to an incomplete fix for
CVE-2013-1966.
Apache Struts 2.3.19 to 2.3.20.2,
2.3.21 to 2.3.24.1, and 2.3.25 to
2.3.28, when Dynamic Method
CVE-2016-3081 Invocation is enabled, allow 9.3
remote attackers to execute
arbitrary code via method: prefix,
related to chained expressions.
September 4, 2022

Grafana is an open source data
visualization platform. In affected
versions unauthenticated and
authenticated users are able to
view the snapshot with the lowest
database key by accessing the
literal paths: /dashboard/
CVE-2021-39226 7.3
snapshot/:key, or /api/
snapshots/:key. If the snapshot
'public_mode' configuration
setting is set to true (vs default of
false), unauthenticated users are
able to delete the snapshot with
the lowest database key by


accessing the literal path: /api/
snapshots-delete/:deleteKey.
Regardless of the snapshot
'public_mode' setting,
authenticated users are able to
delete the snapshot with the
lowest database key by accessing
the literal paths: /api/
snapshots/:key, or /api/snapshots-
delete/:deleteKey. The
combination of deletion and
viewing enables a complete walk
through all snapshot data while
resulting in complete snapshot
data loss. This issue has been
resolved in versions 8.1.6 and
7.5.11. If for some reason you
cannot upgrade you can use a
reverse proxy or similar to block
access to the literal paths: /api/
snapshots/:key, /api/snapshots-
delete/:deleteKey, /dashboard/
snapshot/:key, and /api/
snapshots/:key. They have no
normal function and can be
disabled without side effects.
An attacker can abuse the batch-
requests plugin to send requests
to bypass the IP restriction of
Admin API. A default configuration
of Apache APISIX (with default API
key) is vulnerable to remote code
execution. When the admin key
was changed or the port of Admin
API was changed to a port
CVE-2022-24112 9.8
different from the data panel, the
impact is lower. But there is still a
risk to bypass the IP restriction of
Apache APISIX's data panel. There
is a check in the batch-requests
plugin which overrides the client
IP with its real remote IP. But due
to a bug in the code, this check can
be bypassed.
software/apt-lib.pl in Webmin
CVE-2022-36446 before 1.997 lacks HTML escaping 9.8
for a UI command.

August 28, 2022

The MethodClosure class in
runtime/MethodClosure.java in
Apache Groovy 1.7.0 through 2.4.3
CVE-2015-3253 allows remote attackers to execute 7.5
arbitrary code or cause a denial of
service via a crafted serialized
object.
modules/bamegamenu/
ajax_phpcode.php in the
Responsive Mega Menu
(Horizontal+Vertical+Dropdown)
CVE-2018-8823 Pro module 1.0.32 for PrestaShop 7.5
1.5.5.0 through 1.7.2.5 allows
arbitrary PHP code via the code
parameter.
ThinkPHP before 3.2.4, as used in
Open Source BMS v1.1.1 and other
products, allows Remote
CVE-2019-9082 Command Execution via public//? 10
s=index/\think\app/
invokefunction&function=call_user_func_array&vars[0]=system&vars[1]
[]= followed by the command.
An Improper Authorization
vulnerability in Fortinet FortiOS
6.0.0 to 6.0.4, 5.6.0 to 5.6.8 and
5.4.1 to 5.4.10 under SSL VPN web
CVE-2018-13382 5
portal allows an unauthenticated
attacker to modify the password of
an SSL VPN web portal user via
specially crafted HTTP requests.
Netsweeper through 6.4.3 allows
unauthenticated remote code
execution because webadmin/
tools/unixlogin.php (with certain
CVE-2020-13167
Referer headers) launches a
command line with client-supplied
parameters, and allows injection
of shell metacharacters.
BigTree CMS contains a flaw in
the /index.php/admin/developer/
settings/create/ script that is
NO OFFICIAL CVE ID 9
triggered as input passed to the
'settings' POST parameter is not
properly sanitized. This may allow


an authenticated remote attacker
to execute arbitrary code.
Joomla! contains a flaw that
allows traversing outside of a
restricted path. The issue is due to
mod_random_image not properly
sanitizing input, specifically path
traversal style attacks (e.g. '../')
supplied via the 'folder'
parameter. With a specially crafted
request, a remote attacker can
have an unspecified impact.
August 21, 2022

Modern WPBakery Page Builder
Addons Plugin for WordPress
contains an unspecified flaw which
CVE-2021-24284 10
may allow a remote attacker to
upload or delete arbitrary files and
potentially execute arbitrary code.
On WatchGuard Firebox and XTM
appliances, an unauthenticated
user can execute arbitrary code,
aka FBX-22786. This vulnerability
CVE-2022-26318 9.8
impacts Fireware OS before
12.7.2_U2, 12.x before 12.1.3_U8,
and 12.2.x through 12.5.x before
12.5.9_U2.
Zimbra Collaboration (aka ZCS)
8.8.15 and 9.0 allows an
unauthenticated attacker to inject
arbitrary memcache commands
CVE-2022-27924 7.5
into a targeted instance. These
memcache commands becomes
unescaped, causing an overwrite
of arbitrary cached entries.
A vulnerability in Mobile Plugin for
Jira Data Center and Server allows
a remote, authenticated user
(including a user who joined via
CVE-2022-26135 the sign-up feature) to perform a 6.5
full read server-side request
forgery via a batch endpoint. This
affects Atlassian Jira Server and
Data Center from version 8.0.0


before version 8.13.22, from
version 8.14.0 before 8.20.10, from
version 8.21.0 before 8.22.4. This
also affects Jira Management
Server and Data Center versions
from version 4.0.0 before 4.13.22,
from version 4.14.0 before 4.20.10
and from version 4.21.0 before
4.22.4.
The Atlassian Questions For
Confluence app for Confluence
Server and Data Center creates a
Confluence user account in the
confluence-users group with the
username disabledsystemuser and
a hardcoded password. A remote,
unauthenticated attacker with
CVE-2022-26138 9.8
knowledge of the hardcoded
password could exploit this to log
into Confluence and access all
content accessible to users in the
confluence-users group. This user
account is created when installing
versions 2.7.34, 2.7.35, and 3.0.2 of
the app.
VMware Workspace ONE Access
and Identity Manager contain a
remote code execution
CVE-2022-31659 vulnerability. A malicious actor 7.2
with administrator and network
access can trigger a remote code
execution.
August 14, 2022

Adobe Experience Manager
versions 6.4 and earlier have a
Server-Side Request Forgery
CVE-2018-5006 5
vulnerability. Successful
exploitation could lead to sensitive
information disclosure.
Adobe Experience Manager
versions 6.4 and earlier have a
CVE-2018-12809 5
Server-Side Request Forgery
vulnerability. Successful


exploitation could lead to sensitive
information disclosure.
A vulnerability in Mobile Plugin for
Jira Data Center and Server allows
a remote, authenticated user
(including a user who joined via
the sign-up feature) to perform a
full read server-side request
forgery via a batch endpoint. This
affects Atlassian Jira Server and
Data Center from version 8.0.0
CVE-2022-26135 6.5
version 8.21.0 before 8.22.4. This
also affects Jira Management
Server and Data Center versions
from version 4.14.0 before 4.20.10
4.22.4.
Zoho ManageEngine Password
Manager Pro before 12101 and
PAM360 before 5510 are
vulnerable to unauthenticated
CVE-2022-35405 9.8
remote code execution. (This also
affects ManageEngine Access
Manager Plus before 4303 with
authentication.)
VMware Workspace ONE Access,
Identity Manager and vRealize
Automation contain an
authentication bypass
vulnerability affecting local
CVE-2022-31656
domain users. A malicious actor
with network access to the UI may
be able to obtain administrative
access without the need to
authenticate.
August 7, 2022

The llhttp parser in the http
module in Node.js does not strictly
CVE-2022-32214 use the CRLF sequence to delimit 9.1
HTTP requests. This can lead to
HTTP Request Smuggling (HRS).


The Apache Spark UI offers the
possibility to enable ACLs via the
configuration option
spark.acls.enable. With an
authentication filter, this checks
whether a user has access
permissions to view or modify the
application. If ACLs are enabled, a
code path in HttpSecurityFilter can
allow someone to perform
impersonation by providing an
CVE-2022-33891 arbitrary user name. A malicious 8.8
user might then be able to reach a
permission check function that
will ultimately build a Unix shell
command based on their input,
and execute it. This will result in
arbitrary shell command
execution as the user Spark is
currently running as. This affects
Apache Spark versions 3.0.3 and
earlier, versions 3.1.1 to 3.1.2, and
versions 3.2.0 to 3.2.1.
Zoho ManageEngine Password
Manager Pro before 12101 and
PAM360 before 5510 are
vulnerable to unauthenticated
CVE-2022-35405 9.8
remote code execution. (This also
affects ManageEngine Access
Manager Plus before 4303 with
authentication.)
July 24, 2022

JBoss RichFaces 4.5.3 through
4.5.17 allows unauthenticated
remote attackers to inject an
arbitrary expression language (EL)
CVE-2018-12532 7.5
variable mapper and execute
arbitrary Java code via a
MediaOutputResource's resource
request, aka RF-14309.
CVE-2021-24284 10


July 17, 2022

In Apache Druid 0.22.1 and earlier,
certain specially-crafted links
result in unescaped URL
CVE-2021-44791 parameters being sent back in
HTML responses. This makes it
possible to execute reflected XSS
attacks.
July 3, 2022

Microsoft Exchange Server Remote
CVE-2021-42321 6.5
Code Execution Vulnerability
June 19, 2022

CVE-2022-1609 WordPress Weblizar Backdoor
June 12, 2022

Versions of Confluence Server and
Data Center contain a remote code
CVE-2022-26134 execution vulnerability that allow
for an unauthenticated attacker to
perform arbitrary code execution.
May 29, 2022

The Strapi framework before 3.0.0-
beta.17.8 is vulnerable to Remote
Code Execution in the Install and
Uninstall Plugin components of
CVE-2019-19609 the Admin panel, because it does 9
not sanitize the plugin name, and
attackers can inject arbitrary shell
commands to be executed by the
execa function.


An authentication bypass
vulnerability in the User Portal and
Webadmin allows a remote
CVE-2022-1040
attacker to execute code in Sophos
Firewall version v18.5 MR3 and
older.
May 22, 2022

In spring cloud gateway versions
prior to 3.1.1+ and 3.0.7+ ,
applications are vulnerable to a
code injection attack when the
Gateway Actuator endpoint is
CVE-2022-22947 10
enabled, exposed and unsecured.
A remote attacker could make a
maliciously crafted request that
could allow arbitrary remote
execution on the remote host.
CVE-2022-1040
older.
An OS command injection
vulnerability in the CGI program of
Zyxel USG FLEX 100(W) firmware
versions 5.00 through 5.21 Patch 1,
USG FLEX 200 firmware versions
5.00 through 5.21 Patch 1, USG
FLEX 500 firmware versions 5.00
through 5.21 Patch 1, USG FLEX
700 firmware versions 5.00
through 5.21 Patch 1, USG FLEX
CVE-2022-30525 50(W) firmware versions 5.10
through 5.21 Patch 1, USG20(W)-
VPN firmware versions 5.10
through 5.21 Patch 1, ATP series
firmware versions 5.10 through
5.21 Patch 1, VPN series firmware
versions 4.60 through 5.21 Patch 1,
which could allow an attacker to
modify specific files and then
execute some OS commands on a
vulnerable device.

May 15, 2022

XStream contains a flaw that is
triggered when deserializing
com.sun.xml.ws.util.ReadAllStream$FileStream
CVE-2020-26259 classes from user-supplied XML 4.3
input. This may allow a context-
dependent attacker to delete
arbitrary files.
SEOmatic Plugin for Craft CMS
contains a flaw that is triggered as
the evaluateDynamicContent()
method is not disabled for
Yii::Base::View objects. This may
allow a remote attacker to create a
CVE-2020-24961 10
new Yii::Base::View object which
directly calls the
evaluateDynamicContent()
method, allowing them to bypass
protection mechanisms and
execute arbitrary code.
Pyrescom Termod4 contains a flaw
that is triggered as input passed
via the URL in a request to the /cgi-
bin/cfg.cgi script is not properly
CVE-2020-23160 9
sanitized. This may allow an
authenticated remote attacker to
execute arbitrary commands with
root privileges.
CVE-2022-1040
older.
On F5 BIG-IP 16.1.x versions prior
to 16.1.2.2, 15.1.x versions prior to
15.1.5.1, 14.1.x versions prior to
14.1.4.6, 13.1.x versions prior to
13.1.5, and all 12.1.x and 11.6.x
CVE-2022-1388 versions, undisclosed requests
may bypass iControl REST
authentication. Note: Software
versions which have reached End
of Technical Support (EoTS) are
not evaluated

May 1, 2022

Movable Type contains a flaw in
mt-xmlrpc.cgi that is triggered
during the handling of a specially
CVE-2021-20837 7.5
crafted message. This may allow a
remote attacker to execute
arbitrary commands.
The fix issued for CVE-2020-17530
was incomplete. So from Apache
Struts 2.0.0 to 2.5.29, still some of
the tag's attributes could perform
a double evaluation if a developer
CVE-2021-31805 applied forced OGNL evaluation by 7.5
using the %{...} syntax. Using
forced OGNL evaluation on
untrusted user input can lead to a
Remote Code Execution and
security degradation.
Certain WSO2 products allow
unrestricted file upload with
resultant remote code execution.
This affects WSO2 API Manager
2.2.0 and above through 4.0.0;
WSO2 Identity Server 5.2.0 and
CVE-2022-29464 above through 5.11.0; WSO2
Identity Server Analytics 5.4.0,
5.4.1, 5.5.0, and 5.6.0; WSO2
Identity Server as Key Manager
5.3.0 and above through 5.10.0;
and WSO2 Enterprise Integrator
6.2.0 and above through 6.6.0.
April 24, 2022

Improper Access Control to
Remote Code Execution in GitHub
CVE-2022-0824
repository webmin/webmin prior
to 1.990.
VMware Workspace ONE Access
and Identity Manager contain a
remote code execution
CVE-2022-22954 vulnerability due to server-side
template injection. A malicious
actor with network access can
trigger a server-side template


injection that may result in remote
code execution.
April 10, 2022
Spring Framework RCE via Data

CVE-2022-22965
Binding on JDK 9+
April 3, 2022

Spring Security OAuth, versions
2.3 prior to 2.3.3, 2.2 prior to 2.2.2,
2.1 prior to 2.1.2, 2.0 prior to 2.0.15
and older unsupported versions
contains a remote code execution
vulnerability. A malicious user or
CVE-2018-1260 7.5
attacker can craft an authorization
request to the authorization
endpoint that can lead to remote
code execution when the resource
owner is forwarded to the
approval endpoint.
strapi before 3.0.0-beta.17.5
mishandles password resets
within packages/strapi-admin/
CVE-2019-18818 5
controllers/Auth.js and packages/
strapi-plugin-users-permissions/
controllers/Auth.js.
The Strapi framework before 3.0.0-
beta.17.8 is vulnerable to Remote
Code Execution in the Install and
Uninstall Plugin components of
CVE-2019-19609 the Admin panel, because it does 9
not sanitize the plugin name, and
attackers can inject arbitrary shell
commands to be executed by the
execa function.
A crafted request uri-path can
cause mod_proxy to forward the
request to an origin server chosen
CVE-2021-40438 6.8
by the remote user. This issue
affects Apache HTTP Server 2.4.48
and earlier.


In Spring Cloud Function versions
3.1.6, 3.2.2 and older unsupported
versions, when using routing
functionality it is possible for a
CVE-2022-22963 user to provide a specially crafted
SpEL as a routing-expression that
may result in remote code
execution and access to local
resources.
A Spring MVC or Spring WebFlux
application running on JDK 9+
may be vulnerable to remote code
execution (RCE) via data binding.
The specific exploit requires the
application to run on Tomcat as a
WAR deployment. If the
CVE-2022-22965
application is deployed as a Spring
Boot executable jar, i.e. the
default, it is not vulnerable to the
exploit. However, the nature of the
vulnerability is more general, and
there may be other ways to exploit
it.
March 20, 2022

In Apache httpd before 2.2.34 and
2.4.x before 2.4.27, the value
placeholder in
[Proxy-]Authorization headers of
type 'Digest' was not initialized or
reset before or between successive
key=value assignments by
mod_auth_digest. Providing an
CVE-2017-9788 6.4
initial key with no '=' assignment
could reflect the stale value of
uninitialized pool memory used by
the prior request, leading to
leakage of potentially confidential
information, and a segfault in
other cases resulting in denial of
service.
Microsoft SharePoint Server
contains an unspecified flaw that
CVE-2022-22005 9
is triggered when handling the
creation of a specially crafted


page. This may allow an
CVE-2022-0824
to 1.990.
The TP-240 (aka tp240dvr)
component in Mitel MiCollab
before 9.4 SP1 FP1 and MiVoice
Business Express through 8.1
allows remote attackers to obtain
sensitive information and cause a
CVE-2022-26143
denial of service (performance
degradation and excessive
outbound traffic). This was
exploited in the wild in February
and March 2022 for the
TP240PhoneHome DDoS attack.
March 13, 2022

CVE-2022-0824
to 1.990.
March 6, 2022

A remote code execution
vulnerability exists in Microsoft
Exchange software when the
CVE-2020-0688 software fails to properly handle 9
objects in memory, aka 'Microsoft
Exchange Memory Corruption
Vulnerability'.
Movable Type contains a flaw in
mt-xmlrpc.cgi that is triggered
during the handling of a specially
CVE-2021-20837 7.5
crafted message. This may allow a
arbitrary commands.
Adobe Commerce versions 2.4.3-
CVE-2022-24086 p1 (and earlier) and 2.3.7-p2 (and 10
earlier) are affected by an


improper input validation
vulnerability during the checkout
process. Exploitation of this issue
does not require user interaction
and could result in arbitrary code
execution.
February 27, 2022

elFinder is an open-source file
manager for web, written in
JavaScript using jQuery UI. Several
vulnerabilities affect elFinder
2.1.58. These vulnerabilities can
allow an attacker to execute
arbitrary code and commands on
CVE-2021-32682
the server hosting the elFinder
PHP connector, even with minimal
configuration. The issues were
patched in version 2.1.59. As a
workaround, ensure the connector
is not exposed without
authentication.
February 20, 2022

Zoho ManageEngine ServiceDesk
Plus before 11306, ServiceDesk
Plus MSP before 10530, and
SupportCenter Plus before 11014
CVE-2021-44077 are vulnerable to unauthenticated
remote code execution. This is
related to /RestAPI URLs in a
servlet, and ImportTechnicians in
the Struts configuration.
February 13, 2022

Multiple ZyXEL NAS devices
contain a flaw in the weblogin.cgi
script that is triggered as input
CVE-2020-9054 10
passed to the 'username'
parameter is not properly
sanitized. With a specially crafted


inject commands (and
subsequently execute arbitrary
code) with root privileges.
Vulnerability in the Oracle
WebLogic Server product of Oracle
Fusion Middleware (component:
Web Container). Supported
versions that are affected are
12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0
and 14.1.1.0.0. Easily exploitable
vulnerability allows
unauthenticated attacker with
network access via HTTP to
CVE-2022-21371 5
compromise Oracle WebLogic
Server. Successful attacks of this
vulnerability can result in
unauthorized access to critical
data or complete access to all
Oracle WebLogic Server accessible
data. CVSS 3.1 Base Score 7.5
(Confidentiality impacts). CVSS
Vector: (CVSS:3.1/AV:N/AC:L/PR:N/
UI:N/S:U/C:H/I:N/A:N).
February 6, 2022

An issue has been discovered in
GitLab CE/EE affecting all versions
starting from 11.9. GitLab was not
CVE-2021-22205 properly validating image files that
were passed to a file parser which
resulted in a remote command
execution.
January 30, 2022

A command injection vulnerability
in the web server of some
Hikvision product. Due to the
CVE-2021-36260 insufficient input validation, 9.3
attacker can exploit the
vulnerability to launch a command
injection attack by sending some


messages with malicious
commands.
The
org.h2.util.JdbcUtils.getConnection
method of the H2 database takes
as parameters the class name of
the driver and URL of the
database. An attacker may pass a
JNDI driver name and a URL
CVE-2021-42392
leading to a LDAP or RMI servers,
causing remote code execution.
This can be exploited through
various attack vectors, most
notably through the H2 Console
which leads to unauthenticated
remote code execution.
January 23, 2022

HTTP Protocol Stack Remote Code
CVE-2022-21907
Execution Vulnerability.
January 9, 2022

In affected versions of Confluence
Server and Data Center, an OGNL
injection vulnerability exists that
would allow an authenticated
user, and in some instances an
unauthenticated user, to execute
arbitrary code on a Confluence
Server or Data Center instance.
The vulnerable endpoints can be
accessed by a non-administrator
CVE-2021-26084 user or unauthenticated user if
â€Ãllow people to sign up to
create their accountâ€™ is
enabled. To check whether this is
enabled go to COG > User
Management > User Signup
Options. The affected versions are
version 7.5.0 before 7.11.6, and
from version 7.12.0 before 7.12.5.


OptinMonster Plugin for
WordPress contains a flaw in
the /wp-json/omapp/v1/support
script that is triggered as the
logged_in_or_has_api_key()
CVE-2021-39341 5
function fails to properly perform
capability checks. This may allow a
remote attacker to access the
endpoint and disclose API key
information.
January 2, 2022

Thinfinity VirtualUI before 3.0 has
functionality in /lab.html
CVE-2021-45092 reachable by default that could
allow IFRAME injection via the
vpath parameter.
December 26, 2021

Apache Log4j2 <=2.14.1 JNDI
features used in configuration, log
messages, and parameters do not
protect against attacker controlled
LDAP and other JNDI related
endpoints. An attacker who can
control log messages or log
message parameters can execute
arbitrary code loaded from LDAP
servers when message lookup
substitution is enabled. From log4j
2.15.0, this behavior has been
CVE-2021-44228
disabled by default. In previous
releases (>2.10) this behavior
can be mitigated by setting system
property
'log4j2.formatMsgNoLookups' to
â€œtrueâ€ or by removing the
JndiLookup class from the
classpath (example: zip -q -d log4j-
core-*.jar org/apache/logging/
log4j/core/lookup/
JndiLookup.class). Java 8u121
(see https://www.oracle.com/java/


technologies/javase/8u121-
relnotes.html) protects against
remote code execution by
defaulting
'com.sun.jndi.rmi.object.trustURLCodebase'
and
'com.sun.jndi.cosnaming.object.trustURLCodebase'
to 'false'.
It was found that the fix to address
CVE-2021-44228 in Apache Log4j
2.15.0 was incomplete in certain
non-default configurations. This
could allows attackers with control
over Thread Context Map (MDC)
input data when the logging
configuration uses a non-default
Pattern Layout with either a
Context Lookup (for example, $$
{ctx:loginId}) or a Thread Context
Map pattern (%X, %mdc, or
%MDC) to craft malicious input
data using a JNDI Lookup pattern
resulting in a denial of service
(DOS) attack. Log4j 2.15.0 restricts
JNDI LDAP lookups to localhost by
CVE-2021-45046 default. Note that previous
mitigations involving
configuration such as to set the
system property
`log4j2.noFormatMsgLookup` to
`true` do NOT mitigate this
specific vulnerability. Log4j 2.16.0
fixes this issue by removing
support for message lookup
patterns and disabling JNDI
functionality by default. This issue
can be mitigated in prior releases
(<2.16.0) by removing the
log4j/core/lookup/
JndiLookup.class).

December 19, 2021

Included in Log4j 1.2 is a
SocketServer class that is
vulnerable to deserialization of
untrusted data which can be
exploited to remotely execute
CVE-2019-17571 arbitrary code when combined 7.5
with a deserialization gadget when
listening to untrusted network
traffic for log data. This affects
Log4j versions up to 1.2 up to
1.2.17.
releases (>2.10) this behavior
can be mitigated by setting system
property
CVE-2021-44228
'log4j2.formatMsgNoLookups' to
â€œtrueâ€ or by removing the
log4j/core/lookup/
JndiLookup.class). Java 8u121
(see https://www.oracle.com/java/
technologies/javase/8u121-
relnotes.html) protects against
remote code execution by
defaulting
'com.sun.jndi.rmi.object.trustURLCodebase'
and
'com.sun.jndi.cosnaming.object.trustURLCodebase'
to 'false'.

December 12, 2021

CVE-2021-44228
releases (>2.10) this behavior can
be mitigated by setting system
property
"log4j2.formatMsgNoLookups" to
“true” or it can be
mitigated in prior releases (<2.10)
by removing the JndiLookup class
from the classpath (example: zip
-q -d log4j-core-*.jar org/apache/
logging/log4j/core/lookup/
JndiLookup.class).
CVE-2021-42321 6.5
Code Execution Vulnerability
December 5, 2021

A file upload issue exists in
CVE-2015-4553 DeDeCMS before 5.7-sp1, which 6.5
allows malicious users getshell.
Fortinet FortiWeb contains a flaw
in the SAML server configuration
page within the management
interface. The issue is triggered as
input passed to the 'name' POST
parameter via /api/v2.0/user/
remoteserver.saml is not properly
validated. With a specially crafted
HTTP POST request, an
authenticated remote attacker can
inject and execute arbitrary
commands with root privileges.


Metabase is an open source data
analytics platform. In affected
versions a security issue has been
discovered with the custom
GeoJSON map (àdmin-
>settings->maps->custom
maps->add a map`) support
and potential local file inclusion
(including environment variables).
URLs were not validated prior to
CVE-2021-41277
being loaded. This issue is fixed in
a new maintenance release (0.40.5
and 1.40.5), and any subsequent
release after that. If youÃ¢â‚¬â„¢re
unable to upgrade immediately,
you can mitigate this by including
rules in your reverse proxy or load
balancer or WAF to provide a
validation filter before the
application.
November 21, 2021

Multiple vulnerabilities in the web-
based management interface of
Cisco HyperFlex HX could allow an
unauthenticated, remote attacker
CVE-2021-1497 to perform command injection 10
attacks against an affected device.
For more information about these
vulnerabilities, see the Details
section of this advisory.
Cisco HyperFlex HX Data Platform
input is not properly validated
when handling a specially crafted
CVE-2021-1498 7.5
request. This may allow a remote
attacker to potentially execute
arbitrary commands as the
tomcat8 user.
In affected versions of Confluence
Server and Data Center, an OGNL
injection vulnerability exists that
CVE-2021-26084
would allow an authenticated
user, and in some instances an
unauthenticated user, to execute


arbitrary code on a Confluence
Server or Data Center instance.
The vulnerable endpoints can be
accessed by a non-administrator
user or unauthenticated user if
â€Ãllow people to sign up to
create their accountâ€™ is
enabled. To check whether this is
enabled go to COG > User
Management > User Signup
Options. The affected versions are
version 7.5.0 before 7.11.6, and
from version 7.12.0 before 7.12.5.
November 14, 2021

The MailPoet Newsletters (wysija-
newsletters) plugin before 2.6.7 for
WordPress allows remote
attackers to bypass authentication
and execute arbitrary PHP code by
CVE-2014-4725 7.5
uploading a crafted theme using
wp-admin/admin-post.php and
accessing the theme in wp-
content/uploads/wysija/themes/
mailp/.
Unrestricted file upload
vulnerability in includes/
upload.php in the Aviary Image
Editor Add-on For Gravity Forms
plugin 3.0 beta for WordPress
arbitrary code by uploading a file
with an executable extension, then
accessing it via a direct request to
the file in wp-content/uploads/
gform_aviary.
Joomla! 1.5.x, 2.x, and 3.x before
3.4.6 allow remote attackers to
conduct PHP object injection
CVE-2015-8562 attacks and execute arbitrary PHP 7.5
code via the HTTP User-Agent
header, as exploited in the wild in
December 2015.


Unrestricted file upload
vulnerability in upload.php in the
Giulio Ganci Wp Downloads
Manager module 0.2 for WordPress
allows remote attackers to execute
CVE-2008-3362 arbitrary code by uploading a file 10
with an executable extension via
the upfile parameter, then
accessing it via a direct request to
the file in wp-content/plugins/
downloads-manager/upload/.
An issue was discovered in Kentico
before 12.0.15. Due to a failure to
validate security headers, it was
possible for a specially crafted
request to the staging service to
bypass the initial authentication
CVE-2019-10068 7.5
and proceed to deserialize user-
controlled .NET object input. This
deserialization then led to
execution on the server where the
Kentico instance was hosted.
execution.
OptinMonster Plugin for
the /wp-json/omapp/v1/support
script that is triggered as the
logged_in_or_has_api_key()
CVE-2021-39341 5
function fails to properly perform
capability checks. This may allow a
remote attacker to access the
endpoint and disclose API key
information.
November 7, 2021

Sitecore Experience Platform (XP)
CVE-2019-11080 prior to 9.1.1 is vulnerable to 9
remote code execution via


deserialization, aka TFS # 293863.
An authenticated user with
necessary permissions is able to
remotely execute OS commands
by sending a crafted serialized
object.
execution.
HPE iLO Amplifier Pack Server
contains a flaw that allows
traversing outside of a restricted
path. The issue is due to the
program not properly sanitizing
CVE-2021-29212 10
input, specifically path traversal
style attacks (e.g. '../'). With a
specially crafted request, a remote
attacker can potentially execute
arbitrary code.
October 31, 2021

Affected versions of Atlassian
Confluence Server allow remote
attackers to view restricted
resources via a Pre-Authorization
CVE-2021-26085 Arbitrary File Read vulnerability in
the /s/ endpoint. The affected
versions are before version 7.4.10,
7.12.3.
Affected versions of Atlassian Jira
Server and Data Center allow
remote attackers to read particular
files via a path traversal
vulnerability in the /WEB-INF/
CVE-2021-26086
web.xml endpoint. The affected
8.16.1.


A crafted request uri-path can
cause mod_proxy to forward the
request to an origin server
CVE-2021-40438 6.8
choosen by the remote user. This
issue affects Apache HTTP Server
2.4.48 and earlier.
October 24, 2021

CVE-2020-9054 10
Microsoft Open Management
Infrastructure (OMI) contains a
flaw in the client/server
communication related to the
Authorization header. The issue is
triggered when a remote attacker
CVE-2021-38647 10
makes a request and simply
removes the Authorization header
completely. With a crafted request,
the server will trust the request
implicitly and allow for the
execution of arbitrary commands.
It was found that the fix for
CVE-2021-41773 in Apache HTTP
Server 2.4.50 was insufficient. An
attacker could use a path traversal
attack to map URLs to files outside
the directories configured by Alias-
like directives. If files outside of
CVE-2021-42013
these directories are not protected
by the usual default configuration
'require all denied', these requests
can succeed. If CGI scripts are also
enabled for these aliased pathes,
this could allow for remote code
execution. This issue only affects


Apache 2.4.49 and Apache 2.4.50
and not earlier versions.
October 17, 2021

Affected versions of Atlassian
Confluence Server allow remote
attackers to view restricted
resources via a Pre-Authorization
CVE-2021-26085 Arbitrary File Read vulnerability in
the /s/ endpoint. The affected
7.12.3.
Affected versions of Atlassian Jira
Server and Data Center allow
remote attackers to read particular
files via a path traversal
vulnerability in the /WEB-INF/
CVE-2021-26086
web.xml endpoint. The affected
8.16.1.
AlphaWeb XE contains a flaw in the
custom scripts in /index.php that
is triggered as file types and
extensions for uploaded files are
not properly validated before
being placed in a web-accessible
CVE-2021-40845 9
path. This may allow an
upload e.g. a PHP file and then
request it in order to execute
arbitrary code with the privileges
of the web servic
October 10, 2021

The Apache HTTP Server through
2.4.23 follows RFC 3875 section
4.1.18 and therefore does not
CVE-2016-5387 5.1
protect applications from the
presence of untrusted client data
in the HTTP_PROXY environment


variable, which might allow
remote attackers to redirect an
application's outbound HTTP
traffic to an arbitrary proxy server
via a crafted Proxy header in an
HTTP request, aka an 'httpoxy'
issue. NOTE: the vendor states
'This mitigation has been assigned
the identifier CVE-2016-5387'; in
other words, this is not a CVE ID for
a vulnerability.
Apache HTTP Server (httpd)
ap_normalize_path() function in
server/util.c not properly
CVE-2021-41773 traversal style attacks (e.g. '../') 5
when handling URLs mapped to
files outside the document root.
With a specially crafted request, a
remote attacker can read files
outside the document root or
disclose the source code of CGI
scripts.
October 3, 2021

Budget and Expense Tracker
System contains a flaw in /classes/
Users.php that is triggered as file
types and extensions for uploaded
files are not properly validated
before being placed in a web-
accessible path. This may allow a
remote attacker to upload e.g. a
PHP file and then request it in
order to execute arbitrary code
with the privileges of the web
service.

September 26, 2021

Fortinet FortiWeb contains a flaw
in the SAML server configuration
page within the management
interface. The issue is triggered as
input passed to the 'name' POST
parameter via /api/v2.0/user/
remoteserver.saml is not properly
validated. With a specially crafted
HTTP POST request, an
inject and execute arbitrary
commands with root privileges.
September 5, 2021

Multiple Mimosa Backhaul Devices
contain a flaw in the
getThroughput() method in
the /var/www/core/api/calls/
Througput.php script that is
CVE-2020-25206 triggered input is not properly 10
validated. This may allow a remote
attacker to execute arbitrary
commands on the underlying
device with administrative
privileges.
Simple 301 Redirects by
BetterLinks Plugin for WordPress
contains a flaw in the
wp_ajax_simple301redirects/
admin/wildcard and /
CVE-2021-24355 admin/get_wildcard AJAX actions 5.5
that is triggered as capability
checks are not properly
implemented. This may allow an
enable wildcards and disclose
wildcard values.
CVE-2021-24354 contains a flaw in the 6.5
activate_plugin() function in the


admin/activate_plugin AJAX
action that is triggered as
capability checks are not properly
install and activate arbitrary
plugins via the 'slug' parameter
install_plugin() function in the
admin/install_plugin AJAX action
CVE-2021-24356 6.5
that is triggered as capability
checks are not properly
install and activate arbitrary
plugins via the 'slug' parameter.
In affected versions of Confluence Server and Data Center, an OGNL
injection vulnerability exists that would allow an authenticated user,
and in some instances an unauthenticated user, to execute arbitrary
code on a Confluence Server or Data Center instance. The vulnerable
endpoints can be accessed by a non-administrator user or
CVE-2021-26084
unauthenticated user if â€Ãllow people to sign up to create their
accountâ€™ is enabled. To check whether this is enabled go to COG
> User Management > User Signup Options. The affected
versions are before version 6.13.23, from version 6.14.0 before 7.4.11,
from version 7.5.0 before 7.11.6, and from version 7.12.0 before 7.12.5.
Eclipse Keti contains a flaw in
createPolicySet in
PolicyManagementController that
is triggered during the handling of
CVE-2021-32834 9
a specially crafted PolicySet
object. This may allow a remote
Groovy code.
August 22, 2021

Telerik.Web.UI in Progress Telerik
UI for ASP.NET AJAX before R1
CVE-2017-11317 2017 and R2 before R2 2017 SP2 7.5
uses weak RadAsyncUpload
encryption, which allows remote


attackers to perform arbitrary file
uploads or execute arbitrary code.
August 15, 2021

When requests to the internal network for webhooks are enabled, a
server-side request forgery vulnerability in GitLab CE/EE affecting all
CVE-2021-22214 versions starting from 10.5 was possible to exploit for an
unauthenticated attacker even on a GitLab instance where
registration is limited
Multiple VMware products contain
a flaw related to request handling
between a user and a server,
where the server can be induced
into performing unintended
actions (Server Side Request
Forgery aka SSRF). By sending a
CVE-2021-22002 6.4
specially crafted host header in a
request, the server can be used to
conduct host-based attacks. This
gain access to the /cfg web app
and /cfg diagnostic endpoints
without authentication.
August 1, 2021

ForgeRock OpenAM contains a
flaw in the /ccversion/Version
supplied to the 'pageSession' GET
CVE-2021-35464 10
parameter is insecurely
deserialized. This may allow a
remote attacker to potentially
July 25, 2021

6.0.0 to 6.0.4, 5.6.0 to 5.6.8 and
CVE-2018-13382 5


Jenkins Git Client Plugin 2.8.4 and
earlier and 3.0.0-rc did not
properly restrict values passed as
CVE-2019-10392 6.5
URL argument to an invocation of
'git ls-remote', resulting in OS
command injection.
An issue was discovered in rConfig
3.9.2. An attacker can directly
execute system commands by
sending a GET request to
CVE-2019-16663 search.crud.php because the 9
catCommand parameter is passed
to the exec function without
filtering, which can lead to
command execution.
3.9.3. A remote authenticated user
can directly execute system
commands by sending a GET
CVE-2019-19509 request to ajaxArchiveFiles.php 9
because the path parameter is
passed to the exec function
without filtering, which can lead to
command execution.
Machform contains a flaw in /
embed.php that is triggered as file
CVE-2021-20104 accessible path. This may allow a 10
PHT or PHP7 file and then request
it in order to execute arbitrary
code with the privileges of the web
service.
July 18, 2021

6.0.0 to 6.0.4, 5.6.0 to 5.6.8 and
CVE-2018-13382 5


Jenkins Git Client Plugin 2.8.4 and
earlier and 3.0.0-rc did not
properly restrict values passed as
CVE-2019-10392 6.5
URL argument to an invocation of
'git ls-remote', resulting in OS
command injection.
3.9.3. A remote authenticated user
can directly execute system
commands by sending a GET
CVE-2019-19509 request to ajaxArchiveFiles.php 9
because the path parameter is
passed to the exec function
without filtering, which can lead to
command execution.
When requests to the internal network for webhooks are enabled, a
server-side request forgery vulnerability in GitLab CE/EE affecting all
CVE-2021-22214 versions starting from 10.5 was possible to exploit for an
unauthenticated attacker even on a GitLab instance where
registration is limited
ForgeRock OpenAM contains a
flaw in the /ccversion/Version
supplied to the 'pageSession' GET
CVE-2021-35464 10
parameter is insecurely
July 11, 2021

The REST API in CyberArk
Password Vault Web Access before
9.9.5 and 10.x before 10.1 allows
CVE-2018-9843 remote attackers to execute 7.5
arbitrary code via a serialized .NET
object in an Authorization HTTP
header.
OpenEMR 5.0.1 allows an authenticated attacker to upload and
CVE-2020-19364
execute malicious PHP scripts through /controller.php.
Arbitrary file upload in the Modern Events Calendar Lite WordPress
plugin, versions before 5.16.5, did not properly check the imported
CVE-2021-24145
file, allowing PHP ones to be uploaded by administrator by using the
'text/csv' content-type in the request.


privileges.
Netflix NdBench contains a flaw in
the /REST/ndbench/driver/
initfromscript API endpoint that is
NO OFFICIAL CVE ID triggered when evaluating Groovy 9.3
scripts. This may allow a context-
dependent attacker to execute
arbitrary code.
Jkev Online Voting System
contains a flaw in /admin/
save_candidate.php that is
triggered as file types and
NO OFFICIAL CVE ID being placed in a web-accessible 9
authenticated, remote attacker to
of the web service.
NeDi contains a flaw in the /
pwsec.php script that is triggered
as input passed to the 'pw' POST
CVE-2021-27361 parameter is not properly 10
execute arbitrary commands.
July 4, 2021

The REST API in CyberArk
Password Vault Web Access before
CVE-2018-9843 9.9.5 and 10.x before 10.1 allows 7.5
arbitrary code via a serialized .NET


object in an Authorization HTTP
header.
Nacos contains a flaw in the
AuthFilter Servlet Filter that is
triggered as the program fails to
properly validated User-Agent
CVE-2021-29441 HTTP headers in POST requests for 7.5
the /nacos/v1/cs/configs script.
This may allow a remote attacker
to bypass authentication
mechanisms.
ConfigOpsController that is
perform authentication checks
CVE-2021-29442 when handling requests for the / 6.4
derby endpoint. This may allow a
remote attacker to query the
database or delete content within
the database.
privileges.
This vulnerability allows remote
attackers to execute arbitrary code
on affected installations of
SolarWinds Network Performance
Monitor 2020.2.1. Authentication is
not required to exploit this
vulnerability. The specific flaw
CVE-2021-31474 exists within the 10
SolarWinds.Serialization library.
The issue results from the lack of
proper validation of user-supplied
data, which can result in
deserialization of untrusted data.
An attacker can leverage this
vulnerability to execute code in


the context of SYSTEM. Was ZDI-
CAN-12213.
June 27, 2021

Trend Micro InterScan Web
Security Virtual Appliance (IWSVA)
Java_com_trend_iwss_gui_IWSSJNI_AddVLANItem()
function in libuiauutil.so that is
triggered as input in the 'id'
CVE-2020-28580 parameter via /servlet/ 6.5
com.trend.iwss.gui.servlet.ManageVLANSettings
is not properly validated. This may
allow an authenticated remote
attacker to inject and
commands.
Java_com_trend_iwss_gui_IWSSJNI_ModifyVLANItem()
triggered as input in HTTP
CVE-2020-28581 messages via /servlet/ 6.5
commands.
Information Exposure vulnerability
in context asset handling of
Apache Tapestry allows an
attacker to download files inside
WEB-INF if using a specially-
constructed URL. This was caused
CVE-2021-30638 5
by an incomplete fix for
CVE-2020-13953. This issue affects
Apache Tapestry Apache Tapestry
5.4.0 version to Apache Tapestry
5.6.3; Apache Tapestry 5.7.0
version and Apache Tapestry 5.7.1.
CVE-2021-29441 AuthFilter Servlet Filter that is 7.5


properly validated User-Agent
HTTP headers in POST requests for
the /nacos/v1/cs/configs script.
to bypass authentication
mechanisms.
ConfigOpsController that is
perform authentication checks
CVE-2021-29442 when handling requests for the / 6.4
derby endpoint. This may allow a
remote attacker to query the
database or delete content within
the database.
This vulnerability allows remote
attackers to execute arbitrary code
on affected installations of
SolarWinds Network Performance
Monitor 2020.2.1. Authentication is
not required to exploit this
vulnerability. The specific flaw
exists within the
CVE-2021-31474 SolarWinds.Serialization library. 10
The issue results from the lack of
proper validation of user-supplied
data, which can result in
deserialization of untrusted data.
An attacker can leverage this
vulnerability to execute code in
the context of SYSTEM. Was ZDI-
CAN-12213.
Joomla! Core is prone to a security bypass vulnerability. Exploiting
this issue may allow attackers to perform otherwise restricted actions
and subsequently retrieve password reset tokens from the database
CVE-2010-1435
through an already existing SQL injection vector. Joomla! Core
versions 1.5.x ranging from 1.5.0 and up to and including 1.5.15 are
vulnerable.
Customer Relationship
Management (CRM) contains a
flaw that is triggered as file types
and extensions for uploaded files
NO OFFICIAL CVE ID are not properly validated before 9


of the web service.
June 20, 2021

Java_com_trend_iwss_gui_IWSSJNI_AddVLANItem()
triggered as input in the 'id'
CVE-2020-28580 parameter via /servlet/ 6.5
commands.
commands.
FasterXML jackson-databind 2.x
before 2.9.10.8 mishandles the
CVE-2020-36180 interaction between serialization 6.8
gadgets and typing, related to
org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.
oadd.org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS.
CVE-2020-36181 before 2.9.10.8 mishandles the 6.8
interaction between serialization


org.apache.tomcat.dbcp.dbcp.cpdsadapter.DriverAdapterCPDS.
org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS.
org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool.
org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource.
org.apache.tomcat.dbcp.dbcp2.datasources.SharedPoolDataSource.
org.apache.tomcat.dbcp.dbcp.datasources.PerUserPoolDataSource.
org.apache.tomcat.dbcp.dbcp.datasources.SharedPoolDataSource.
com.newrelic.agent.deps.ch.qos.logback.core.db.JNDIConnectionSource.
com.newrelic.agent.deps.ch.qos.logback.core.db.DriverManagerConnectionSource.
SonicWall Email Security version 10.0.9.x contains a vulnerability that
CVE-2021-20022 allows a post-authenticated attacker to upload an arbitrary file to the
remote host.


VMware vCenter Server contains a
flaw in the vSphere Client (HTML5)
that is triggered as input passed to
the Virtual SAN Health Check plug-
CVE-2021-21985 10
in is not properly validated. With a
attacker can execute arbitrary
commands.
June 13, 2021

Dup Scout Enterprise contains an
overflow condition in the /
online_registration script. The
issue is triggered as certain input is
not properly validated when
passed to the 'customer_name'
and 'unlock_key' POST
parameters. This may allow a
remote attacker to cause a buffer
overflow, resulting in a denial of
service or potentially allowing the
execution of arbitrary code.
Voting System contains a flaw in /
votesystem/admin/
voters_add.php that is triggered as
file types and extensions for
uploaded files are not properly
validated before being placed in a
web-accessible path. This may
attacker to upload e.g. a PHP file
and then request it in order to
execute arbitrary code with the
privileges of the web service.
Nagios XI contains a flaw in html/
includes/configwizards/cloud-vm/
cloud-vm.inc.php that is triggered
as input to the 'ip_address'
CVE-2021-25298 sanitized. With a specially crafted 9
request to /nagiosxi/config/
monitoringwizard.php, an
authenticated, remote attacker
can inject and execute arbitrary
commands.


includes/configwizards/switch/
switch.inc.php that is triggered as
input to the 'ip_address'
commands.
CVE-2021-21985 10
commands.
June 6, 2021

HTTP Protocol Stack Remote Code
CVE-2021-31166 7.5
Execution Vulnerability
CVE-2021-21985 10
commands.
May 30, 2021

The RichFaces Framework 3.X
through 3.3.4 is vulnerable to
Expression Language (EL) injection
via the UserResource resource. A
CVE-2018-14667 remote, unauthenticated attacker 7.5
could exploit this to execute
arbitrary code using a chain of java
serialized objects via
org.ajax4jsf.resource.UserResource$UriData.


The Plus Addons for Elementor
Plugin for WordPress contains an
unspecified flaw which may allow
CVE-2021-24175 a remote attacker to bypass 10
authentication mechanisms. No
further details have been
provided.
May 9, 2021

HTTPServerILServlet.java in JMS
over HTTP Invocation Layer of the
JbossMQ implementation, which
is enabled by default in Red Hat
Jboss Application Server <=
CVE-2017-7504 Jboss 4.X does not restrict the 7.5
classes for which it performs
deserialization, which allows
arbitrary code via crafted
serialized data.
EyesOfNetwork contain a flaw that
is triggered as input passed via the
'target' GET parameter to the /
NO OFFICIAL CVE ID autodiscovery.php script is not 9
properly validated. This may allow
to execute arbitrary commands.
EyesOfNetwork contains a flaw
that allows traversing outside of a
the /module/tool_all/
select_tool.php script not properly
NO OFFICIAL CVE ID sanitizing input, specifically 5
absolute paths supplied via the
'tool_list' GET parameter. With a
attacker can disclose arbitrary
files.
includes/configwizards/cloud-vm/
cloud-vm.inc.php that is triggered
CVE-2021-25298 as input to the 'ip_address' 9


commands.
includes/configwizards/switch/
switch.inc.php that is triggered as
input to the 'ip_address'
commands.
A vulnerability in the SonicWall Email Security version 10.0.9.x allows
CVE-2021-20021 an attacker to create an administrative account by sending a crafted
HTTP request to the remote host.
May 2, 2021

A vulnerability in the SonicWall Email Security version 10.0.9.x allows
CVE-2021-20021 an attacker to create an administrative account by sending a crafted
HTTP request to the remote host.
CVE-2021-20022 allows a post-authenticated attacker to upload an arbitrary file to the
remote host.
CVE-2021-20023 allows a post-authenticated attacker to read an arbitrary file on the
remote host.
SAINT Security Suite contains a
flaw that allows traversing outside
of a restricted path. The issue is
due to the Agent service not
properly sanitizing input,
NO OFFICIAL CVE ID specifically path traversal style 10
attacks (e.g. '../'). With a specially
crafted request, a remote attacker
can overwrite arbitrary files and
execute commands with root
privileges.
CVE-2021-24284 10


Drupal contains a flaw that allows
a cross-site scripting (XSS) attack.
This flaw exists because the
sanitization API does not properly
sanitize input before returning it to
users. This may allow a remote
attacker to potentially create a
specially crafted request that
executes arbitrary script code in a
user's browser session within the
trust relationship between their
browser and the server.
Buffalo WSR-2533DHPL2 and
WSR-2533DHP3 contain a flaw that
unspecified web interfaces not
CVE-2021-20090 properly sanitizing input, 10
specifically path traversal style
can bypass authentication
mechanisms.
April 25, 2021

Primetek Primefaces 5.x is
vulnerable to a weak encryption
CVE-2017-1000486 7.5
flaw resulting in remote code
execution
A critical unauthenticated remote code execution vulnerability was
found all recent versions of Apache Tapestry. The affected versions
include 5.4.5, 5.5.0, 5.6.2 and 5.7.0. The vulnerability I have found is a
bypass of the fix for CVE-2019-0195. Recap: Before the fix of
CVE-2019-0195 it was possible to download arbitrary class files from
the classpath by providing a crafted asset file URL. An attacker was
able to download the file ÀppModule.class` by requesting the URL
CVE-2021-27850
`http://localhost:8080/assets/something/services/AppModule.class`
which contains a HMAC secret key. The fix for that bug was a blacklist
filter that checks if the URL ends with `.class`, `.properties` or
`.xml`. Bypass: Unfortunately, the blacklist solution can simply be
bypassed by appending a `/` at the end of the URL: `http://
localhost:8080/assets/something/services/AppModule.class/` The
slash is stripped after the blacklist check and the file


ÀppModule.class` is loaded into the response. This class usually
contains the HMAC secret key which is used to sign serialized Java
objects. With the knowledge of that key an attacker can sign a Java
gadget chain that leads to RCE (e.g. CommonsBeanUtils1 from
ysoserial). Solution for this vulnerability: * For Apache Tapestry 5.4.0
to 5.6.1, upgrade to 5.6.2 or later. * For Apache Tapestry 5.7.0, upgrade
to 5.7.1 or later.
SAINT Security Suite contains a
due to the Agent service not
NO OFFICIAL CVE ID specifically path traversal style 10
can overwrite arbitrary files and
execute commands with root
privileges.
Drupal contains a flaw that allows
a cross-site scripting (XSS) attack.
This flaw exists because the
sanitization API does not properly
sanitize input before returning it to
users. This may allow a remote
attacker to potentially create a
specially crafted request that
executes arbitrary script code in a
user's browser session within the
trust relationship between their
browser and the server.
April 11, 2021

An issue was discovered in the Ultimate Member plugin before 2.1.12
for WordPress, aka Unauthenticated Privilege Escalation via User
Meta. An attacker could supply an array parameter for sensitive
metadata, such as the wp_capabilities user meta that defines a user's
CVE-2020-36155
role. During the registration process, submitted registration details
were passed to the update_profile function, and any metadata was
accepted, e.g., wp_capabilities[administrator] for Administrator
access.
for WordPress, aka Authenticated Privilege Escalation via Profile
CVE-2020-36156
Update. Any user with wp-admin access to the profile.php page could
supply the parameter um-role with a value set to any role (e.g.,


Administrator) during a profile update, and effectively escalate their
privileges.
Roles. Due to the lack of filtering on the role parameter that could be
CVE-2020-36157
supplied during the registration process, an attacker could supply the
role parameter with a WordPress capability (or any custom Ultimate
Member role) and effectively be granted those privileges.
Code Execution Vulnerability This
CVE ID is unique from
CVE-2021-26855 9.4
CVE-2021-26412, CVE-2021-26854,
CVE-2021-26857, CVE-2021-26858,
CVE-2021-27065, CVE-2021-27078.
Django contains a flaw that allows
MultiPartParser not properly
CVE-2021-28658 10
supplied via the name of an
uploaded file. With a specially
can have an unspecified impact.
April 4, 2021

SeaCMS contains a flaw in the /
admin_ip.php script that is
NO OFFICIAL CVE ID 'ip' and 'weburl' POST parameters 10
is not properly sanitized. This may
allow a remote attacker to execute
arbitrary commands.
LiteSpeed Web Server contains a
due to the /config/confMgr.php
script not properly sanitizing
NO OFFICIAL CVE ID input, specifically path traversal 9
style attacks (e.g. '../') supplied via
the 'path' POST parameter. With a
specially crafted request, an


PhreeBooks contains a flaw in /
index.php, when 'p' is set to
'bizuno/image/manager', that is
of the web service.
Dell EMC OpenManage Server
Administrator (OMSA) version 9.5
Microsoft Windows installations
with Distributed Web Server (DWS)
enabled configuration contains an
CVE-2021-21513 authentication bypass 10
vulnerability. A remote
unauthenticated attacker could
potentially exploit this
vulnerability to gain admin access
on the affected system.
Percona XtraBackup contains a
due to xbstream not properly
CVE-2020-29488 sanitizing input, specifically path 9.3
traversal style attacks (e.g. '../').
With a specially crafted archive
file, a context-dependent attacker
can write to arbitrary files.
Nokia NetAct contains a flaw in /
netact/sct that is triggered as file
CVE-2021-26597 accessible path. This may allow an 9
upload e.g. a JSP file and then
of the web service.
Patreon Plugin for WordPress
NO OFFICIAL CVE ID contains a flaw that allows 5


servePatronOnlyImage() function
not properly sanitizing input,
attacks (e.g. '../') supplied via the
'patron_only_image' parameter.
With a specially crafted request, a
remote attacker can disclose
arbitrary files.
PHP contains a backdoor in the
php_zlib_output_compression_startm()
function in ext/zlib/zlib.c. With a
NO OFFICIAL CVE ID specially crafted HTTP User-agent 10
header containing the string
'zerodium', a remote attacker can
March 28, 2021

Remote code execution is possible
with Apache Tomcat before 6.0.48,
7.x before 7.0.73, 8.x before 8.0.39,
8.5.x before 8.5.7, and 9.x before
9.0.0.M12 if
JmxRemoteLifecycleListener is
CVE-2016-8735 7.5
used and an attacker can reach
JMX ports. The issue exists
because this listener wasn't
updated for consistency with the
CVE-2016-3427 Oracle patch that
affected credential types.
In Jboss Application Server as
shipped with Red Hat Enterprise
Application Platform 5.2, it was
found that the doFilter method in
the ReadOnlyAccessFilter of the
CVE-2017-12149 7.5
HTTP Invoker does not restrict
classes for which it performs
deserialization and thus allowing
an attacker to execute arbitrary
code via crafted serialized data.
When running on Windows with
enableCmdLineArguments
CVE-2019-0232 enabled, the CGI Servlet in Apache 9.3
Tomcat 9.0.0.M1 to 9.0.17, 8.5.0 to
8.5.39 and 7.0.0 to 7.0.93 is


vulnerable to Remote Code
Execution due to a bug in the way
the JRE passes command line
arguments to Windows. The CGI
Servlet is disabled by default. The
CGI option
enableCmdLineArguments is
disable by default in Tomcat 9.0.x
(and will be disabled by default in
all versions in response to this
vulnerability). For a detailed
explanation of the JRE behaviour,
see Markus Wulftange's blog
(https://
codewhitesec.blogspot.com/
2016/02/java-and-command-line-
injections-in-windows.html) and
this archived MSDN blog (https://
web.archive.org/web/
20161228144344/https://
blogs.msdn.microsoft.com/
twistylittlepassagesallalike/
2011/04/23/everyone-quotes-
command-line-arguments-the-
wrong-way/).
arbitrary commands.
Profiling System For Human
Resource Management contains a
flaw in /ProfilingSystem/
add_file_query.php that is


path. This may allow a remote
March 21, 2021

Microsoft Exchange Server
certain input is not properly
validated when handling a
specially crafted email. This may
CVE-2020-16875 9
attacker to corrupt memory and
cause a denial of service or
potentially execute arbitrary code
in the context of the System user.
contains a flaw that is triggered
during the handling of cmdlet
CVE-2020-17132 9
arguments. This may allow an
An unauthenticated command-
execution vulnerability exists in
TerraMaster TOS through 4.2.06 via
CVE-2020-35665 10
shell metacharacters in the Event
parameter in include/
makecvs.php during CSV creation.

March 14, 2021

CVE-2020-9054 10
Attackers can use public NetTest
web service of Apache
CVE-2020-13951 5
OpenMeetings 4.0.0-5.0.0 to
organize denial of service attack.
The vSphere Client (HTML5)
contains an SSRF (Server Side
Request Forgery) vulnerability due
to improper validation of URLs in a
vCenter Server plugin. A malicious
actor with network access to port
443 may exploit this issue by
CVE-2021-21973 sending a POST request to vCenter 5
Server plugin leading to
information disclosure. This
affects: VMware vCenter Server
(7.x before 7.0 U1c, 6.7 before 6.7
U3l and 6.5 before 6.5 U3n) and
VMware Cloud Foundation (4.x
before 4.2 and 3.x before 3.10.1.2).
Code Execution Vulnerability This
CVE-2021-26855 9.4
CVE ID is unique from
CVE-2021-26412, CVE-2021-26854,


CVE-2021-26857, CVE-2021-26858,
CVE-2021-27065, CVE-2021-27078.
Online Ordering System contains a
flaw in /GPST/store/
initiateorder.php that is triggered
as file types and extensions for
allow a remote attacker to upload
e.g. a PHP file and then request it
in order to execute arbitrary code
service.
Textpattern CMS contains a flaw
in /textpattern/index.php that is
upload e.g. a file and then request
it in order to execute arbitrary
code with the privileges of the web
service.
March 7, 2021

Ignition before 2.5.2, as used in
Laravel and other products, allows
unauthenticated remote attackers
to execute arbitrary code because
CVE-2021-3129 of insecure usage of 7.5
file_get_contents() and
file_put_contents(). This is
exploitable on sites using debug
mode with Laravel before 8.4.2.
flaw in an unspecified plugin
related to vSphere Client (HTML5)
related to request handling
CVE-2021-21973 5
between a user and a server,
where the server can be induced
into performing unintended
actions (Server Side Request


Forgery aka SSRF). By sending a
specially crafted request to a
vCenter server plugin, the server
can be used to conduct host-based
attacks. This may allow a remote
attacker to bypass access
restrictions (e.g. host or network
ACLs), conduct port scanning of
internal networks, enumerate
internal hosts, or possibly invoke
additional protocols (e.g. Gopher,
TFTP) which may give additional
control over such requests.
Magento UPWARD-php version 1.1.4 (and earlier) is affected by a Path
traversal vulnerability in Magento UPWARD Connector version 1.1.2
(and earlier) due to the upload feature. An attacker could potentially
CVE-2021-21064 exploit this vulnerability to upload a malicious YAML file that can
contain instructions which allows reading arbitrary files from the
remote server. Access to the admin console is required for successful
exploitation.
February 28, 2021

SAP Solution Manager (User
Experience Monitoring), version-
7.2, due to Missing Authentication
Check does not perform any
CVE-2020-6207 10
authentication for a service
resulting in complete compromise
of all SMDAgents connected to the
Solution Manager.
In Joomla Component GMapFP Version J3.5 and J3.5free, an attacker
can access the upload function without authenticating to the
CVE-2020-23972 application and can also upload files which due to issues of
unrestricted file uploads which can be bypassed by changing the
content-type and name file too double extensions.
Drupal contains a flaw that is
triggered as filenames are not
properly sanitized for uploaded
files before being placed in a web-
accessible path. This may allow an
CVE-2020-13671 9
upload e.g. a specially crafted file
that will be interpreted as the
incorrect extension and served
with the wrong MIME type. The


attacker can then request the file
service.
The WooCommerce plugin before 4.7.0 for WordPress allows remote
CVE-2020-29156 attackers to view the status of arbitrary orders via the order_id
parameter in a fetch_order_status action.
February 21, 2021

Joomla! CMS contains an overflow
condition in the /
configuration.php script. The issue
is triggered as certain input is not
properly validated when passed to
NO OFFICIAL CVE ID the 'username' field. This may 10
allow a remote attacker to cause a
buffer overflow, resulting in a
denial of service or potentially
allowing the execution of arbitrary
code.
SAP Solution Manager (User
Experience Monitoring), version-
7.2, due to Missing Authentication
Check does not perform any
CVE-2020-6207 10
authentication for a service
resulting in complete compromise
of all SMDAgents connected to the
Solution Manager.
accessible path. This may allow an
CVE-2020-13671 9


service.
CSV Import and Export Plugin for
WordPress contains a flaw in /
admin/upload-handler.php that is
attacker to upload e.g. a file and
then request it in order to execute
of the web service.
Adning Advertising Plugin for
admin-ajax.php, when the 'action'
is set to '_ning_upload_image',
that is triggered as file types and
NO OFFICIAL CVE ID not properly validated before 10
Voting System contains a flaw in /
votesystem/admin/
voters_add.php that is triggered as
PhreeBooks contains a flaw in /
index.php, when 'p' is set to
'bizuno/image/manager', that is


of the web service.
Ruby on Rails contains a flaw that
allows a cross-site redirection
attack. This flaw exists because the
HostAuthorization.authorized()
function in actionpack/lib/
action_dispatch/middleware/
host_authorization.rb does not
properly handle allows hosts that
start with a leading '.'. This could
allow a context-dependent
attacker to create a specially
crafted link that, if followed, would
redirect a victim from the intended
CVE-2021-22881 legitimate web site to an arbitrary 0
web site of the attacker's
choosing. Such attacks are useful
as the crafted URL initially appears
to be a web page of a trusted site.
This could be leveraged to direct
an unsuspecting user to a web
page containing attacks that target
client-side software such as a web
browser or document rendering
programs, as well as phishing
attacks that mimic the legitimate
site but send user-supplied
information to the attacker.
February 14, 2021

Jenkins versions 2.56 and earlier
as well as 2.46.1 LTS and earlier are
vulnerable to an unauthenticated
remote code execution. An
execution vulnerability allowed
CVE-2017-1000353 7.5
attackers to transfer a serialized
Java `SignedObject` object to the
Jenkins CLI, that would be
deserialized using a new
ÒbjectInputStream`, bypassing
the existing blacklist-based


protection mechanism. We're
fixing this issue by adding
`SignedObject` to the blacklist.
We're also backporting the new
HTTP CLI protocol from Jenkins
2.54 to LTS 2.46.2, and deprecating
the remoting-based (i.e. Java
serialization) CLI protocol,
disabling it by default.
Xstream API versions up to 1.4.6
and version 1.4.10, if the security
framework has not been
initialized, may allow a remote
CVE-2013-7285 attacker to run arbitrary shell 7.5
commands by manipulating the
processed input stream when
unmarshaling XML or any
supported format. e.g. JSON.
It was found that xstream API
version 1.4.10 before 1.4.11
introduced a regression for a
previous deserialization flaw. If the
security framework has not been
CVE-2019-10173 initialized, it may allow a remote 7.5
attacker to run arbitrary shell
commands when unmarshalling
XML or any supported format. e.g.
JSON. (regression of
CVE-2013-7285)
FasterXML contains a flaw in
jackson-databind jsontype/impl/
SubTypeValidator.java related to
the CXF JAX-RS implemtation that
NO OFFICIAL CVE ID is triggered as user-supplied 10
JavaScript content is insecurely
CVE-2019-16662 ajaxServerSettingsChk.php 10
because the rootUname
parameter is passed to the exec
function without filtering, which
can lead to command execution.


CVE-2019-16663 search.crud.php because the 9
catCommand parameter is passed
to the exec function without
filtering, which can lead to
command execution.
JYaml through 1.3 allows remote
code execution during
deserialization of a malicious
CVE-2020-8441 7.5
payload through the load()
function. NOTE: this is a
discontinued product.
QiHang Media Web (QH.aspx)
Digital Signage contains a flaw
of the web service.
QiHang Media Web (QH.aspx)
Digital Signage contains a flaw
the /QH.aspx script not properly
sanitizing input, specifically
absolute paths or path traversal
NO OFFICIAL CVE ID 6.4
the 'data' POST parameter or path
supplied via the 'filename' POST
delete arbitrary files via the 'data'
parameter and disclose arbitrary
files via the 'filename' parameter.
FF4J Web contains a flaw in the /
ff4j-web-console/home script that
NO OFFICIAL CVE ID is triggered as input passed to a 9
specially crafted JAR file is
insecurely deserialized. This may


attacker to upload a configuration
file and execute arbitrary code.
An unrestricted file upload issue in HorizontCMS through 1.0.0-beta
allows an authenticated remote attacker (with access to the
FileManager) to upload and execute arbitrary PHP code by uploading
a PHP payload, and then using the FileManager's rename function to
CVE-2020-27387 provide the payload (which will receive a random name on the server)
with the PHP extension, and finally executing the PHP file via an HTTP
GET request to /storage/<php_file_name>. NOTE: the vendor has
patched this while leaving the version number at 1.0.0-beta.</
php_file_name>
commands.
Apache Unomi contains a flaw that
may allow conditions to use OGNL
and MVEL scripting to call static
Java classes from the JDK. This
CVE-2020-13942 10
permission level of the running
Java process.
org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.
oadd.org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS.
CVE-2020-36181 before 2.9.10.8 mishandles the 6.8
interaction between serialization


org.apache.tomcat.dbcp.dbcp.cpdsadapter.DriverAdapterCPDS.
org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS.
org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool.
org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource.
org.apache.tomcat.dbcp.dbcp2.datasources.SharedPoolDataSource.
org.apache.tomcat.dbcp.dbcp.datasources.PerUserPoolDataSource.
org.apache.tomcat.dbcp.dbcp.datasources.SharedPoolDataSource.
com.newrelic.agent.deps.ch.qos.logback.core.db.JNDIConnectionSource.
com.newrelic.agent.deps.ch.qos.logback.core.db.DriverManagerConnectionSource.
Oracle WebLogic Server contains
an unspecified flaw related to the
CVE-2021-2109 Console component. This may 9


arbitrary code. No further details
have been provided by the vendor.
LiteSpeed Web Server contains a
due to the /config/confMgr.php
NO OFFICIAL CVE ID input, specifically path traversal 9
the 'path' POST parameter. With a
specially crafted request, an
February 7, 2021

In Apache httpd before 2.2.34 and
2.4.x before 2.4.27, the value
placeholder in
[Proxy-]Authorization headers of
type 'Digest' was not initialized or
reset before or between successive
key=value assignments by
mod_auth_digest. Providing an
CVE-2017-9788 6.4
initial key with no '=' assignment
could reflect the stale value of
uninitialized pool memory used by
the prior request, leading to
leakage of potentially confidential
information, and a segfault in
other cases resulting in denial of
service.
modules/bamegamenu/
parameter.
GMapFP Google Map Component
for Joomla! contains a flaw that
NO OFFICIAL CVE ID allows a remote attacker to 10
execute arbitrary PHP code. This
flaw exists because the


upload_image task in index.php
script does not properly verify or
sanitize user-uploaded files. By
uploading a .php file with multiple
file extensions (e.g. myfile.php.gif),
the upload will bypass the sanity
check restricting file uploads to
certain designated file types. Once
uploaded, the remote system will
place the file in a web-accessible
path. Making a direct request to
the uploaded file will allow the
attacker to execute the script with
the privileges of the web server.
PHPKB contains a flaw that is
triggered during the handling of a
specially crafted HTTP GET request
from a malicious server to the /
CVE-2020-11579 4.3
admin/include/configuration.php
script. This may allow a context-
dependent attacker to disclose
arbitrary files.
ReQuest Serious Play F3 Media
Server contains a flaw that is
triggered as direct requests to the
message_log page are not
properly restricted. This may allow
a remote attacker to disclose
debug log information, which
includes credential information.
ReQuest Serious Play F3 Media
Server contains a flaw in /tools/
upload.html that is triggered as
e.g. a PHP file and then request it
service.


Online Students Management
System contains a flaw in /
studentrecord/my-profile.php that
is triggered as file types and
of the web service.
OpenEMR 5.0.1 allows an authenticated attacker to upload and
CVE-2020-19364
execute malicious PHP scripts through /controller.php.
CVE-2020-23160 9
root privileges.
OpenLiteSpeed contains a flaw
the /view/confMgr.php script not
NO OFFICIAL CVE ID specifically encoded path traversal 4
style attacks (e.g. '..%2f') supplied
via the 'path' POST parameter.
With a specially crafted request, an
disclose arbitrary files.
January 31, 2021

CVE-2020-13671 accessible path. This may allow an 9


service.
CVE-2020-35665 10
Ignition before 2.5.2, as used in Laravel and other products, allows
unauthenticated remote attackers to execute arbitrary code because
CVE-2021-3129
of insecure usage of file_get_contents() and file_put_contents(). This
is exploitable on sites using debug mode with Laravel before 8.4.2.
Oracle WebLogic Server contains
an unspecified flaw related to the
Console component. This may
CVE-2021-2109 allow an authenticated remote 9
arbitrary code. No further details
have been provided by the vendor.
ONLYOFFICE Document Server
uploadImageFile() function in
DocService/sources/
fileuploaderservice.js not properly
CVE-2021-3199 10
traversal style attacks (e.g. '../').
With a specially crafted request to
the /upload endpoint, a remote
attacker can overwrite arbitrary
files with privileges of the web
server.
Selea Targa IP Cameras contain a
due to the /cgi-bin/get_file.php
NO OFFICIAL CVE ID input, specifically encoded path 5
traversal style attacks (e.g. '..%2f')
supplied via the 'files_list' POST


CVE-2020-23160 9
root privileges.
Pyrescom Termod4 contains a
local file inclusion (LFI) flaw due to
the /cgi-bin/cfg.cgi script not
properly sanitizing user input,
attacks (e.g. '../../') supplied to the
URL. With a specially crafted
CVE-2020-23161 request, an authenticated remote 7.6
attacker can include arbitrary files
from the targeted host. This may
allow disclosing file contents or
executing files like PHP scripts.
Such attacks are limited due to the
script only calling files already on
the target host.
OpenLiteSpeed contains a flaw
the /view/confMgr.php script not
NO OFFICIAL CVE ID specifically encoded path traversal 4
style attacks (e.g. '..%2f') supplied
via the 'path' POST parameter.
With a specially crafted request, an
January 24, 2021

CVE-2020-35665 10
Dup Scout Enterprise contains an
NO OFFICIAL CVE ID overflow condition in the / 10
online_registration script. The


issue is triggered as certain input is
not properly validated when
passed to the 'customer_name'
and 'unlock_key' POST
parameters. This may allow a
remote attacker to cause a buffer
arbitrary commands.
Meta. An attacker could supply an array parameter for sensitive
metadata, such as the wp_capabilities user meta that defines a user's
CVE-2020-36155
role. During the registration process, submitted registration details
were passed to the update_profile function, and any metadata was
accepted, e.g., wp_capabilities[administrator] for Administrator
access.
for WordPress, aka Authenticated Privilege Escalation via Profile
Update. Any user with wp-admin access to the profile.php page could
CVE-2020-36156
supply the parameter um-role with a value set to any role (e.g.,
Administrator) during a profile update, and effectively escalate their
privileges.
Roles. Due to the lack of filtering on the role parameter that could be
CVE-2020-36157
supplied during the registration process, an attacker could supply the
role parameter with a WordPress capability (or any custom Ultimate
Member role) and effectively be granted those privileges.
EGavilan Media Resumes
Management And Job Application
Website contains a flaw in the
resume upload feature that is
NO OFFICIAL CVE ID extensions for uploaded files are 10


Gila CMS contains a flaw that is
triggered as input passed via HTTP
headers is not properly sanitized.
to use a specially crafted request
OpenCATS contains a flaw in the
DataGrid::get() function in lib/
DataGrid.php that is triggered as
input to the
'parametersactivity:ActivityDataGrid'
CVE-2021-25294 9
GET parameter is insecurely
deserialized. This may allow an
inject PHP objects and execute
arbitrary code.
January 17, 2021

Trend Micro InterScan Messaging
Security Virtual Appliance (IMSVA)
contains a flaw related to request
handling between a user and a
server, where the server can be
induced into performing
unintended actions (Server Side
Request Forgery aka SSRF). By
sending a specially crafted request
to the /widget/
proxy_controller.php script, the
CVE-2020-27018 4
server can be used to conduct
host-based attacks. This may allow
to bypass access restrictions (e.g.
host or network ACLs), conduct
port scanning of internal
networks, enumerate internal
hosts, or possibly invoke
additional protocols (e.g. Gopher,
TFTP) which may give additional
control over such requests.
CVE-2020-28579 Security Virtual Appliance (IWSVA) 6.5
contains an overflow condition in


the MailNotification() function in
libuiauutil.so. The issue is
triggered as certain input is not
the 'sender_addr' parameter via /
urlf_reclassifyurl.jsp. This may
attacker to cause a stack-based
code.
Ultimate Member Plugin for
WordPress contains a flaw in the
update_profile() function that is
NO OFFICIAL CVE ID 'wp_capabilities' parameter and to 10
user roles is not properly sanitized.
to gain admin permissions on a
newly created account.
SEOmatic Plugin for Craft CMS
the evaluateDynamicContent()
method is not disabled for
Yii::Base::View objects. This may
allow a remote attacker to create a
CVE-2020-24961 10
new Yii::Base::View object which
directly calls the
evaluateDynamicContent()
method, allowing them to bypass
protection mechanisms and
CSV Import and Export Plugin for
admin/upload-handler.php that is
of the web service.
Adning Advertising Plugin for


admin-ajax.php, when the 'action'
is set to '_ning_upload_image',
Apache Flink 1.5.1 introduced a REST handler that allows you to write
an uploaded file to an arbitrary location on the local file system,
through a maliciously modified HTTP HEADER. The files can be written
CVE-2020-17518 to any location accessible by Flink 1.5.1. All users should upgrade to
Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed. The issue
was fixed in commit a5264a6f41524afe8ceadf1d8ddc8c80f323ebc4
from apache/flink:master.
A change introduced in Apache Flink 1.11.0 (and released in 1.11.1 and
1.11.2 as well) allows attackers to read any file on the local filesystem
of the JobManager through the REST interface of the JobManager
process. Access is restricted to files accessible by the JobManager
CVE-2020-17519
process. All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink
instance(s) are exposed. The issue was fixed in commit
b561010b0ee741543c3953306037f00d7a9f0801 from apache/
flink:master.
January 10, 2021

User Friendly SVN contains a flaw
in the lasthundredrequestAction()
function that is triggered as input
passed to the 'Start' and 'End'
CVE-2020-17363 9
fields are not properly sanitized.
This may allow an authenticated
arbitrary OS commands.
XStream contains a flaw that is
triggered when deserializing
com.sun.xml.ws.util.ReadAllStream$FileStream
CVE-2020-26259 classes from user-supplied XML 4.3
input. This may allow a context-
dependent attacker to delete
arbitrary files.
Contact Form 7 plugin for
CVE-2020-35489 10


includes/formatting.php that is
validated against an improperly
formatted regular expression
accessible path. This may allow a
file and then request it in order to
CVE-2020-35665 10
SolarWinds Orion Platform
contains a flaw in the API that is
triggered as requests are not
properly handled when appending
CVE-2020-10148 certain strings to the PathInfo 10
bypass authentication and execute
arbitrary API commands.
Ultimate Member Plugin for
WordPress contains a flaw in the
update_profile() function that is
NO OFFICIAL CVE ID 'wp_capabilities' parameter and to 10
user roles is not properly sanitized.
to gain admin permissions on a
newly created account.
January 3, 2021

Zoho ManageEngine Desktop Central 10 allows remote code execution
because of deserialization of untrusted data in getChartImage in the
CVE-2020-10189
FileStorage class. This is related to the CewolfServlet and
MDMLogUploaderServlet servlets.


Furukawa Electric ConsciusMAP
input passed to the
CVE-2020-12133 'javax.faces.ViewState' parameter 10
is insecurely deserialized. This
certain input is not properly
validated when handling a
specially crafted email. This may
CVE-2020-16875 9
attacker to corrupt memory and
cause a denial of service or
potentially execute arbitrary code
in the context of the System user.
CVE-2020-28579 the 'sender_addr' parameter via / 6.5
code.
CVE-2020-35665 10
bloofoxCMS contains a flaw in
admin/index.php that is triggered
as file types and extensions for
CVE-2020-35709 validated before being placed in a 9
e.g. a PHP file leveraging path


SolarWinds Orion Platform
contains a flaw in the API that is
triggered as requests are not
properly handled when appending
CVE-2020-10148 certain strings to the PathInfo 10
bypass authentication and execute
arbitrary API commands.
December 13, 2020

In Pulse Secure Pulse Connect
Secure (PCS) 8.2 before 8.2R12.1,
8.3 before 8.3R7.1, and 9.0 before
CVE-2019-11510 9.0R3.4, an unauthenticated 7.5
remote attacker can send a
specially crafted URI to perform an
arbitrary file reading vulnerability .
XStream contains a flaw in the
XStream::setupSecurity() function
in XStream.java that is triggered as
javax.imageio.ImageIO$ContainsFilter
CVE-2020-26217 9.3
objects are not properly handled
when deserializing XML data. This
may allow a context-dependent
attacker to execute arbitrary code.
the
CVE-2020-28578 7.5
Java_com_trend_iwss_gui_IWSSJNI_DecryptPasswd()
function in libuiauutil.so. The issue
is triggered as certain input is not


the 'password' parameter via /
rest/windows_client_status. This
cause a stack-based buffer
CVE-2020-28579 the 'sender_addr' parameter via / 6.5
code.
commands.
Apache Unomi contains a flaw that
may allow conditions to use OGNL
and MVEL scripting to call static
Java classes from the JDK. This
CVE-2020-13942 10
permission level of the running
Java process.
OpenCRX contains a flaw in the /
PasswordResetConfirm.jsp script
CVE-2020-7378 4
the 'token' parameter is not


properly validated. This may allow
to change the password for any
users, including the admin-
standard.
December 6, 2020

The MethodClosure class in
runtime/MethodClosure.java in
Apache Groovy 1.7.0 through 2.4.3
arbitrary code or cause a denial of
service via a crafted serialized
object.
modules/bamegamenu/
parameter.
ThinkPHP before 3.2.4, as used in
Open Source BMS v1.1.1 and other
products, allows Remote
CVE-2019-9082 Command Execution via public//? 10
s=index/\think\app/
invokefunction&function=call_user_func_array&vars[0]=system&vars[1]
[]= followed by the command.
6.0.0 to 6.0.4, 5.6.0 to 5.6.8 and
CVE-2018-13382 5
Netsweeper through 6.4.3 allows unauthenticated remote code
execution because webadmin/tools/unixlogin.php (with certain
CVE-2020-13167
Referer headers) launches a command line with client-supplied
parameters, and allows injection of shell metacharacters.
BigTree CMS contains a flaw in
NO OFFICIAL CVE ID the /index.php/admin/developer/ 9
settings/create/ script that is


'settings' POST parameter is not
properly sanitized. This may allow
Joomla! contains a flaw that
mod_random_image not properly
supplied via the 'folder'
have an unspecified impact.


Account Settings
The account settings let you define different attributes of the account, such as two-factor authentication, account
notification emails, and weekly report settings. You can also define Origin Lock settings.
In this topic:
• Access Account Settings

• Account Details
• Data Management
• Origin Lock
• DDoS Protection for Networks and Individual IPs - Sub Accounts
Access Account Settings
Log in to your my.imperva.com account.
2. On the sidebar, click Account Management > Account Settings.

Account Details
This section contains all account-level configuration options.
Forces all users of the account to configure two

factor authentication for their logins. Users that
have not configured two factor authentication will
be required to do so before logging in. (Available for
Require users to use two factor authentication
account admins only.)
Note: Two factor authentication is not activated if

the user logs in with SSO.
Enables users to receive a passcode for two factor

authentication via email. If this option is not
Allow Two Factor Authentication through E-mail
selected, users can choose to receive a passcode via
text message or the Google Authenticator app only.
Limits access to the Cloud Security Console to
Allow login from the following IP addresses only specific IP addresses (e.g., the IP addresses of the
company’s offices).
Determines the time zone for the account and all
sites under it. For example, all dashboards and
Time zone
event logs for sites will show events in accordance
with the configured account time zone.
Shows the account's support level (managed/
Support level
standard).

In compliance with PCI-DSS requirements to disable

the use of TLS 1.0, and due to known vulnerabilities
in TLS 1.1, Imperva has defined TLS 1.2 as the
default minimum supported version for connectivity
between clients (visitors) and Imperva.
This option enables you to set support for TLS

versions earlier than 1.2 on a per site basis.
Enabling this option opens the TLS versions setting

for sites in your account. After you enable this
Support all TLS versions option, enable the Support All TLS Versions option
for each site that you want to support the earlier
TLS versions. For details, see Website General
Settings.
To remain PCI-compliant, do not enable this option.

For more details, see Web Protection - SSL/TLS.
Note: You cannot disable this option if it is enabled

for any of the account's sites. First disable the
Support all TLS versions option for each site in the
site's General Settings page.
Imperva produces a weekly report for every account

that chooses to receive it. The weekly report
contains general information on the account as well
as all sites under the account.
Weekly reports are generated on each Monday, and

contain comparative information between last week
and the previous week. Due to this design, a new
account can only receive its first Weekly Report two
Subscribe to weekly reports weeks after the account is created.
The weekly report is sent to all email addresses

defined in the Account and Website > Account
Notifications recipient list. For details, see
Notification Settings.
The email you receive contains a link for

downloading the report in PDF format. Anyone with
the link can download the report. It does not require
a user or login to Imperva.

The report can also be reviewed in retrospect or

generated on demand, using the Weekly account
report option on the Account Settings page.
Accounts with sub accounts: You can subscribe to

weekly reports for the parent account, and also for
any sub account, via the account/sub account's
Account Settings page.
• The statistics presented in the report for a

parent account include all of the sub accounts.
• A report for a sub account includes only the

statistics for the specific sub account.
View the last weekly report or generate a new one.
Generate and send now: Generates a new report and

Weekly account report sends to the account email addresses.
View: Displays the last report generated by the

system.
Enables HTTP/2.0 support for traffic between end-

user (visitor) and Imperva for all new SSL sites that
are added after this setting is enabled.
Allows supporting browsers to take advantage of the

performance enhancements provided by HTTP/2 for
your website. Non-supporting browsers can connect
via HTTP/1.0 or HTTP/1.1.
Enable HTTP/2 from end-user to Imperva for newly
created SSL sites Note:
• HTTP/2 support is available only for sites that

have SSL support.
• You can enable or disable HTTP/2 support at
the site level for any individual site. For
details, see Delivery Settings.
See also: HTTP/2 FAQ
Enables HTTP/2 support for traffic between Imperva

Enable HTTP/2 to origin for newly created SSL sites
and your origin server for all new SSL sites that are
added after this setting is enabled.

Note:
• To turn on this option, you must first turn on

the Enable HTTP/2 from end-user to
Imperva for newly created sites option.
• You can enable or disable HTTP/2 support at
the site level for any individual site. For
details, see Delivery Settings.
• If this option is enabled for a site and your

origin does not support HTTP/2, we retry the
connection using HTTP/1.1. In this case, logs
will show the error
REQ_ORIGIN_DOESNT_SUPPORT_H2. If your
origin does not support HTTP/2, it is
recommended to turn off this option.
Enables HTTP Strict Transport Security for all new

Enable HSTS for newly created SSL sites SSL sites added after this setting is enabled. For
more details, see Web Protection - General Settings.
Adds the wildcard SAN to the Imperva SSL certificate

instead of the full domain SAN.
Example: For www.example.com, the wildcard SAN

is *.example.com and the full domain SAN is
www.example.com.
Options include: True, False, Default (the option is

set according to the default option for the account
plan)
Include wildcard SAN in Imperva's certificate for Using a wildcard SAN enables you to add
newly created SSL sites subdomains, such as sub.example.com, without the
need for a certificate change and revalidation.
Note: Typically, when your site's Imperva-generated

certificate needs to be renewed, the process is
completed automatically by Imperva. If you are
using a wildcard SAN, automated validation can only
be completed for a subdomain if the domain (e.g.
example.com) is also protected by Imperva.
Otherwise, you will receive an email notification
from Imperva requiring you to revalidate ownership
of your domain.


Include naked domain SAN in Imperva's certificate
for newly created WWW sites Example: For www.example.com, the SAN
example.com is added to the certificate in addition
to the wildcard or full domain SAN.
Enables you to add a unique identifier to correlate

Reference ID an object in our service, such as a protected website,
with an object on the customer side.
Enables you to create up to 20,000 simplified
Allow sites to add a large number of redirect rules redirect rules per site in your account. For details,
see Create Simplified Redirect Rules.
Created On The date the account was created.
Data Management
Select a region for storing your Imperva data.
This option sets the default data storage region for

new sites created in your account and for network
layer data, such as network layer 3/4 headers, which
contain IP addresses.
Default data storage region
Available regions include APAC, AU, EU, and US.
You can view or change the region for any site. For
detail, see Website General Settings.
Overrides the default setting defined by the Default

data storage region option and enables the system
Override site event data region by origin geolocation
to automatically select the WAF event storage
location for each website independently.
Permanently delete the security and access event

data stored for the sites in your account. (Available
for account admins only.)
Delete sites’ security and access event data After you click Delete and then confirm the deletion,
the process begins. Data is permanently deleted
within 48 hours.

Origin Lock
Origin Lock associates a specific IP or certificate fingerprint with your account to prevent other accounts on the
Imperva service from setting up sites that forward traffic to your origin server.
How does it work?
The Imperva cloud service is positioned between the end users (visitors) and your origin server. In this topology, the
origin server IP might be inadvertently accessed by other tenants hosted on the same service.
If tenants on the service configure a site to point to an origin server belonging to another account, they become the
first hop for traffic that arrives from the visitor on its way to the original IP (incoming traffic). This could allow other
application traffic to reach the origin server.
Imperva Origin Lock adds an extra layer of security by associating IP addresses with one specific account. This feature
"locks" the IPs of a given account and prevents them from being used by others.
If your IP or certificate is only used by your account, it is highly recommended that you enable Origin Lock.
Note: If you are using a cloud service provider that issues ephemeral or temporary public IP addresses for your virtual
compute workloads and want to use this feature, you must have your own registered PA or PI IP space allocation.
To enable Origin Lock:
Contact our support team at https://support.imperva.com. The support team will let you know once the restriction is
set.
When setup is complete, the list of locked IPs/fingerprints is displayed in the Origin Lock table.
Note: Fingerprints are listed without spaces. To search the table for a specific fingerprint, first remove all spaces.
DDoS Protection for Networks and Individual IPs - Sub Accounts
These options are available in accounts subscribed to at least one of the Network Security DDoS Protection services.
Enables the viewing and configuration of DDoS

Enable protection and monitoring settings for sub
Protection for Networks/IPs protection and
accounts
monitoring settings in the account's sub accounts.
Enables the creation of connections between

Imperva and your origin network in sub accounts.
Enable connectivity settings for sub accounts Connections in a sub account are then used only in
the specific sub account in which they are created.
Connections cannot be shared between the parent
account and its sub accounts.

If this option is not enabled, connections can be

created in the parent account only and shared by
the parent and sub accounts.
This option is available only when the Enable

protection and monitoring settings for sub
accounts option is turned on.
Tip: Click in any section of the Account Settings page to download a list in .csv format.

Manage Account Resources

Group your resources to simplify the management of enterprise accounts and manage user access.
In this topic:
• Overview
• Sample flow
• Manage sub accounts
• Manage sub account users and permissions
Overview
Organizations often have multiple departments or teams that require access to the Imperva account. An organization
may be subdivided based on functional activities, product lines, processes, or geographical location. Each
department may be required to perform a different set of actions, and require different levels of access rights.
Sub accounts enable you to group and manage resources together based on department, function, or other business
criteria, and assign users to only those resources they are responsible for managing or require access to. For example,
a security officer in a large enterprise company can group sites together based on business department, to be
accessed only by the respective team members responsible for those sites.
You can manage resources in a sub account as a group, and set the following at the sub account level:
• Account Users
• Account Notifications
• Logs
• DNS Protection
Sub accounts are intended to be used to manage resources belonging to the same organizational entity as the parent
account.
Pricing plan and billing data are presented in the parent account only. The parent account's Subscription page
reflects usage of resources from the parent account and all sub accounts.
Sample flow
Create sub accounts. (Account Admin) Create a sub account for each department or group that needs to access the
Imperva account.

Create account users. (Account Admin) Add users to the account.
Add users to sub accounts. In each sub account, add users as needed and configure the appropriate permissions for
each user.
Add or move sites. Add new sites or move existing resources to each sub account as required.
The Account Admin or any user with the appropriate permissions can add users and resources to a sub account.
Example: For a worldwide organization with many brands:
1. Create a sub account for each brand.

2. Create users in the parent account.
3. Grant permissions to manage sub accounts to the security and network engineers.
4. Add each brand's sites/domains to the relevant sub account.
5. Add the application or site owners as users to the relevant sub accounts and configure their permissions.
Manage sub accounts
What do you want to do? Details
To open the Sub Accounts page:
Log in to your account in the Imperva Cloud Security

Console.
1. On the top menu bar, click Account > Account

Management.
View and manage sub accounts 2. On the sidebar, click Sub Accounts.
Tip: To navigate to the parent account from a sub

account, click the breadcrumbs at the top of the
page.
On the Sub Accounts page, click Add Sub Account

Add a sub account
and enter the required details.
On the Sub Accounts page, select the checkbox next

Delete a sub account to the sub account you want to delete, and click the
Delete button.


You cannot delete a sub account that contains sites.
On the Sub Accounts page, you can view Always-on

View bandwidth usage per sub account and On-demand bandwidth usage for each sub
account.
1. On the Sub Accounts page, click the name of

the relevant sub account.
2. In the sub account, open the Websites page
Add a new site to a sub account and click Add Site.
3. Follow the onscreen instructions to onboard
the site. For more details, see Onboarding a
Site – Web Protection and CDN.
You can move a site from the parent account to a

sub account (or vice versa), or from one sub account
to another.
1. On the Websites page, locate the site you

want to move.
2. Under the More column, select Move Site.
3. Enter the name or number of the account you
want to move the site to, and press Enter.
Note:
• You may be required to update DNS and/or

SSL settings for the site. If so, a message will
display informing you of the required changes:
Move an existing site to a sub account
• DNS: If DNS updates are required,
update the domain’s ‘A’ records
according to the information on the
Websites > General Settings page.
• SSL: If domain revalidation is

required by the CA, follow the
instructions on the Websites page >
Status column to complete the
process. When CA approval is
received, the site will automatically
be moved to the new account.
As with the process of onboarding a site, no

downtime is expected.
• Policies: When you move a site:


• Policies that are already applied to
the site in the source account are still
applied. It is recommended to
remove these policies from the site
before moving it.
• Policies set as default in the
destination account are
automatically applied to the site
when it is moved.
For more details on policies, see Create and

Manage Policies.
Manage sub account users and permissions

Note: For most accounts, permissions are now managed using roles. For details, see Manage Roles and Permissions.
For details on creating users, see Account Users.
The Manage account sub accounts permission

enables the user to manage all sub accounts in the
account.
1. In the parent account, open the Account

Users page.
2. Locate the user you want to grant permissions
Grant a user permission to manage an account's sub to, and click the row to open the Settings
accounts panel.
3. Expand the Permissions section and select
Manage account sub accounts.
This permission cannot be granted to a user who is a

member of a sub account. You must remove the user
from all sub accounts before assigning this
permission.
You create users in the parent account and then add

them to sub accounts according to your needs.
Add users to a sub account To add users to a sub account: In the sub account,
open the Account Users page. Click Add User and
select a user from the list.
• You can add a user to multiple sub accounts.


• To grant the user view-only access to the sub
account, add the user without selecting any
permissions.
Note: A user who has Manage account sub accounts

permissions in the parent account cannot and does
not need to be added as a sub account user.
You can grant a user different permissions in each

sub account.
1. In the sub account, open the Account Users

page.
2. Locate the user you want to grant permissions
Assign user permissions in a sub account
to, and click the row to open the Settings
panel.
3. Expand the Permissions section and select
the relevant options.
A sub account does not have its own account admin.
Removing a user from a sub account does not delete

the user from the parent account.
1. In the sub account, open the Account Users

page.
2. Locate the user you want to remove, and click
Remove a user from a sub account the row to open the Settings panel.
3. Expand the Actions section and click Delete.
This removes the user from the sub account
only.
Deleting a user from the parent account removes the

user from all sub accounts.
See also:
• Sub Accounts Page
• DDoS Protection for Networks and IPs: Sub Account Support

Sub Accounts Page

View a list of your sub accounts configured in Imperva. Drill down into any sub account for more details and
configuration settings.
Note: For more details on grouping your resources into sub accounts to simplify management of and manage user
access, see Manage Account Resources.
To open the Sub Accounts page, log in to your account in the Imperva Cloud Security Console
• The Sub Accounts page is displayed by default for accounts that have sub accounts.
• Alternatively, on the top menu bar, click Account > Account Management. On the sidebar, click Account
Management > Sub Accounts.
The following details are displayed for each sub account.
Field Description
The name of the sub account. Click the name to drill
Name down into the sub account details, view dashboards,
and configure settings.
The 95th percentile calculation of always-on

Always-on BW bandwidth used by the sub account in the last 30
days.
The 95th percentile calculation of bandwidth used

On-demand BW by the sub account in the last 30 days for DDoS
Protection for Networks "on-demand" service.
The number of websites configured in the sub
Active Sites
account.
Creation Date The date the sub account was created.
The number of protected IP addresses configured in

the sub account.
Protected IPs
Available for: Accounts subscribed to DDoS
Protection for Individual IPs.
The number of protected network ranges configured

in the sub account.
Protected Networks
Protection for Networks.

Field Description
The number of flow exporters configured in the sub

account.
Flow Exporters
Protection for Networks using the flow-based
monitoring option.
See also:
• Manage Account Resources

Notifications
This topic provides an overview of email notifications sent to you by Imperva, including real-time threat alerts, and
DDoS Protection for Networks status notifications. Learn how you can sign up for additional alerts, reports, and
updates.
Note: We are currently rolling out the new Notification Settings page. If the new page is enabled in your account,
email addresses for notifications are managed there and not on the Account Settings page, as described below. For
more information, see Notification Settings.
In this topic:
• Overview
• Notification list
• Imperva Status Page Notifications
• Subscribe to release notes
Overview
Imperva sends email notifications about activity in your account and sites. Make sure to set up your account's email
addresses to receive notifications and reports.
Account notification list: The email addresses that are defined in the Cloud Security Console under Account >
Account Management > Account Settings > Account Details > E-mails for Notifications.
Note: The E-mails for Notifications field is grayed-out for users whose notifications are now managed in the
Notification Settings page.
Account escalation notification list: The email addresses and phone numbers that are displayed in Edge > Network
Protection > Flow Monitoring Settings > Attack Notifications. If you are using the DDoS Protection for Networks
service in on-demand mode, you can configure the escalation notification list. For details, see Flow Monitoring
Settings.
Email sent to users by the Imperva management system is TLS encrypted and digitally signed.
Notification list
The following notifications are sent by the Imperva management system:
Notification emails are

Activity Details Setting level
sent to:
Account and billing
(Automatic) Account notification list Per account
notifications
(Optional) Receive a
Weekly reports Account notification list Per account
weekly report with
general information on


sent to:
your account and all of its
sites.
For details, see Account

Settings.
(Optional) Receive
notifications about
threats that were
detected on your site,
such as Layer 7
(application layer) DDoS
and backdoor threats.
Website protection: Real-
Events are aggregated Account notification list Per site
time threat alerts
and a notification email is
sent at 5-minute
intervals.
For more details, see

Website Notification
Settings.
(Optional) Sign up to
receive a weekly,
monthly, or quarterly
report about changes to
your security rule
Website protection: PCI-
configuration and Account notification list Per site
compliance reports
compliance with PCI 6.6
requirements.
For details, see Website

(Optional) When adding

or editing a security rule,
you can select the option
to send an email
Website protection:
notification whenever the Account notification list Per rule
Security rule alerts
rule is triggered.
For details, see Create

Rules.


sent to:
(Optional) Select the

failure scenarios that you
want to produce alarm
Website protection: Load messages.
Account notification list Per site
Balancing alerts
For details, see Load
Balancing Monitoring
Settings.
Website protection: DDoS (Automatic) Start/stop of

Account notification list Per account
network layer alerts an attack
DDoS Protection for (Automatic) Start/stop of
Networks/IPs: DDoS Layer an attack (excluding Flow Account notification list Per account
3/4 alerts Monitoring alerts).
DDoS Protection for (Automatic) Status of the
Networks/IPs: Connection GRE, cross-connect, or Account notification list Per account
up/down alerts ECX connection.
DDoS Protection for
Networks/IPs: Protected (Automatic) Account notification list Per account
IP up/down status alerts
Emails:
• Account escalation
notification list
(Automatic) Alerts are • Account
Network monitoring:
sent based on receipt and notification list
NetFlow start/stop/bad Per account
viability of NetFlow
data alerts
packets. SMS: Text message sent
to phone numbers in the
account escalation
notification list.
Emails:
(Automatic) Alerts are
sent when a DDoS attack • Account escalation
has started, based on the notification list
detection policy • Account
Network monitoring:
configured for your notification list Per account
DDoS attack detected
network.
SMS: Text message sent
A DDoS start event is to phone numbers in the
generated when Imperva account escalation
has started mitigation notification list.


sent to:
Phone call: If you are an
on-demand customer and
and an attack has been have asked that we get
blocked for 5 minutes. your approval before
switching the connection
over to Imperva, you will
be contacted by phone at
the start of an attack.
(Automatic) Alerts are

sent when a DDoS attack
Emails:
has started and network
traffic is diverted to
• Account escalation
Imperva.
notification list
• Account
Applies to customers
Network monitoring: notification list
using the DDoS Per account
Network traffic diverted
Protection for Networks
SMS: Text message sent
on-demand mode who
to phone numbers in the
have selected the option
account escalation
to allow Imperva to
notification list.
automatically route traffic
through the Imperva
network.
Imperva Status Page Notifications

Visit the Imperva status page for maintenance information and system status. You can also subscribe to automated
updates via email, SMS, Twitter, or web feed.
Status updates are reported for two types of activity:
Activity Notifications
For each incident, such as a technical, network, or

connectivity issue, the following notifications along
with additional details may be reported:
Incident • Investigating
• Identified
• Update
• Monitoring (in some cases)
• Resolved

Activity Notifications
For all levels of maintenance activity (scheduled,

short-notice, or essential), the following
notifications along with additional details may be
reported:
Maintenance
• Scheduled/Short-Notice/Essential
• In progress
• Update
• Completed
• Canceled
Subscribe to release notes

Get updates about weekly releases via our RSS feed subscription. Updates will be sent via RSS for each release when
the Release Notes are published.
To subscribe to updates about weekly releases, add the following link to your RSS Feed reader:
https://docs.imperva.com/bundle/cloud-application-security/page/release-notes.rss

Notification Settings
The new Notification Settings feature provides you with more granular control over which notifications can be
received, and the list of recipients who receive them.
This topic discusses how you can edit default notification policies and create new notification policies for account and
website activity, application security events, and network security updates.
Note: The Notification Settings page is currently being rolled out and may not yet be enabled for your account.
If you do not see this page in your account, notifications are sent according to email addresses defined on the Account
Settings page. For details about the classic Notification Settings feature and additional notification reports, see
Notifications.
In this topic:
• Overview
• Default notification policies
• Notification types
• Open Notification Settings
• Manage notification policies
• Notification policy settings
• Notification Settings API
Overview
You can manage which notifications to receive and who should receive them. Customizing the notification settings for
your organization helps ensure better awareness of issues to enable the relevant team to take pro-active steps to
mitigate potential security threats.
Get notified about activity in your subaccounts
For accounts with subaccounts, you can also create policies to receive notifications about activity in your
subaccounts.
For more details, see the Accounts section in Notification policy settings below.
Permissions
By default, the account admin user can create and manage notification policies. In addition, the account admin or a
user with the required permissions can assign the Manage notification settings permission to other account users as
required.
Default notification policies
There are default notification policies created in each account. All policies are on by default. For each of the default
notification policies, you can toggle it on/off, edit trigger settings, and modify notification recipients.
Each default notification policy is named Default <subtype>. For example, Default Account Notifications.

Notification types
The following notification types are available.
Notification Type Subtype Description

Notifies about changes in account
Account and Website Account Notifications
data and status.
Notifies about the expiration of
Imperva generated SAN
Certificate Management
certificates, and whether
Notifications
certificates have been modified,
approved, or validated.
Receive a monthly attack report, in

PDF format.
The report provides an overview of

attacks on your websites that were
most targeted over the past year,
Executive Attack Report
including attack distribution by
Notifications
type, severity, time, source
country, source client, and
website.
For details on the report, see

Attack Report.
Notifies about the connectivity

status of the SIEM logs storage.
The data integrates with third-
SIEM Storage Notifications party SIEM systems. For more
information about configuring
your SIEM to consume Imperva
logs, see Installing a SIEM Package.
Notifies about the Cloud Security

Console's subscription trial status
and whether the account has
Subscription Notifications exceeded its bandwidth.
Note: Subscription notification

policies cannot be turned off.
Notifies about DNS changes and

alerts; website onboarding; SSL
Website Notifications
certificate alerts; website PCI
report; website traffic alerts;


origin/data center alerts; and rule
modification.
Notifies about Security rules and

WAF violations, including
backdoor threats, cross-site
scripting, illegal resource access,
remote file inclusion, and SQL
injection. Events are aggregated
and a notification email is sent at
5-minute intervals.
Note: To receive email

notifications for Security rules,
Application Security Events Real-Time WAF Alert Notifications
select the Send an email
notification... option in the Add
Rule page.
For more information about WAF

alerts, see Website Notification
Settings.
For more information about

creating custom Security rules, see
Create Rules.
Notifies about Layer 7 (application

Website DDoS Notifications
layer) DDoS start/stop detection.
Notifies about Layer 3/4 DDoS
start/stop events (excluding Flow
Website Group DDoS Notifications
Monitoring alerts) on the network/
IPs.
Notifies about issues such as
attempted DNS DDoS Layer 7
Network Security DNS Protection Notifications
attacks or connectivity status of
the DNS zone.
Notifies about DDoS attacks and
Individual IP Protection status (up/down), and

Notifications configuration change of the
Individual IP.
Notifies about changes in the
Network Connectivity status (up/down) of origin

Notifications connectivity, e.g. via GRE tunnel,
cross-connect, or ECX.

In on-demand mode, notifies

Network Monitoring Notifications about NetFlow start flow/stop
flow/incompatible flow alerts.
Notifies about DDoS attacks on IP

ranges.
This policy replaces the email

Network Protection Notifications notifications that are configured in
the Flow Monitoring Settings page.
For more details, see Flow

Monitoring Settings.
Open Notification Settings

Log into your my.imperva.com account.
2. On the sidebar, click Notification Settings.

Manage notification policies
You can view, create, and modify notification policies for application and network security alerts, and receive status
updates on your account and its related assets like certificates and websites.
From the row of the appropriate notification policy, select the desired option:
Option Description
Click to create a new notification

policy.
Create a notification policy
For more information, see Notification policy
settings.
Click (Edit).
Edit a notification policy
Note: Trigger settings in the Account and Website
section cannot be edited once a policy is created.

Option Description
Toggle the Status switch on/off.

Activate/de-activate a notification policy
Note: Subscription notification policies are editable
but cannot be de-activated.
From the drop-down, select Delete to delete a

notification policy.
Note:
Delete a notification policy • The deletion of a notification policy cannot be
undone, and recipients will no longer receive
notification.
• At least one policy of each subtype needs to

exist.
From the drop-down, select Duplicate to

Duplicate a notification policy
create a new editable notification policy based on
one of the existing notification policies.
Notification policy settings
The following fields are available when adding or editing a policy:
Section Field Description

Type a unique name of the
General Notification Name notification policy to easily
identify it.
The general application area that

Trigger Notification Type triggers the notification. For
details, see Notification types.
The specific application area that

Subtype triggers the notification. For
details, see Notification types.
The method of notification.

Recipients Channel
Currently available: Email.

Account users or email addresses

of the recipients whom you want
to receive notifications by email.
You can enter up to 100 recipients.

Recipients
Note: Users who haven't verified
their email addresses won't
receive email notifications. For
details, see Add a user.
You can configure a policy to send

notifications for activity in your
account, or to send notifications
for activity that occurs in your
subaccounts.
Accounts Choose accounts
Subaccounts can define their own
notification policies for activity in
their specific subaccount,
independent of any policy defined
in the parent account.
Select the subaccounts that you

want to receive notifications for.
Sub accounts
Notifications are sent for all assets
in the selected subaccount. You
cannot select specific assets.
Apply this notification policy to

Enable notifications on newly
additional subaccounts that are
added sub accounts
created in your account.
Select assets that trigger the

notification, such as websites,
router connections, network
Assets Assets prefixes, individual IPs, Flow
exporters, and DNS zones. If you
choose Select All, all options in
the drop-down are selected.
Enable notification on newly By selecting this option, all newly

added assets onboarded assets are


automatically added to the
notification policy's assets list.
Note: Notification types and subtypes cannot be modified after the notification policy is created. The other fields can
be modified.
Notification Settings API
You can also manage notification settings using the API.
For instructions on using the Notification Settings API, see Notification Settings API Definition.
The definition file presents a full, formatted, and interactive version of the APIs that you can use to learn about the
APIs, or test them using your API ID and key. You can also download the definition file.

Notification Settings API Definition

Subscription Status
The Cloud Security Console's Subscription page enables you to:
• review plan details.

• view usage statistics for the past 30 days.
• download bandwidth history for 3 months.
• download the Imperva Service Level Agreement (SLA).
• upgrade your plan.
Note: For more details on usage and billing, see Account Bandwidth Calculation.
Log in to your account in the Imperva Cloud Security

Console.
1. On the top menu bar, click Account > Account

To access your subscription details
Management.
2. On the sidebar, click Account Management >

Subscription.
Under Change Plan To, select the desired plan and

To upgrade your plan
follow the onscreen instructions.

Account Bandwidth Calculation

Learn how Imperva calculates your bandwidth for billing.
Overview
Imperva uses a burstable billing model for calculation of account traffic. This model is based on calculating the 95th
percentile of bandwidth usage for billing clean traffic. This enables peaks in usage that exceed the limits of your
subscription for brief periods of time. This model is quite common with transit providers and with some CDNs,
although many CDNs use an alternative cumulative model, described later in this topic.
How does Imperva calculate the 95th percentile?
Billing for the entire account's monthly traffic is based on the 95th percentile of bandwidth usage, which is calculated
as follows:
• Imperva uses 5 minute buckets for calculating the 95th percentile.
• Each bucket collects all the traffic that passes through the Imperva network during those 5 minutes:
• Both incoming traffic (client requests sent to Imperva) and outgoing traffic (responses sent to clients
from Imperva) are taken into account.
• Traffic between Imperva and your origin servers is not taken into account. This includes:
• The fetch to the origin server for missing response content.
• The traffic sent back from the origin server to be cached in Imperva.
• Both cached bits and non-cached bits are taken into account.
• Blocked traffic is not taken into account. Blocked traffic includes blacklisted traffic, L3/4 DDoS traffic,
L7 DDoS traffic, bad bots, security rules, and others.
• Traffic is aggregated across all services (IP Protection, Website Protection, and Infrastructure
Protection).

• For sites that are protected by Website Protection as well as IP Protection or Infrastructure Protection,
the traffic for those sites is only counted once in the overall calculation of aggregated traffic.
• Total traffic in each bucket is then divided by 300 to convert it to bits per second (bps) format.
• At the end of the month, starting on the billing date, the 5% of buckets with the most bps are dropped, and the
highest bps rate of the remaining buckets represents the 95th percentile value for the account.
• The calculation is performed separately for always-on services and on-demand services.
• The calculation for on-demand services takes into account only those time periods during which traffic was
diverted to Imperva.
For example, if traffic was diverted to Imperva for one week out of the entire month, the calculation drops the
top 5% of the traffic during that week.

How is the 95th percentile calculated for non-web traffic?
Calculation of non-web traffic is performed in exactly the same way as web traffic. Usage is calculated across all IPs
and/or IP ranges into 5-minute buckets which are aggregated with all other services.
The calculation is performed separately for always-on services and on-demand services (separate buckets and
aggregation).
Where can I see the 95th percentile calculation?
In the Imperva Cloud Security Console, on the sidebar, click Management > Subscription.
Note: Bandwidth calculation displayed on the Subscription page includes both incoming (visitors > Imperva) and
outgoing (Imperva > visitors) traffic.
Alternatively, bandwidth usage displayed in the Cloud Security Console's Network and Infrastructure Dashboards
reflects ingress traffic only (visitors > Imperva). The dashboards display peak values for the selected time period.

The Subscription page displays statistics for the last 30 days. It does not correspond directly to your billing cycle. For
example, if your billing cycle begins on the first of the month and you are looking at the Subscription page on the
15th, the statistics displayed for the last 30 days include both part of the previous billing cycle and part of the current
billing cycle.
Can I view past billing data?
The Usage Report provides a view of your account’s bandwidth usage per service over time, enabling you to easily
understand usage trends and quickly detect overages in your account. You can also download the report or access it
via the API. For details, see View Account Usage.

What happens when an account exceeds its plan?
At the beginning of each billing cycle, the system checks whether or not the account exceeded its plan in the last
billing cycle. In the event of an overage, a notification will be sent to the account's owner.
What happens if a site under Web Protection is also protected by IP Protection or BGP-based Infrastructure
Protection? Will Imperva charge for the site's traffic twice?
No. In such a case Imperva will subtract that specific site’s traffic from the total accumulation in the calculation of the
95th percentile.
How does the cumulative model, used by other CDNs, work?
Many CDNs use the cumulative model for clean traffic billing. Some offer both cumulative and burstable alternatives.
The cumulative model is calculated according to the total bytes that are “consumed” during a given month. It is
usually presented in either GB or TB.

Audit Trail
In this topic:
• Overview
• View the audit trail
• Imperva Support activity
• Audit Trail API
Overview
Benefits
• Provides full visibility at all times into which actions were performed, when they were performed, and by whom.
• Supports decision-making by providing visibility into change management.

• Speeds up troubleshooting - quickly see who did what, when, and where.
Accounts and sub accounts
• When viewing the audit trail for an account with sub accounts, activity is displayed for the account and for all
sub accounts, provided that the user has permissions to the sub accounts and to the audit trail.
• When viewing the audit trail for a sub account, only the activity for the sub account is displayed.
Who can view the Audit Trail?
• The account administrator user

• Any account user with the View audit trail permission
For how long is the audit activity saved?
Audit activity for your account is saved for a minimum of 7 years.

View the audit trail
2. On the sidebar, click Account Management > Audit Trail.
Field Description
You can filter for a specific range of dates to view a
Time subset of the activities.
The action that was performed in the account, such
Type as logging in, adding a user, or changing site
settings.

Field Description
One of the following:
• Email address of the user who performed the

Performed By
action
• Imperva Support
• Imperva System Process
The name of the account in the Cloud Security

Account
Console.
The object that was acted on, such as a site in the
Resource
account.
The audit activity was performed by one of the

following:
• User Action
Context • API (API ID is displayed. For more details on
API IDs, see API Key Management.)
• System
• Internal API
Message Additional details about the audit activity.
Tips:
• Use the free text filter at the top of the page to filter the displayed data by keyword or ID, such as account ID or
API ID.
• Click Export to CSV to download the audit trail .csv file format. If a filter is currently applied, the download
includes the filtered data only.
Imperva Support activity
The Imperva team has the ability to assume the identity of a specific end-user in a customer account for investigation
and troubleshooting purposes.
This enables Imperva Support, for example, to view the account from the customer perspective, or to perform pre-
approved actions on the customer’s behalf.
When an Imperva employee assumes the identity of a user in your account, the following events are logged in the
Audit Trail:
• Logged in as customer account user
• Logged out of customer account user
These audit trail entries indicate the account user whose identity was temporarily taken on. For example: “Imperva
Support logged in as account user user@demo.com”.

In addition, all actions performed by Imperva Support while logged in as a user of your account are also recorded in
the Audit Trail. For example: “API key created. Performed by Imperva Support logged in as user@demo.com”.
Audit Trail API
Get audit events for your account using the Audit Trail API.
For instructions on using the Audit Trail API, see Audit Trail API Definition.
The definition file presents a full, formatted, and interactive version of the Audit Trail APIs that you can use to learn
about the APIs, or test them using your API ID and key. You can also download the definition file.
See also
• Audit Trail API Definition

• Audit Trail Event Types

Audit Trail Event Types

The list of audit trail event types for Imperva Cloud Application Security.
Types
A-records changed
ABP Account created
ABP Account updated
ABP Website Group priorities updated
ABP Account credentials created
ABP Account credentials deleted
ABP Website Group created
ABP Website Group updated
ABP Website Group deleted
ABP Website created
ABP Website updated
ABP Website priorities updated
ABP Website deleted
ABP Website encryption key created
ABP Website encryption key deleted
ABP Condition created
ABP Condition updated
ABP Condition deleted
ABP Policy created
ABP Policy udpated
ABP Policy deleted
ABP Configuration published
Account 1-day cancellation notification sent
Account activated
Account admin changed
Account bandwidth exceeded
Account data cleanup completed successfully
Account deleted
Account edit event
Account locked
Account moved
Account notifications email changed
Account removed
Account removed due to trial expiration
Account roles deleted
Account signup
Account signup

Types
Account SSO error
Account support of all TLS versions changed
Account unlocked
Add-on trial ended
Add-on trial started
API key created
API key deleted
API key disabled
API key edited
API key enabled
API key reset
ASN added
ASN deleted
Assets added to policy
Assets removed from policy
Available account added to policy
Available account removed from policy
Backdoor added
Backdoor removed
BGP added
BGP changed
Black list item added
Black list item removed
Cache mode changed
Cache purged
Cache rule added
Cache rule disabled
Cache rule edited
Cache rule enabled
Cache rule removed
Cache Shield settings changed
Client CA certificate uploaded
Client CA certificate deleted
Client CA certificate updated
Client CA certificate assigned to website
Client CA certificate removed from website
Client CA certificate site configuration changed
Compress logs settings changed
Configuration changed
Configuration changed to multi data centre
Connection added/created

Types
Connection changed/updated
Connection deleted
Custom SSL added
Custom SSL removed
Data storage region changed
Details changed
Detection policy updated
Domain added
Domain deleted
Domain state changed
Email change verification mail sent
Email changed
Email verified
Encryption disabled
Exception changed
Exception deleted
Failed to change cache mode
Failed to change email
Flow exporter added
Flow exporter changed
Flow exporter deleted
HSTS configuration changed
HTTP/2 configuration changed
IP changed
IP range diverted
IP range reverted
Log configuration created
Log configuration deleted
Log configuration updated
Logged in as customer account user
Logged out of customer account user
Login
Login attempt by unauthorized IP address
Login Protect activated
Login Protect disabled
Login Protect Google Authenticator verification failed
Login Protect Google Authenticator verified
Login Protect invitation
Login Protect phone verified
Login Protect phone verified failed
Login Protect user edited

Types
Login Protect user removed
Login Protect user revoked
Log collector API key changed
Log collector config deleted
Log collector config status changed
Log collector item deleted
Log format settings changed
Manual certificate deleted
Manual certificate uploaded
Max log size settings changed
New CSR generated
New logs collector API key created
New log collector config created
New log collector item created
Password changed
Password forgotten
Password reset by admin user
Policy added
Policy cloned
Policy deleted
Policy modified
Policy status modified
Policy modified, exception added
Policy modified, exception saved
Policy of IP range updated
Protected IP over Layer 2 added
Protected IP over Layer 2 changed
Protected IP over Layer 2 deleted
Remove SSL complete
Remove SSL start
Request for account data cleanup
Role assigned
Role assignment deleted
Role created
Role deleted
Role updated
Rollover time settings changed
Route option deleted
Rule added
Rule disabled
Rule enabled

Types
Rule edited
Rule priority changed
Rule priority fixed
Rule removed
Rule reverted
SAN CAA records fixed
SAN expiration notice sent
SAN undeleted
SAN validation method changed
Seal location changed
Secure Resources settings changed
Security policy updated
Sent unavailable storage email notification
Server added to datacenter
SIEM configuration resources purged
SIEM log integration migrated
SIEM log integration rolled back
SIEM notification email pushed
Single IP added
Single IP changed
Single IP deleted
Site advanced security rule configuration changed
Site cache settings changed
Site configured
Site created
Site delivery settings changed
Site enabled
Site in extended SSL validation
Site is disabled
Site log level changed
Site moved
Site moved account
Site moving process started
Site notifications settings changed
Site origin servers settings changed
Site reached the maximum number of allowed backdoor URLs
Site removed
Site security configuration changed
Site server disabled
Site state changed
Site support of all TLS versions changed

Types
Site's POPs blacklist changed
Site's POPs whitelist changed
Specific resources purged
SSL added
SSL process started
SSL selected
SSO account configuration created
SSO account configuration updated
SSO protocol configuration created
SSO protocol configuration updated
Static route added
Static route changed
Subdomain added
Subdomain deleted
System message set
Two factor authentication by email
Two factor authentication by Google Authenticator failed
Two factor authentication by Google Authenticator verified
Two factor authentication by phone failed
Two factor authentication by phone verified
Two factor authentication by SMS
Two factor authentication disabled
Two factor authentication enabled
Two factor authentication failed
Two factor authentication passed
User added to account
User login via SSO failed
User permissions changed
User removed from account
User roles deleted
User successfully logged in via SSO
Waiting room added
Waiting room deleted
Waiting room updated
Weekly account report read
Weekly account report sent

Audit Trail API Definition

View Account Usage

The usage report displays bandwidth usage history for an account. It provides you with a view of your bandwidth
usage per service over time, enabling you to easily understand usage trends and quickly detect overages in your
account.
In this topic:
• Overview
• Open the usage report
• View report details
• Usage Report API
Overview
Usage displayed in the report is per billing plan.
• Monthly usage data is based on the 95th percentile of bandwidth usage for billing clean traffic. To learn more
about how the 95th percentile for billing is calculated, see Account Bandwidth Calculation.
• The report provides a clear indication of overages - where monthly usage has exceeded the bandwidth included
with your plan.
• You can also access the report via the API, or download it in CSV format.
• For accounts with sub accounts, note that the report is available only in the parent account. Usage data for the
account includes all of the sub accounts and their sites.
Availability of usage data:
Monthly usage data is available as of September 2020, when the feature was implemented.

Permissions:
By default, the account admin user and users who are assigned one of the default roles (Administration, Reader) have
full access to the usage report.
The following permissions can be added to roles and assigned to other account users as required:
• View usage report: The user can view the Usage Report in the Cloud Security Console.
• Use usage report API: The user can access the usage report via the API
Open the usage report
Log in to your account in the Imperva Cloud Security Console.
2. On the sidebar, click Account Management > Usage Report.

View report details
You can filter both the upper and lower sections of the report according to billing plan. The billing plans listed in the
report are based on your subscription.
Note: The billing plans listed in the report may also depend on when the plan was purchased. For example, if you have
purchased Always On Infrastructure Protection, it may be listed under the Always On Bandwidth billing plan (for
older subscriptions), or in its own Infrastructure Always On Bandwidth billing plan (newer subscriptions).
Usage Information for last 12 months
This section displays a quick snapshot of your account usage for each billing plan over the past 12 months.
Monthly usage
The lower table drills-down into usage data per billing period for each billing plan that you have purchased. It will
include the entire usage history for the account moving forward.
Tip: Click Export to CSV to download the table in CSV format.

Column Description
The period of time for which usage is calculated and

compared with the purchased amount.
Note: The billing period does not directly

Billing Period
correspond to when payments are due for your
account, or to the usage statistics on the
Subscription page, which always displays the last
30 days.
The plan you have purchased. It may include several

services. For example, the Always On Bandwidth
Billing Plan
plan can include the Website Protection and
Infrastructure Protection services.
Services The product or products included in the billing plan.

The amount of bandwidth included in the billing
Purchased
plan.
Used Your account's usage during the billing period.
Your usage for the billing period beyond the amount
Overages
included in your billing plan.
Drill-down by service
Click a row in the Monthly usage table to view a breakdown of usage for each service.

Distribution by service: The monthly usage per service in your account's plan, based on the 95th percentile
calculation.
Bandwidth over time (bits per second): Raw data based on actual usage in each 5-minute bucket.
Note:
• The Used column in the table can display a value of zero (0), while the raw data in the graph for the same billing
period can display a small amount of traffic. This is due to the 95th percentile calculation method that is
reflected in the Used column, which includes rounding of the values.
• There may be a 0.01 discrepancy between the value displayed in the table's Used column and the Total Usage
value displayed under Distribution by service. This is due to the rounding of the values of the individual
services.
Usage Report API
Access usage data via the API:
Billing summary: Retrieve usage details for each billing period in a specified time range (purchased/used/overage).
Actual bandwidth usage: Retrieve actual usage data for each 5-minute bucket in a specified time range.
For instructions on using the Usage Report API, see Usage Report API Definition.
The definition file presents a full, formatted, and interactive version of the Usage Report APIs that you can use to learn
See also:
• Subscription Status


Usage Report API Definition

Attack Report
Gain insights into attack trends on your assets over the past year and easily share them across your organization.
The Attack Report provides an overview of attacks on your websites and web applications, including attack
distribution by type, severity, time, source country, source client, and website.
In this topic:
• Overview
• Subscribe to the Attack Report
• Report content
• Attack types
Overview
When you subscribe to the Attack Report, Imperva sends you a monthly email with the report attached, in PDF format.
Data in the report represents activity for websites in your account and its subaccounts that were most targeted over
the past year.
The following descriptions can be useful for understanding the report data:
Item Description
Event A request that triggers a security rule.
A cluster of multiple, related events. An incident is
created when Imperva identifies events of a similar
Incident
attack type from the same source (IP, device) within
a short period of time.
The type of attack, as identified and categorized by
Attack types Imperva Research Labs. For more details, see Attack
types below.
The client application that sent the request, based
Client on Imperva's client classification technology and
database. For more details, see Client Classification.
The size of an attack is based on the number of
Attack size
malicious requests.
Subscribe to the Attack Report
By default, the account admin user automatically receives the report.
To add others to the recipient list, the account admin or any user with the Manage notification settings permission
can configure the notification settings:
• Notification type: Type: Account and Website
• Notification subtype: Executive Attack Report Notifications
For more details on configuring notifications, see Notification Settings.

Note: With the introduction of this new feature on May 22, 2022, anyone already configured to the receive the Account
and Website: Default Account Notifications will automatically receive the monthly Attack Report.
Report content
The report provides statistics on the following areas over the past year.
Report page Description
An overview of the attack landscape for your

account.
Executive summary
View trends in attacks as compared to the previous
report period.
The types, distribution, and severity of attacks on

Incident details
your websites.
Data on the source location of the attacks and the

Incident distribution clients that sent the malicious requests, including
distribution by severity.
The most frequently attacked websites in your

Website posture
account, and the type of attacks that occurred.
The types and size of attacks that targeted your 20
Incidents for 20 most visited websites
most visited websites.
FAQs Find answers for some commonly asked questions,
Note: The Attack Report covers an extended list of attack types, beyond those presented in the Cloud Security
Console. As a result, the number of reported incidents may differ. Future plans include adding all of the additional
attack types to the Cloud Security Console. At that time, the incident numbers displayed will be identical.
Attack types
Some or all of the following attack types can appear in your report, based on your subscribed services. The list
includes all attack types, as identified and categorized by Imperva Research Labs.
Type Description
An unauthorized user takes ownership of an online

account using stolen usernames and passwords.
Account Takeover
This attack then exploits legitimate functionality of
an application, rather than attempting to exploit
unmitigated vulnerabilities.
API Violation
Unauthorized use of an application’s API.

Type Description
Indicates attacks blocked by Imperva's API Security.
The attacker performs malicious activity by

Authentication Bypass bypassing the application’s authentication
mechanism.
Attacks that Imperva has not classified as a known

Automated Attack
type.
An attacker's attempt to access a malicious script in

Backdoor/Trojan
the application server, such as a web shell.
Exploits vulnerabilities in the application’s design or

implementation that enable an attacker to perform
malicious activity.
Business Logic
Indicates attacks blocked by Imperva's Advanced
Bot Protection. For more details, see Advanced Bot
Protection.
Enables the attacker to pass data to a destination

Data Leakage
outside of the web application.
Unauthorized upload of a malicious file to a system,
File Upload that can be used later for attack purposes, such as
remote code execution.
Path traversal and local file inclusion (LFI)
vulnerabilities. Via a web application, attackers
Path Traversal/LFI
access files on a web server that they should not be
able to access.
Disrupts a communication protocol to perform an
Protocol Manipulation
attack.
Remote code execution / Remote file inclusion.
Targets the web servers that run websites and their
RCE/RFI applications. It represents an attempt to manipulate
an application into downloading or executing a file
from a remote location.
Unauthorized use of a messaging system to send
Spam
messages to the system’s users.
SQL injection of malicious code into a web
SQLi application through an entry field for the purpose of
backend database manipulation.
Server-side request forgery (SSRF) causes a server-
SSRF side application to make unauthorized HTTP
requests.

Type Description
Cross Site Scripting attempts to run malicious code
XSS
on your website visitor’s browser.

Near Real-Time SIEM Log Integration

Send security event logs for Imperva's cloud services to your cloud storage repository.
Note: This document introduces Imperva's new Near Real-Time SIEM log integration. For documentation on the
legacy Cloud WAF log integration, see Cloud WAF Log Integration.
In this topic:
• Overview and configuration

• Allow access to Imperva IPs
Overview and configuration
The log integration is currently supported for the following services:
Service Availability How to configure the integration
You can configure the log

integration to export your
Advanced Bot Protection security
logs to your preferred SIEM
solution.
Advanced Bot Protection (ABP) Available by default
Where it's located: On the SIEM
Logs > Log Configuration page.
For details, see Configure the SIEM
Log Integration.
Once the feature is enabled for

your account, you can configure
the log integration to send event
logs to your preferred SIEM
solution.
Where it's located: On the SIEM

DDoS Protection for Networks/IPs Available on request Logs > Log Configuration page.
For details, see Configure the SIEM
Log Integration.
For more details on the

integration, see SIEM Log
Integration: DDoS Protection for
Networks and IPs.

Service Availability How to configure the integration
The legacy cloud WAF SIEM log

integration is still in use for the
Imperva API and SFTP methods.
Cloud WAF customers who were

already using the legacy
integration with the S3 method
have been migrated to the new
Near Real-Time SIEM mechanism.
To start using the new Near Real-

Time SIEM log integration:
Available for the Amazon S3 push
Cloud WAF Configure the settings on the
method only
legacy page and select the S3
method. Once you configure the
integration, your account is
automatically onboarded to the
new Near Real-Time SIEM
mechanism within several
minutes.
Where it's located: On the

SIEM Logs > WAF Log Setup page.
For details, see Cloud WAF Log
Integration.
When using the Near Real-Time SIEM log integration, you can expect the following:
Attribute Description
Sending rate Files sent every 10-70 seconds
Data freshness File arrives within 3-5 minutes of the event
Security events
File contents
Access events will be added at a later date
Log file names <account_id>.<log type>.<uuid>.log

123456.CONNECTION.7f108651-1258-4177-a3dd-
Example
c9f6bb4dccfa.log
Allow access to Imperva IPs
Make sure you have Imperva IP addresses included in your allowlist. IP addresses used by the Near Real-Time SIEM log
integration are listed under Other services on this page: Allowlist Imperva IP addresses & Setting IP restriction rules.
Imperva ranges, as they are not required by all Cloud WAF customers.

See also:
• Configure the SIEM Log Integration
• SIEM Log Integration: DDoS Protection for Networks and IPs

Configure the SIEM Log Integration

Set up the Imperva Near Real-Time SIEM log integration for your account.
Note:
• Imperva recently introduced this new Near Real-Time SIEM solution. To learn more before you begin, see Near
Real-Time SIEM Log Integration.
• For details on the legacy log integration for Cloud WAF, see Cloud WAF Log Integration.
This Log Configuration page is currently available for configuring the Near Real-Time SIEM log integration for the
following services:
• DDoS Protection for Networks/IPs (The integration is available per request only. To enable the feature for your
account, contact Imperva Support.)
For Cloud WAF customers who would like to use the Near Real-Time SIEM log integration, you must setup the
integration with the S3 method on the SIEM Logs > WAF Log Integration page. For details, see Cloud WAF Log
Integration.
In this topic:
• Overview
• Open the Log Configuration page
• Create or edit a connection
• Add or edit a configuration
• View your log configuration
• Troubleshoot SIEM storage unavailability
Overview
Send security event logs for Imperva's cloud services to your cloud storage repository.
Setting up the SIEM log integration requires the following:
• A connection: Provide the details of your log storage repository to Imperva.
• A configuration: Select the logs that you want to receive from Imperva based on your subscribed services.
Permissions
The account admin user or any user who is assigned the Administrator role can configure the log integration.

Allow access to Imperva IPs
Make sure you have Imperva IP addresses included in your allowlist. IP addresses used by the Near Real-Time SIEM log
integration are listed under Other services on this page: Allowlist Imperva IP addresses & Setting IP restriction rules.
Imperva ranges, as they are not required by all Cloud WAF customers.
Open the Log Configuration page

Create or edit a connection
Define the details of your log storage repository.
Provide the path to your repository and the access credentials Imperva needs to push the logs.
In the Connections table, click Add new to create a connection, or to edit or delete a connection.
Note: If you choose to update any details of a connection after it is fully defined and saved, you must re-enter the
secret key in order to save your changes.
Field Description
Currently supports connection to Amazon S3 only.
To enable Imperva to access your S3 bucket, select

an authentication method:
• Amazon S3: Provide your access key ID and

Connection type secret access key for authentication.
• Amazon S3 ARN: Define an IAM role in your S3

bucket policy that grants Imperva permission
to upload log files. For more details on
configuring this connection, see Amazon S3
ARN.
Enter a descriptive name to help you identify this

Connection name connection. You can rename the default connection
name.
Path The location of the folder where you want to store

the log files.

Field Description
Enter the path in the following format: <Amazon S3
bucket name>/<log folder>.
For example: MyBucket/MyIncapsulaLogFolder.
Your S3 access key.

Access key
For the Amazon S3 connection type only.
Your S3 secret key.

Secret key
For the Amazon S3 connection typeonly.
Performs a full testing cycle in which a test file is

transferred to your designated folder. The test file
Test Connection
does not contain real data, and is removed by
Imperva when the transfer is complete.
Defined: Details of your log storage repository are

fully defined for this connection. The connection can
be used in a configuration.
Status
Undefined: The required details have not been
provided or the connection test failed with the
details that were provided.
Amazon S3 ARN
For enhanced security, you can define a connection to your S3 bucket using the AWS Amazon Resource Name (ARN)
authentication with an Identity and Access Management (IAM) role.
Create a policy for your S3 bucket and define a role that grants Imperva permission to upload log files.
Required: To enable Imperva to upload log files, define the following in your S3 bucket policy:
Parameter Definition
"AWS": "arn:aws:iam::446351906296:role/prd-
Role
imperva-logs"
"arn:aws:s3:::<CUSTOMER_S3_BUCKET>/
Resource <CUSTOMER_S3_FOLDER>/*"
Identifies the destination folder for your log files.

Make sure to replace the bolded text with your
bucket and folder details.
Action "s3:PutObject" (Required for log file upload.)
Optional: When you create or update a connection to your S3 bucket, Imperva runs a test by attempting to connect to
your bucket and uploading a test file.
You can define the following permissions to allow Imperva to delete the test file that is uploaded when the connection
to your S3 bucket is tested.
"AWS": "arn:aws:iam::446351906296:role/prd-
Role
imperva-logs"
"arn:aws:s3:::<CUSTOMER_S3_BUCKET>/
<CUSTOMER_S3_FOLDER>/
imperva_siem_test_file_*.text"
Resource
Make sure to replace the bolded text with your
bucket and folder details.
Action "s3:DeleteObject" (Deletes the test log file only.)
Add or edit a configuration

Configure the logs that you want to receive from Imperva.
The services and log types available to you are based on your subscribed services.
Add a configuration: In the Configuration table, click Add New.
The Add New button is disabled if there is no connection defined for your account, or when all available log types
have already been added to a configuration.
Edit a configuration: In the Configuration table, click the ellipsis next to a configuration and click Edit.
General
Field Description
Add a descriptive name for this configuration. Each
Configuration name
configuration name must be unique.
Select a service for which you want to configure the
Select service
log integration.

Field Description
Add logs types to the configuration.
Each log type can be used only once per connection.

Log types that are already in use in other
Select log types configurations are not displayed.
Network Security: For details of the available log

types, see SIEM Log Integration: DDoS Protection for
Networks and IPs.
Format Supports JSON format only.
Enabled: Imperva is sending logs for this

configuration.
State
Disabled: Imperva is not currently sending logs for
this configuration. You can enable the configuration
to start sending logs again.
Connection
Select the connection to use for this configuration.

View your log configuration
The Log Configuration page displays the existing connections and configurations defined for your account.
Connections table
Lists the connections configured for your account.
Connections define the path to your log storage repository and the access credentials for Imperva to use.
Field Description
Name The name assigned to this connection.
Connection type Currently supports connection to Amazon S3 only.
The method of authentication used to allow

Imperva to upload files to your log storage
repository.
Authentication method
• ARN: Authentication using the AWS ARN for
your bucket with a defined IAM role to allow
Imperva to upload log files.

Field Description
• User/Password: Authentication using your
access key ID and secret access key.
For more details, see Create or edit a connection

above.
Indicates if you have defined this connection and

Status
provided Imperva with the details of your S3 bucket.
More options Click to edit or delete a connection.
For more details see Create or edit a connection

above.
Configurations table
Field Description
Name The name assigned to the configuration.
Service The Imperva service specified for this configuration.
Log type The log types specified for this configuration.
Connection name The connection used by this configuration.
Enabled: Imperva is sending logs for this

configuration.
State
Disabled: Imperva is not currently sending logs for
this configuration. You can enable the configuration
to start sending logs again.
Edit: For more details, see Add or edit a

More
configuration.
Delete: Deletes the configuration. Imperva will no

longer send logs defined in this configuration.
Troubleshoot SIEM storage unavailability

If your SIEM storage repository becomes unavailable, Imperva will be unable to upload the log files.
When this happens, you will be notified by mail, according to your notification settings. (Make sure that SIEM storage
notifications are configured for your account. For details, see Notification Settings.)
To troubleshoot the issue, consider the following:
• Are the required Imperva IP addresses allowed access to your bucket? For details, see here.

• Are permissions on your S3 bucket set correctly to allow access to Imperva?
• Is there a current network issue preventing the connection?
• Does your S3 bucket have sufficient storage capacity?
Imperva continues to attempt to send the logs for 48 hours, after which time there are no further attempts to upload
the logs.
Note that for Cloud WAF customers, past events are also available on the Cloud Security Console’s Security Events
page, or via the API, for a period of 90 days.
DDoS Protection for Networks/IPs customers can view past events on the Network/IP Protection dashboards.
Imperva continues testing the connection. When it is restored and Imperva is able to access your S3 bucket, another
notification is sent to you.
See also:
• SIEM Log Integration: DDoS Protection for Networks and IPs

SIEM Log Integration: DDoS Protection for Networks

and IPs
Send event logs for the Imperva DDoS Protection for Networks and IPs services to your preferred SIEM solution.
This integration is based on the new Imperva Near Real-Time SIEM solution, currently rolling out. For details, see Near
Real-Time SIEM Log Integration.
Note: The integration is available per request only. To enable the feature for your account, contact Imperva Support.
In this topic:
• Log files
• Log types
• Events
• Event fields
• Sample events
Log files
Each event is provided in a separate file.
The filename format is as follows:
<account ID>.<log type>.<uuid>.log
<account ID> The unique ID of your Imperva account.

Either Connection, Netflow, Attack or IP, as
<log type>
described below in Log types.
<uuid> A unique identifier for the event.
For example:
123456.CONNECTION.7f108651-1258-4177-a3dd-c9f6bb4dccfa.log
Log types
You can choose to enable the integration for any or all of the following log types, based on your subscribed services.
For more details on each event, see Events below.
Log type Description Related events

Change in the BGP peer
• Connection up
CONNECTION (Network connectivity status of the
Connectivity) connection between Imperva and
• Connection down
your origin network.

Log type Description Related events
• Flow traffic has stopped

Change in status of the flow that
NETFLOW (Network Monitoring) you are exporting to Imperva for • Flow traffic has started
flow-based monitoring.
• Incompatible flow traffic
• DDoS event has started
• DDoS event has ended

Events related to a DDoS attack on
ATTACK (Network and
your protected network ranges or • DDoS attack detected
IP Protection)
IPs.
• IP is up
Change in status of your protected
IP (IP Connectivity)
public IP.
• IP is down
Events
Log entries are generated for the following events.
All entries also include the time of the event and the Imperva data center (PoP) from which the event was originally
reported.
Event Event fields

For more details on each event, see the View the
For more information on each event field, see the
Event Log section of Security Dashboard:
Event fields section below.
DDoS Protection for Networks and IPs.
• Connection ID
Connection up • Connection name
• Connection type
• Connection ID
Connection down • Connection name
• Connection type
• Exporter customer IP
Flow traffic has stopped
• Exporter description

Event Event fields
Flow traffic has started
Incompatible flow traffic
DDoS event has started • IP range
• IP range
• Imperva data center
DDoS event has ended • Attack duration
• Peak total traffic (bps)
• Peak total traffic (pps)
• IP range
• Traffic volume
• Traffic type
• Main targeted assets (Iist of IP addresses)
• Is automatic divert enabled?
• Range type (Always-on or On-demand)
IP is up • Customer public IP
IP is down • Customer public IP
Event fields
Log entries are presented in the standard JSON key/value pair format of "fieldname":"fieldvalue". For example,
“timestamp”:“1630832131096”.
Field name Field name in JSON format Description

Start time of the event in
Time of the event timestamp
Unix epoch time, in milliseconds.
The Imperva data center (PoP)
Imperva data center (PoP) observer from which the event was
originally reported.
The unique Imperva ID for the
Connection ID id connection, as defined in the


The name of the connection
between the Imperva network and
Connection name name
your origin network, as defined in
the Connectivity Settings page.
The connection type. Possible

values include:
• BGP (for a GRE tunnel

Connection type type connection)
• ECX
• CROSS_CONNECT
Your protected network, as

configured on the Network
IP range ipRange
Settings > Protected Networks
page.
Attack duration duration The length of the attack.

The total traffic during the attack,
Peak total traffic (BW) peakBW in bits per second, as displayed in
the Dashboard.
The total traffic during the attack,
Peak total traffic (PPS) peakPPS in packets per second, as
displayed in the Dashboard.
The IP address of your flow

Exporter customer IP ip exporter, as configured in the Flow
Monitoring Settings page.
Exporter description A description of your flow

description exporter, as configured in the Flow
Monitoring Settings page.
The volume of traffic, in bits per

Traffic volume (bps) trafficVolumeBps second, from the start of the attack
until the attack was detected.
The volume of traffic, in packets

per second, from the start of the
Traffic volume (pps) trafficVolumePps
attack until the attack was
detected.


The network protocol or attack
Traffic type trafficType
vector, such as TCP or SYN.
The top IP addresses that were
Main targeted assets mainAssets
targeted in the attack.
For on-demand customers,

indicates if you have opted for the
automated switchover mode, in
which Imperva automatically re-
routes the attacked network prefix
Is automatic divert enabled? automaticDivert
traffic to our scrubbing centers
through BGP announcements, and
then performs attack mitigation.
Possible values: true, false
The service mode of your

Range type rangeType protected network: Always-on or
On-demand
Your protected public IP address,

Customer public IP ip as defined in the Connectivity
Settings page.
connection-down-event
ddos-start-event
ddos-end-event
attack-detected-event For more details on each event,

see the View the Event Log
Event name flow-start-event section of Security Dashboard:
DDoS Protection for Networks and
flow-stop-event IPs.
incompatible-flow-event
ip-is-up-event
ip-is-down-event

Sample events
Log type Event name Sample event
{"event":{"action":"connection-
down-event"},
"@timestamp":1630832131096,
CONNECTION (Network
Connection down "observer":{"geo":
Connectivity)
{"name":"cdg"}}, "connection":
{"id":1711,"name":"Demo
connection","type":"BGP"}}
{"event":{"action":"flow-start-
event"},
"@timestamp":1630832131095,
NETFLOW (Network Monitoring) Flow traffic has started
"observer":{"geo":
{"name":"mia"}},"server":
{"ip":"1.2.3.4"}}
{"event":{"action":"ddos-start-
event"},
ATTACK (Network and "@timestamp":1630832131095,
DDoS event has started
IP Protection) "observer":{"geo":
{"name":"bom"}},"ip_range":
{"ip_range":"1.2.3.4"}}
{"event":{"action":"ip-is-down-
event"},
"@timestamp":1630832131097,
IP (IP Connectivity) IP is down
"observer":{"geo":
{"name":"dub"}},"server":
{"ip":"1.2.3.4"}}
See also:

• Connectivity Settings: DDoS Protection for Networks
• Flow Monitoring Settings
• Imperva Data Centers (PoPs)


Account Users
As an account administrator or other user with the appropriate permissions, you can create additional account users
for your team members, to enable collaboration and co-management of the Imperva service.
You can grant different levels of permissions and sub account access to users, based on the level of visibility and
control that is required.
Note: The Cloud Security Console's new Account Users page is currently being introduced to a limited number of
direct customers (not resellers). We will provide updates in future release notes about the continued rollout.
For more details on the new page, see Manage Account Users
In this topic:
• Overview
• View the account user list
• Add a user
• View and edit user settings
Overview
The Account Users page lists all account users.
Account admins can:
• add and delete users

• reset a user password
• grant granular permissions to users, including access to account settings, control over sites and DNS zones, and
control over other users and permissions
• manage API keys for all users
Note: If you need to change the account administrator user, contact Support to request the change.
View the account user list
To access the Account Users page:

Add a user
Click Add User. The account administrator or any user with the appropriate permissions can add a new user to the
account.
When a new user is created in an account, a verification mail is sent to the email address listed for the user.
The new user clicks the link in the email to verify their address and set a login password.

Note: If the user does not verify their email address within 15 days after the user was created, the user is locked out.
When the user tries to log in, the user receives an email notification that includes a link to verify and unlock the user.
Notification emails are sent to the user before the user is locked, as a reminder to verify their email address. The
address verification link is included in the mail.
When users are locked out, the account admin user receives an email notification with the list of unverified users in
the account.
View and edit user settings
Click a user row to open the Settings panel.

Create and manage up to 5 API keys per user. For
Manage API Keys
details, see API Key Management.
The account administrator or any user with the

appropriate permissions can manage user
Manage Permissions
permissions using roles. For details, see Manage
Roles and Permissions.
Limit log in access by providing a specific list of

Manage approved log-in IP addresses approved log-in IP addresses that the user is
permitted to log in from.
Actions > Delete. Deletes the selected user. This
Delete a user cannot be undone. The Account Admin user cannot
be deleted.
Actions > Reset Password. Resets the password for
Reset a user password the selected user. A password reset link is displayed
onscreen, which you can then send to the user.
Actions > Set as API-only user
Defines a user with permissions to use only the API.

This user cannot log in to the Cloud Security
Console.
This can be useful when creating users that only

require API access, such as for automation
Limit user to API-only access
processes.
Note:
• When enabled, the label API Only is displayed

next to the user name.
• API use is allowed according to the

permissions of the user's assigned role.


• You cannot set this option for an external user
in your account (a user that was created in a
different account and then added to your
account). Example: A user is created in
Account A, and then added to Account B. You
can set the user as API-only in Account A, but
not in Account B.
• The API-only access is managed for the user at

the parent account level. Therefore, the user
cannot access any other accounts or their
subaccounts via login to the Cloud Security
Console.
Actions > Remove API-only restriction

Restore access to Console login
Removes the API-only restriction and allows the user
to log in to the Cloud Security Console:
See also:
• Manage Roles and Permissions


Manage Account Users

As an account administrator or other user with the appropriate permissions, you can create additional account users
for your team members to enable collaboration and co-management of the Imperva service. You can also grant
different levels of permissions and sub account access to users, based on the level of visibility and control that is
required.
Note: The Cloud Security Console's new Account Users page is currently being introduced to a limited number of
direct customers (not resellers). We will provide updates in future release notes about the continued rollout. To
request access to the new page at an earlier date, contact Support.
This topic replaces the Account Users topic that describes the previous version of the Cloud Security Console's
Account Users page. The new version provides an improved user experience and enhanced management
functionality.
In this topic:
• View account users

• Add a user
• View and edit user settings
View account users
To access the Account Users page:
1. Log in to your my.imperva.com account.
The Account Users page lists the details of all users in the account: Name, Email, Status, Roles and Last login date. You
can sort, search, filter and download the users that are displayed.
Add a user
Click Add User to create a new user for the account and assign it up to 10 roles.
Note: Only the account administrator or an administrator user with the appropriate permissions can add new users.
When a new user is created in an account, a verification message is sent to the email address listed for the user. The
new user then clicks the link in the email to verify the address and set a login password.
Note:
• The user has 15 days after the user account is created to verify the email address on record before it is locked.
• When users are locked out, the account admin user receives an email notification with the list of unverified
users in the account.

• If a user that is locked out tries to log in, Imperva sends an email notification that includes a link to verify and
unlock the user account.
View and edit user settings
Click a user row to open the Settings panel. It displays the name of the user account and the date it was created.
Select multiple users to lock, delete or reset

password.
Perform bulk updates
Note: Reset password is disabled if any selected
user's status is set to Pending Activation or Locked.
Role management
Grant up to 10 roles to a selected user, providing

specific permissions to manage the account or sub
Manage roles and permissions account.
Note: User permissions in accounts created after

October 27, 2019 are managed using Roles. For
details, see Manage Roles and Permissions.
API keys
Manage API Keys
Create and manage up to 5 API keys per user. For
details, see API Key Management.
Approved log-in IP addresses
Manage approved log-in IP addresses Limit log-in access by providing a specific list of
approved IP addresses from which the user is
permitted to log in.
Actions > Lock user

Lock user
Disable a selected user from logging in to the
account and all sub accounts.
Unlock user
Actions > Unlock user

Enable a selected user to access the account and all

sub accounts, according to its defined roles and
permissions.
Actions > Set as API-only user
Define a user that only has permissions to use the

API and cannot log in to the Cloud Security Console.
This can be useful when creating users that only
require API access, such as for automation
processes.
Note:
• When enabled, the label API Only is displayed

next to the user name.
• API use is allowed according to the

Limit user to API-only access permissions of the user's assigned role.
• You cannot set this option for an external user

in your account (a user that was created in a
different account and then added to your
account). Example: A user is created in
Account A, and then added to Account B. You
can set the user as API-only in Account A, but
not in Account B.
• The API-only access is managed for the user at

the parent account level. Therefore, the user
cannot access any other accounts or their
subaccounts via login to the Cloud Security
Console.
Actions > Remove API-only restriction

Restore access to Console login
Remove a user's API-only restriction and allow the
user to log in to the Cloud Security Console.
Reset a user password

Actions > Reset Password

Reset the password for a selected user. A password

reset link is displayed onscreen, which you can then
send to the user.
Actions > Delete user
Delete a user Delete a selected user. This action cannot be

undone. The Account Admin user cannot be
deleted.
Actions > Set as account admin

Set a user as account admin
Set the role of a user (Active status) to account
admin.
Actions > Resend activation email
Resend activation email For a user with the status of Pending, Recovery or
Password Expired, send the user an email with a
link to activate the user account.
Actions > Activate user

Activate user
For a user with the status of Pending, Recovery or
Password Expired, activate the user account.
See also:
• Manage Roles and Permissions


Password Policy
The following PCI-compliant policy applies to users logging in to the Cloud Security Console.
Note: This policy does not affect organizations that log in to the Cloud Security Console via their organization's SSO.
Requirement Description

• Must include at least one of each of the
Password requirements
following: numeric character, uppercase letter,
lowercase letter, and special character
Your login password expires after 90 days. You are

then prompted to reset your password.
If the password expires, you will not be able to

administer your account and sites before changing
Maximum password age
your password.
Note: If two-factor authentication is enabled for your

user, you are not required to periodically reset your
password.
Six failed attempts to log in to the Cloud Security

Failed login attempts Console within 30 minutes lock the user out for 30
minutes.
When changing your password, you cannot use any

Reusing previous passwords
of your previous 6 passwords.
See also:
• User Preferences
• Account Users

User Preferences
The User Preferences page enables you to update your personal details, including name, email address, and
password.
You can also choose to enable two-factor authentication for your user account. When enabled, you are required to
enter a one-time passcode during login, in addition to your username and password.
Note: The Cloud Security Console's new My Profile page is replacing the User Preferences page and is currently
being introduced to a limited number of direct customers (not resellers). We will provide updates in future release
notes about the continued rollout.
For more details on the new page, see My Profile
In this topic:
• View or update user preferences

• Change password
• Enable two-factor authentication
View or update user preferences
On the top menu bar, click Account > My Profile.
Change password
Click Change Password and fill in the details.

special character
• You cannot use any of your previous 6 passwords
Enable two-factor authentication
The methods available for obtaining this passcode include:
• e-mail
• text messaging
• the Google Authenticator app
Note:
• The account admin can prohibit obtaining the passcode via e-mail.
• The account admin can also force all account users to use two-factor authentication. If that option is enabled,
users that have not yet configured it will be required to do so on their next login attempt.
• If you are an account admin and want to enforce two-factor authentication for all account users, see Account
Settings.
• Two factor authentication is not activated if the user logs in with SSO.


My Profile
The My Profile page displays your personal settings and enables you to update them.
Note: The Cloud Security Console's new My Profile page is currently being introduced to a limited number of direct
customers (not resellers). We will provide updates in future release notes about the continued rollout. To request
access to the new page at an earlier date, contact Support.
This topic replaces the User Preferences topic that describes the User Management > My Profile > User Preferences
page.
The new My Profile page offers an improved user experience and new security measures. It provides users the ability
to enable multi-factor authentication and configure additional delivery methods (i.e., Okta and phone call), view their
roles, as well as both view and add new API keys.
In this topic:
• View your personal profile

• Update your personal details
• Change your password
• Enable Multi-factor authentication
• View your roles and associated permissions
• Configure your API keys
View your personal profile
Open the My Profile page:
2. On the top menu bar, click Account > My Profile.
3. On the sidebar, click User Management > My Profile.

Update your personal details
Click Edit to update Personal details:
• First name
• Last name
• Email
• Phone number
• Additional information that you choose to include

Change your password
Click Change Password and fill in the details.


special character
• You cannot use any of your previous 6 passwords
Enable Multi-factor authentication
If Multi-factor authentication (MFA) is not already enabled in Account Settings, you can enable it for your user account.
When enabled, you are required to enter a one-time passcode during login, in addition to your username and
password.
Click Configure on any of the following factor options to display instructions on how to receive a verification code,
then enter the code and click Verify to complete its setup:
• Email (pre-configured)
• Okta Verify app
• Google Authenticator app
• Phone Call
• SMS text messaging
Note:
• The account admin can prohibit obtaining the passcode via email.
• If you are an account admin and want to enforce MFA for all account users, see Account Settings.
• If the MFA option is enabled, users that have not yet configured it will be required to do so on their next login
attempt.
• MFA is not activated if the user logs in with SSO.
View your roles and associated permissions
For any assigned role, click View role to display its enabled permissions, associated services and types.
For more details, see: Manage Roles and Permissions

Configure your API keys
Note: Users with limited permissions that can now access the new My Profile page are no longer able to access the
User Management > API Keys page.
For more details, see: API Key Management
Configure up to 5 API keys, which are dependent on their defined roles and permissions:
• Enable / Disable any API key.
• Click the ellipsis to edit a key's name and description, delete it, or click Regenerate to update its
expiration period.
• Click Add API key to configure a new key.


API Key Management
Create and manage API keys with granular permissions and sub account access, enabling you to integrate Imperva
into your environment and streamline processes. For example, you can automate security responses, integrate
dashboards and reports, or onboard new sites.
In this topic:
• Overview
• Create and manage API keys
• Examples
• API key expiration
Overview
The account administrator or a user with equivalent permissions can manage API Keys.
• API keys inherit the user's permissions and sub account access.
• Any user with the Manage API keys permission can create and manage their own API keys (up to 5 keys per user
account).
• The account admin or any user with the appropriate permissions (Manage users and permissions and Manage
API keys) can create and manage keys for all account users.
• Add a name and description to an API key to indicate what it is used for.
• Export key details. This action exports details such as user, name, description, and status in csv format. It does
not export the key itself.
Log integration: The API Key/ID which is used for logs is available on the Log Setup page only. It is not listed here.
Create and manage API keys
Add, edit, enable, disable, reset, and delete API keys.
Note: When you reset an API key, the API ID remains the same and a new key is generated that overrides the previous
one.
Account Admin or user with the appropriate permissions:
1. In the Cloud Security Console, open the Account Users page. For details, see Account Users.
2. Click a user row to open the Settings panel.

3. Click Add API Key to generate the API ID and Key.
4. Copy the details from the popup window. Once the pop up window with the generated ID & key is closed, you
will no longer be able to retrieve the key.
User with limited permissions:
Note: Users with access to the Cloud Security Console's new My Profile page can now manage their API keys on that
page. They are no longer able to access the API Keys page.
For more details, see My Profile
1. In the Cloud Security Console top menu bar, click Account > Account Management.
2. On the sidebar, click User Management > API Keys.

3. Click Add API Key to create a new key.
4. Copy the details from the popup window. Once the pop up window with the generated ID & key is closed, you
will no longer be able to retrieve the key
5. Select an option under the More column to edit, enable/disable, reset, or delete a key.
Examples
User Scenario
Reporting. This user does not require special
Marketing administrator permissions and can use an API key to get statistics
and event data for internal reporting purposes.
Site configuration. This user has permissions to
Devops engineer modify site settings and can use an API key for
automating site configuration.
Defining rules. This user has permissions to modify
site settings and can use an API key for configuring
Security engineer
rules to implement their own security, delivery, and
access control rules .
Purging the cache. This user has permissions to

modify site settings and can use an API key for
Application engineer clearing all resources in the cache after a major
change to their website, such as following a version
update.
API key expiration

When you create or reset an API key, you can set an expiration date. By default, API keys do not expire.
You can select the following time periods for expiration:
• 3 months
• 6 months
• 1 year
• Never

Grace period
• Expired API key: When an API key has expired, you can still use it for a grace period of two weeks.
• Reset API key: When you reset an existing API key, the previous key will still work for a period of two weeks from
its expiration date or from the time it is reset - whichever comes first.
• Additional reset during the two week grace period: Resetting the key more than once within the grace period
cancels any earlier key resets. The grace period is valid for the last reset only. The keys generated by previous
resets are no longer valid.
Extending the validity period of the API key
Email notifications will be sent to you before the API key expires. The email will include a link enabling you to extend
the validity of the API key for two weeks.
Read More
• Account Users

Manage Roles and Permissions

Create and manage roles to provide the appropriate level of permissions to your account users.
In this topic:
• Overview
• Create and manage roles
• Assign roles to users
• Default roles
• Migration
• Role Management API
Overview
A role is a set of permissions granting a certain level of access to Imperva cloud assets and services. Role
Management includes creating and managing roles, and assigning those roles to your account users.
For example, an application owner may need permissions to edit settings and view security events for the application,
and a member of the marketing team may need permissions to manage cache settings and purge the cache.
In addition, you can assign multiple roles to a single user. A user may require different levels of access to different
resources. For example, you may want to grant view-only permissions to a user on one sub account, and grant
administrator permissions to that user on another sub account.
Create and manage roles
Open the Roles page to create and manage roles. The Roles page is available to the account administrator or any user
with the Manage user roles permission.
2. On the sidebar, click User Management > Roles.

Click New Role. Fill in the required details and select
Create a new role
the permissions you want to grant to this role.
In the relevant row, under Actions, select Duplicate.
Copy an existing role You can edit the permissions, and save it as a new
role.
View, edit, or delete a role
In the Actions column, select an option.


Note: You cannot modify or delete the default
Administrator role.
In the Assigned users column, click the link to view

View the list of users assigned to a role
the users assigned to the role.
Note:
• The icon next to a permission indicates that the permission can apply to roles used in both parent accounts and
sub accounts.
• Permissions without the icon are relevant to parent accounts only. If it is included in a role assigned to a user in
a sub account, the user is still not granted this permission in the sub account.
Assign roles to users

You can assign roles to a user when creating the user or at a later time.
For details on creating and managing users, see Account Users.
For accounts with sub accounts:
• When you assign a role to a user at the parent account level, this grants permissions to sites and settings in the
parent account only. To grant permissions to a sub account, assign the role to the user in the sub account.
• If you do not want to grant permissions for the parent account to a user, do not assign a role to the user in the
parent account. Instead, assign a role to the user in the relevant sub account(s) only.
To view and assign roles:

2. To view and assign roles in a sub account, open the sub account.
2. On the sidebar, click Sub Accounts and then click the relevant sub account.

5. Click a user row. In the right pane, expand the Role Management section. View the role or roles already
assigned to the user, or assign a role.

Assign a role Select a role from the drop-down
View the permissions associated with the role Click
Add another role Click +
Default roles
The following roles are available out of the box. You cannot modify or delete a default role.
Role Description
Grants full permissions to the assigned user to

manage the account or sub account.
Administrator
Note: Only an Administrator or user with the
Administrator role is able to assign the Administrator
role.
Grants view-only permissions to the assigned user

Reader
for the account or sub account.
Migration
Older accounts were migrated from permission management to the new Role Management model when it was
introduced.
Roles that were created during the migration process are displayed with the name “Automatically created role” and a
role ID. For example, [3] Automatically created role. We recommend that you change the role name after migration,
assigning a name that is more meaningful for your organization.
Role Management API
Create and manage roles using the API.
For instructions on using the Audit Trail API, see Role Management API Definition.
The definition file presents a full, formatted, and interactive version of the Role Management APIs that you can use to
learn about the APIs, or test them using your API ID and key. You can also download the definition file.
See also
• Role Management API Definition

Role Management API Definition

Identity Management API Definition

Single Sign-On (SSO)

Enable your organization to log in to the Cloud Security Console via SSO. SSO provides multiple benefits, including an
improved user experience and centralized user authentication management.
Note:
• SSO is currently supported for SAML 2.0 only.
• Imperva’s SSO environment does not automatically provision users based on your IdP environment. All users
that need to log in to the Cloud Security Console using SSO must first be added as users to your Imperva
account. For details on adding users, see Account Users.
In this topic:
• Enable and configure SSO

• SAML 2.0 configuration
• Two factor authentication
• Disable SSO
Enable and configure SSO
To enable logging in to the Cloud Security Console using your organization's SSO mechanism, you must configure the
SSO settings as described here.
Only the account admin user can configure the SSO settings for your account.
When SSO is enabled:
• the account admin continues to sign in directly to the Cloud Security Console using the Imperva user and
password, bypassing SSO.
• all other account users log in via SSO.
To configure SSO for your account
Log in to your my.imperva.com account and open the SSO page:
1. On the top menu, click Account > Account Management.

2. On the sidebar, click Users Management > SSO.
Enable SSO and configure the settings. Click Save to activate SSO.
SAML 2.0 configuration
Configure the settings and then provide your identity provider (IdP) with the relevant URLs for the Imperva Cloud
Security Console (the service provider or SP).

Field Description Required
The IdP metadata file contains

configuration and integration
details for SAML 2.0 single sign-on.
Upload SAML 2.0 IdP Metadata
Upload your file to populate the
required configuration fields
automatically.
The unique entity ID from your

Identity Provider Entity ID (Issuer) identity provider. For example, Yes
https://www.idp.com/abc123.
The SAML 2.0 SSO URL from your
identity provider. For example,
Identity Provider Login URL Yes
https://www.idp.com/login/
abc123/sso.
The SAML self-signed X.509

certificate from your identify
provider. For example, -----BEGIN
CERTIFICATE----- ... -----END
Identity Provider X.509 Certificate Yes
CERTIFICATE-----
Note: SAML responses must be

signed.
Imperva URLs for your identity provider
Give the URLs listed in the Cloud Security Console to your identity provider.
Field Description
The service provider’s (Imperva Cloud Security
Assertion Consumer Service URL Console) SAML 2.0 URL responsible for receiving and
parsing the SAML assertion.
The service provider’s (Imperva Cloud Security
Audience URL (Entity ID)
Console) SAML 2.0 Entity ID.
XML metadata of the service provider (Imperva
Cloud Security Console), including details for IdP
Service Provider Metadata integration, such as entity ID, endpoints, public
X.509 certificate, information on the company, and
contact details.

Advanced Configuration
Field Description
The preferred authentication context class

(AuthnContextClassRef) for the IdP to use for
authentication.
Authentication Context Class
For more details on the specific classes, refer to the
SAML 2.0 documentation.
Default value: Password Protected Transport
The comparison attribute for the IdP to use to

determine the permitted authentication contexts.
Exact: The authentication context used must match

one of the contexts in the specified Authentication
Context Class.
Minimum: The authentication context used must

have a security level, as determined by the IdP,
equal to or higher than the contexts in the specified
Authentication Context Class.
Authentication Context Comparison Type
Better: The authentication context used must have
a security level, as determined by the IdP, higher
than the contexts in the specified Authentication
Context Class.
Maximum: The authentication context used must

have a security level, as determined by the IdP,
equal to or lower than the contexts in the specified
Authentication Context Class.
Default value: Minimum
Send the Subject element in the SAML request to

Send Subject element in SAML request
identify the authenticated user.
Optional Fields
Field Description
The SAML 2.0 response attribute key name for user's
Assertion Group Attribute Name
group membership. For example, memberOf.
Allow user login only if the SAML 2.0 response states
User's Expected Group Membership that the user is a member of the desired group,
according to the specified Assertion Group Attribute.

Field Description
For example, my_security_group. You may enter one
group name only.
Two factor authentication
Enabling SSO does not impact two factor authentication functionality for the Cloud Security Console login. If two
factor authentication is enabled for your account, the mechanism remains active when SSO is enabled.
If after enabling SSO:
• you want to enforce two factor authentication via your SSO Identity provider only, and
• you don't want to disable two factor authentication for the account admin (who bypasses SSO and continues to
log in with Imperva credentials)
then each user must disable two factor authentication in the Cloud Security Console, as follows:
In the Imperva Cloud Security Console, click the user icon and select My Profile.
Disable SSO
You can disable SSO on the Single Sign-On page:
When SSO is disabled, account users can resume logging in to the Cloud Security Console using their Imperva
credentials.
This can be useful, for example, if you are having an issue that you need to troubleshoot before re-enabling SSO.


Web Protection – Introduction

Imperva’s Web Protection is a 100% cloud based solution for protecting websites and applications from external
threats including: OWASP top 10 threats, hacking attempts, malicious bots, scraping, and DDoS attacks.
At the core of Imperva’s Web Protection are our security reverse proxy and Web Application Firewall (WAF) in the
cloud, which are deployed across our globally distributed CDN network. Organizations using Web Protection route
their website traffic through the Imperva network by performing a simple DNS change. This enables Imperva to
inspect each and every request sent to the website and filter out any kind of malicious activity.
Benefits
• PCI certified Web Application Firewall
• Service is backed by Imperva’s security team for updating and tuning security rules
• Easy and quick implementation - usually no rule tuning is required
• Bot mitigation using Imperva’s advanced client classification technology
• Backdoor Protection to identify and quarantine backdoors planted on your website
• Custom security logic using security rules
• Granular access controls based on IPs, URLs, location and client type
• Seamless implementation of two-factor authentication
• Real-time dashboard for traffic monitoring and event analysis
• REST API and SIEM integration of access and security logs
How Does Web Protection Work?
Imperva’s Web Protection is based on a network of secure reverse proxies deployed on our globally distributed
CDN. Web traffic that is routed through the Imperva network is terminated by those proxies, allowing Imperva to
inspect each and every request to the website and identify and block any malicious activity.

Organizations using Web Protection update their domain DNS to point to a unique hostname (CNAME) provided by
Imperva (e.g., mysite.incapdns.net). This hostname is dynamically resolved for every website visitor, making sure
each visitor is served by the closest Imperva data center.
Web Application Firewall
Imperva’s secure proxy and Web Application Firewall (WAF) inspect every request at three levels: the connection level,
the request format and structure level, and the content level. The WAF matches the HTTP/S requests against a set of
security engines, known attack patterns, heuristic rules, anomaly detection and known "good" patterns. Each visitor
is also profiled and matched against a large set of known client signatures. These components allow Imperva to
automatically filter out bad actors and enable organizations to define their access policy for bots.
Personal Data Protection
Imperva's reverse proxies include over 50 patterns used to recognize personal data such as credit card numbers, email
addresses, or phone numbers.
Imperva reverse proxies analyze incoming requests and search for data that matches these patterns. When a match is
found, we immediately perform irreversible masking in memory (RAM), in real-time. Logs generated in the proxy use
the masked data.
These patterns are fully configurable and can be enhanced per customer, per website. Our customers can expand the
list of patterns as needed to cover additional information that they consider to be sensitive.
The current definition and the ability to add new patterns is configured by Support.

DDoS Mitigation
Websites using Imperva DDoS Protection are protected from any type of DDoS attack, including both network (Layer 3
and 4) and application (Layer 7) attacks. Imperva’s secure HTTP proxy terminates TCP connections, acting as a buffer
between the Internet and the origin server and filtering out any kind of DDoS attack, such as SYN floods and UDP
floods. Only legitimate TCP sessions are forwarded to the origin server.
Layer 7 DDoS attacks are mitigated by a dedicated engine that can distinguish between legitimate visitors and DDoS
bots. This engine leverages Imperva’s client classification technology, as well as unique capabilities to challenge
suspected visitors and verify their authenticity, without impacting the website's normal user experience.
Security Operations Center
Imperva Web Protection is backed up by a team of security experts who are responsible for keeping the Web
Application Firewall and other security engines up to date and accurate. The research team monitors external sources
such as new vulnerability disclosures and analyzes all traffic going through Imperva. Any new attack identified on the
network is automatically analyzed, and new mitigation rules are propagated to all Web Protection customers. All rules
go through a vetting phase in which they are deployed across the network but only generate alerts. Those alerts are
analyzed by the security team and, if required, adjustments are made to make sure that new rules do not create false
positives.
Deployment
Websites that support SSL are required to provision an SSL certificate on Imperva. Imperva maintains two types of
certificates. The first is an Imperva-generated certificate that can be automatically created and integrated using the
new site wizard. Organizations using Web Protection can also upload their own certificate, which will be presented to
SNI-supporting clients instead of the Imperva-generated certificate. See Web Protection - SSL/TLS for more
information.
Web Protection can be deployed as an always-on solution (the most common scenario) or as an on-demand solution
for DDoS mitigation.
Traffic Flow
Understand the behind-the-scenes flow of an end user visit to a website protected by Imperva’s Web Protection.
Before Adding the Domain to Imperva
1. A visitor opens a web browser and types in your website’s URL (for example, http://www.yourdomain.com).
2. The web browser queries its DNS server for the IP address associated with www.yourdomain.com and receives
your origin server IP address.
3. The web browser sends requests to the origin server IP address, which are routed through the Internet to your
ISP or hosting provider.

After Adding the Domain to Imperva
1. A visitor opens a web browser and types in your website’s URL (for example, http://www.yourdomain.com)
2. The web browser queries its DNS server for the IP address associated with www.yourdomain.com and receives
the Imperva CNAME you configured in your DNS (for example, yourdomain.incapdns.net).
3. The web browser queries its DNS server for the IP address associated with yourdomain.incapdns.net and
receives the IP address of the nearest Imperva data center.
4. The web browser sends requests for http://www.yourdomain.com to the IP address of the nearest Imperva data
center.
5. The request is accepted by the Imperva secure proxy and inspected for any security risk.
6. If the request does not pose any threat, it is either responded to directly from Imperva’s cache or forwarded to
the origin server (if the resource is dynamic and cannot be cached).
7. Responses from the origin server are accepted by the Imperva secure proxy and then forwarded back to the
visitor’s web browser.
How To
• Onboarding a Site – Web Protection and CDN

Read More
• Web Protection - SSL/TLS


• Web Protection - Dedicated Network
• Bot Mitigation
• Extended Mitigation

Web Protection - Websites

View and manage your websites configured in Imperva, or add a new site.
To open the Websites page, log in to your account in the Imperva Cloud Security Console .
2. On the sidebar, click Websites.
To add a new site, click the Add website button and follow the onscreen instructions. For more details, see
Onboarding a Site – Web Protection and CDN.
The following details are displayed for each website. The statistics are generated daily and cover the last 7 days,
except for bandwidth, which covers the last 30 days.
Field Description
Name of the website. Click to drill down into the
specific website's dashboard to view incoming
Name
traffic, security events, and server activity in real-
time. Configure site settings to meet your needs.
The total amount of traffic served from your website,
Bandwidth both from the Imperva cache and from your origin
server.
Number of visits to your website by legitimate
Human Visits
human visitors, typically via a web browser.
Bot Visits Total visits by all good and bad bots.
WAF Sessions Threats to your website detected by Imperva.
Creation Date The date the site was created.
Indicates if the website is enabled, disabled, or

partially configured. Click the status icon on the
Websites page to view more details.
Fully configured:
Traffic to the website is protected and accelerated.

Status
Partially configured:
DNS is only partially configured and requires you to

take further action. The website is pointing to the
Imperva-provided CNAME but the naked domain’s A
records are not pointing to the Imperva-provided
IPs.

Field Description
Not configured:
DNS changes have not been implemented. Traffic to

the website is not completely secured. Complete the
DNS configuration to enhance the site’s security.
Disabled:
Traffic to the website is directed to your origin server

without being routed through Imperva.
• Disable/Enable a site. When a site is disabled,

DNS resolves the site's CNAME into the origin
IP address for the site instead of into one of
the Imperva PoP's IP addresses. As a result,
traffic bypasses Imperva and is routed directly
to your origin servers.
• Events. This opens the Security Events page
to display a log of security events detected by
Imperva. For more details, see View Security
Events.
• Setting. This opens the Website Settings page
to define general site attributes and options
related to security, web scraping protection,
performance, and availability of your website.
For more details, see Web Protection - Website
Settings.
• Purge Cache. This purges the entire cache of
More
the website. For more details, see Cache
Settings.
• Purge Cache Resource. This purges a subset
of the website's cached resources. For more
• Delete a site. Use this option when you want

to remove a website from Imperva.
Note:
• Before deleting a website, change

your DNS configuration back to its
original settings; otherwise you might
lose visitors.
• Deleting a site requires the following
user permissions: Modify site
settings, Add and remove sites

Field Description
• Move Site. If your account has sub accounts,
you can move a site from the parent account
to a sub account (or vice versa), or from one
sub account to another. For more details, see
Manage Account Resources.
Tip: Click Export to CSV to download the list of websites in .csv file format.
Read More


Website General Settings

View and update settings for the selected website, including data encryption, adding Imperva headers to incoming
requests, and your site's DNS settings.
Note:
• The General Settings page has been revised in order to improve the customer experience. It is available to all
users who access the new UI.
• The SSL- and HSTS-support options remain on the previous General Settings page and will be moved to a new
location at a later date. For details on the previous General Settings page, see Web Protection - General Settings.
In this topic:
• Access the General Settings

• TLS Versions
• Data Storage
• Imperva Headers
• DNS settings
• Additional Settings
Access the General Settings
To open General Settings, log in to your my.imperva.com account.

2. On the sidebar, click Websites and click a website name.
3. On the sidebar, click Origin and Network > General.
TLS Versions
In compliance with PCI-DSS requirements to disable the use of TLS 1.0, and due to known vulnerabilities in TLS 1.1,
Imperva has defined TLS 1.2 as the default minimum supported version for connectivity between clients (visitors)
and the Imperva service.
This option enables you to set support for TLS versions earlier than 1.2.
To remain PCI-compliant, do not enable this option.
Changing this option requires domain validation by the CA. Follow the instructions in the Websites page Status
column to complete the process. When CA approval is received, the change in supported TLS versions will take effect.
After the TLS change takes place, update the domain's DNS records according to the information in the DNS section of
the Websites General Settings page.
This option is available only if the account-level setting to support all TLS versions is enabled.
For more details and supported TLS versions, see Web Protection - SSL/TLS.

Data Storage
By default, Imperva assigns a region to a site based on geolocation of the origin server registered for the site. If the
account administrator changed the default region for new sites created in your Imperva account, the data storage
region for your site may be different. For details, see Account Settings.
Option Description
Determines the geographical region for storing your

Layer 7 (application layer) Imperva data. Available
regions include APAC, AU, EU, and US.
Region
If you change the data storage region, all
subsequent data is stored in the selected region. The
Events page will display only those events that
occurred after the region change.
Use the hashing method for masking fields in your

logs and in the Events page, instead of default (XXX)
data masking.
Salt value: Enter a hashing salt to use for hashing.

Mask data by hashing The salt increases the security of the hashing
process.
Type your own salt or click Generate to

automatically create one for you. The salt value is
limited to 64 characters.
Note: Event data is stored for 90 days. To view events from the previous region during that time period, click the pop-
up banner on the Events page.
If you change the data storage region twice within a 90-day period, you will no longer be able to view event data from
the first region.
Example: You changed from region A to region B and then to region C within a 90-day period. When you change to
region C, you will not be able to access event data from region A.
For more details on stored data, see Data Storage Management.

Imperva Headers
Enabling Imperva request headers adds new headers to each request sent to your origin server.
Imperva supports the following headers:

Option Description
Indicates the TLS version of the client browser and

can be used to identify visitors using old, non-
INCAP-TLS-VERSION secured browsers.
Format: TLSv1.0 ; TLSv1.1; TLSv1.2; TLSv1.3; SSLv3
Indicates a unique and persisted request ID. It can

be used to correlate requests with records in
Imperva logs, and allow debug level visibility into
INCAP-REQ-ID each request passing through the Imperva service to
the Origin.
Format: 64-bit number
DNS settings
This section displays reference information showing your original DNS settings, and the DNS records that were
provided by Imperva for onboarding your site. The instructions for changing your DNS records were provided by
Imperva.
Option Description
The DNS settings detected by Imperva during the
Original DNS Settings
initial onboarding process of the website.
The DNS settings issued by Imperva for onboarding

DNS Settings for Imperva
this website.
Links additional domains or hosts to this website

using the CNAME provided by Imperva. All DNS
queries are resolved to the primary domain.
Alternative domains / hosts (CNAME reuse)
For more details, see Alternative domains/hosts
(CNAME reuse) below.
Displays the Text records based on the specified

conditions returned by Imperva when responding to
TXT queries for your site's CNAME.
TXT records in Imperva DNS Maximum length: 255 characters.
As part of onboarding your site, you configure your

DNS settings to use the CNAME provided by Imperva.
Since DNS protocol doesn't permit other record
types when the CNAME record exists, you can't add

Option Description
TXT records directly to your domain's
DNS configuration. This section enables you to
configure TXT records while simultaneously using a
CNAME record for your domain.
For example, you can define a TXT record here for

SPF authentication in order to prevent email
spoofing.
To query additional hosts, select Add New.
Alternative domains/hosts (CNAME reuse)
This section lists all domains that are connected to an onboarded website via CNAME reuse.
Imperva detects and adds all domains that are using the Imperva-provided CNAME assigned to the onboarded
(primary) website.
Once ownership of a domain is verified, the domain is protected by Imperva and shares the website settings and
configuration of the onboarded website. Legitimate traffic for all verified domains is allowed.
You can also manually add domains to the table, as follow:
• Click Add New to add a single domain
• To add multiple domains, you can upload a file in csv format, with one domain per line. Click the arrow and click
Upload bulk CSV.
Note: The table can list up to 1000 domains.
• When this limit is passed the Add New button is disabled.

• If adding a CSV file will surpass the limit, the upload will fail and an error is displayed.
• If Imperva's autodiscovery detects additional domains and passes the limit, only 1000 domains are listed. The
list is dynamic, and the domains that most recently had traffic are listed in the table.
• You cannot detach a wildcard domain if it causes the number of domains in the table to pass the limit. For more
details on wildcard domains, see Wildcard domains.
Column Description
The name of the domain. For example,
Name
www.example.com.

Column Description
Indicates if the domain is the website that is

onboarded to Imperva, or another domain that is
sharing the CNAME provided by Imperva for the
website.
• Primary: The website that is onboarded to

Imperva.
Domain type
• Full: The domain is a full or naked domain
(not a wildcard domain).
• Wildcard: A wildcard domain, such as

*.example.com. Includes all subdomains
under the wildcard domain. For more details,
see Wildcard domains below.
Indicates that the domain was automatically

Auto-discovered
detected by Imperva.
Indicates the domain ownership verification status.
Possible values:
• Protected: Imperva has verified your

ownership of the domain and traffic to the
domain is flowing through the Imperva
network.
• Bypassed: Ownership of the domain was not

yet verified by Imperva. To enable Imperva to
verify your ownership of the domain, add the
Protected Status specified value as a CNAME or TXT record to
the domain's DNS zone.
• Misconfigured: The domain is already verified

and associated with another website
configured in Imperva.
• Verified: The CNAME value was added to your

DNS configuration as a TXT record but not as a
CNAME record. Imperva was able to verify your
ownership of the domain but traffic to the
domain is not yet flowing through the Imperva
network.

Wildcard domains
Once a wildcard domain is in Protected status, all domains that match the wildcard domain are added to the list of
allowed domains when traffic to them is detected.
You can choose to "promote" the matching domains to become full domains. On the wildcard domain row, click
and select Detach Wildcard. Each of the matching domains is then listed as a full domain and the wildcard is removed
from the table.
Website domain API
To manage alternative domains using the Imperva API, see Website Domain Management API Definition.
Additional Settings
Miscellaneous
Option Description
A free-text field where you can add a unique

identifier to correlate an object in our service, such
Reference ID
as a protected website, with an object on the
customer side.
By default, error responses are returned in

HTML format only.
Enable content based error responses This option enables you to return an error response
in JSON or XML format, based on the Accept or
Content-Type HTTP request headers. For details,
see Error Responses.
Read More


Website Domain Management API Definition

Web Protection - Website Settings

Define general site attributes and options related to security, web scraping protection, performance, and availability
of your website.
Note: If you are subscribed via an Imperva partner, your default settings are defined by the partner and may vary from
the descriptions in this documentation.
To open Website Settings, log in to your my.imperva.com account.

3. On the sidebar, click Website Settings.
The following settings pages are available:
Origin Servers: Define your site topology as Single

Origin Server, Multiple Origin Servers (Single Data
Center), or Multiple Data Centers, and allows you to
configure the load balancing settings for the defined
topology. For details, see Load Balancing Settings.
General: Define various site attributes, such as

redirection rules, SSL support, original DNS settings
and other general settings for Imperva. For details,
see Web Protection - General Settings.
Monitoring: Configure settings that determine when

origin servers are considered up or down (active or
inactive) by the Load Balancing feature. For details,
see Load Balancing Monitoring Settings.
Login Protect: Set up a two-factor authentication
solution for any website or application, without
making any changes to your website. For details, see
Web Protection - Login Protect.
Security: Configure access control rules as well as

whitelists and blacklists for your website. For details,
see Web Protection - Security Settings.
WAF: Configure WAF settings. Imperva's PCI-

Certified Web Application Firewall (WAF) analyzes all
incoming traffic to your site and prevents access by
malicious and unwanted visitors. For details, see
Web Protection - WAF Settings.

Notifications: Turn specific notifications on and off.

For details, see Website Notification Settings.
Permissions: Grant access to a user from another

account to view or edit the website. For details, see
Permissions.
Read More

Web Protection - General Settings

View and update settings for the selected website, including support for SSL and HSTS.
Note: We have rolled out a new Website General Settings page that is available to all users who access the new UI. All
Website General settings except SSL- and HSTS-support options have moved to the new page.
For details about the new General Settings page, see Website General Settings.
In this topic:
• Access the General settings

• SSL support
• HSTS support
Access the General settings
To open General Settings, log in to your my.imperva.com account.

4. Click General.
SSL support
Configure SSL support for your site, and view your site's SSL configuration status.
Option Description
Imperva generated certificate. As part of the

process of onboarding an SSL site, you add your
domain to an Imperva certificate. The Imperva
certificate is presented to visitors trying to access
your website, indicating that the connection is
secure.
Certificate Type
Custom certificate. You can add your existing
domain certificate to Imperva, in addition to the
Imperva-generated SAN certificate. This certificate is
presented to SNI-supporting clients only.
For more details on certificate types, see Web

Protection - SSL/TLS.

Certificate Status
Active. SSL support is configured for the site. If a
certificate becomes invalid, is revoked, or has some

Option Description
other error, then the status displays Active + <the
error>.
Not active. SSL support is not configured for the

site.
SSL was not detected. Imperva checked your site

for SSL, and SSL was not detected.
Other. If you have initiated the validation process,

the status is displayed according to the validation
method that you chose. For example, "Validation
email was sent to <approver email address>".
Check my site for SSL. Checks for SSL on your site.

If SSL is detected, the configure action is displayed
and you can start the configuration process.
Configure. Starts the SSL configuration process.

Follow the onscreen instructions. For more details,
see Onboarding a Site – Web Protection and CDN.
For a custom certificate, see Upload a Custom

Actions Certificate for Your Website on Imperva.
Test CAA records. Checks your domain for the

required CAA records. For more details, see CAA
Compliance.
Cancel. Cancels the configuration process.
Remove. Removes SSL support for the site.

Attempts by visitors to access your site via a secured
HTTPS connection may fail or result in browser error
messages.
You can configure the following options for Imperva to use each time the certificate is renewed.
Option Description
Add wildcard domain SAN Adds the wildcard SAN to the Imperva SSL certificate
instead of the full domain SAN.

Option Description
Example: For www.example.com, the wildcard SAN
is *.example.com and the full domain SAN is
www.example.com.
Using a wildcard SAN enables you to add

subdomains, such as sub.example.com, without the
need for a certificate change and revalidation.
Note: Typically, when your site's Imperva-generated

certificate needs to be renewed, the process is
completed automatically by Imperva. If you are
using a wildcard SAN, automated validation can only
be completed for a subdomain if the domain (e.g.
example.com) is also protected by Imperva.
Otherwise, you will receive an email notification
from Imperva requiring you to revalidate ownership
of your domain.
Adds the full domain SAN to the Imperva SSL

Add full domain SAN
certificate.

Add naked domain SAN
Example: For www.example.com, the SAN
example.com is added to the certificate in addition
to the wildcard or full domain SAN.
HSTS support
HTTP Strict transport security (HSTS) ensures that any attempt by visitors to use the unsecure version (http://) of a
page will be forwarded automatically to the secure version (https://). HSTS support is available only for sites that have
SSL support.
Imperva implements HSTS by adding a header to the page. For example:
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
There are three levels of restrictions for HSTS. Implementing all three restriction levels might not be appropriate for
all sites. Restrictions are cumulative. Each level includes enforcement of the previous level.
Option Description
(TTL) The amount of time to apply HSTS in the
Max-Age browser before attempting to load the page using
http://.
Enforce HSTS on sub-domains. For example, a page
Include sub-domains listed on xxx.ddd.com uses resources from
images.ddd.com. If HSTS for sub-domains is

Option Description
enabled, the images are also covered. Make sure
that the site and all sub-domains support HTTPS so
that HSTS does not break an internal resource when
rendering the page.
The most secure way to enforce HSTS. Ensures the
first request goes out in a secure tunnel, since the
Pre-load browser already has that URL in the pre-load list.
The domain needs to be listed at https://
hstspreload.appspot.com/.
To enable/disable HSTS support:
• For a specific SSL site: In the SSL Support section, under Strict-Transport-Security (HSTS), click Enable.
• For all new SSL sites added to your account: See Account Settings.
Read More


Web Protection - Login Protect

Login Protect adds a second level of security to sensitive URLs and websites, such as an admin login or configuration
pages, and should be used to restrict access to a limited number of admin users per site.
Note:
An application or site should have no more than 10 defined Login Protect users. Exceeding 500 Login Protect users per
account will result in performance issues.
In this topic:
• Overview
• Login Protect for Administrators
• Login Protect Users List
• Login Protect for the Authenticating User
Overview
On top of existing usernames and passwords, Login Protect adds two factor authentication based on a one-time
passcode sent to the authenticating user, without making any changes to your applications or installing any software.
The following methods are available for users to obtain one-time passcodes:
• Email
• Text message (SMS)
• Google Authenticator mobile application
Login Protect for Administrators
To open the Login Protect Settings, log in to your my.imperva.com account.

4. Click Login Protect.
If Login Protect is not yet enabled, click Enable.

Protected Pages
Protected Pages refer to sensitive pages on your website, such as an admin login page, for which you want to add an
extra layer of security.
Click on the Add Page button and select either a specific URL to protect or a URL pattern (for example, any page
whose URL ends with /admin). Any number of URLs or URL patterns may be entered, as long as they are all within the
same top-level domain (for example, all start with www.mydomain.com).
Excluded Pages
The option to exclude resources defined in the Protected Pages section from being protected by two-factor
authentication.
Example:

Protected Pages rule is : “URL is: /wp-admin “
Excluded Pages rule is : “URL is: /wp-admin/admin-ajax.php“
In this case, all resources under wp-admin will require "two-factor authentication" except from admin-ajax.php.
Methods and Notifications
This section lets you define the authentication mechanisms by which users can receive a one-time passcode.
Select one or more of the following authentication methods:
• Email: User receives an email with a one-time passcode.

• Text Message (SMS): User receives a text message with a one-time passcode.
• Google Authenticator: User can get the one-time passcode via the Google Authenticator mobile application.
Learn more about Google Authenticator here.
Authorized Users
This section lets you define which users are allowed to access Protected Pages after authentication. Login Protect
enables two methods for selecting the group of Login Protect users that will be authorized to access Protected Pages:
• Authorize all Login Protect users in this account: this option will automatically authorize all existing and
future Login Protect users, even if they are added as users on other sites.
• Select authorized users from list: this option can be used for selecting a subset of Login Protect users from the
Login Protect users list
Login Protect Users List
The Login Protect users list is an account level setting of all the Login Protect users defined for all your Imperva-
protected sites. Users can be invited via email or added as a group by uploading a CSV file.
To access the Login Protect Users List:
2. On the sidebar, click Account Management > Login Protect.

When adding users you will be prompted to review the invitation email that will be sent out and customize it if
required. You may enter multiple email addresses separated by commas or semicolons.
Login Protect for the Authenticating User

Setting Up Login Protect
Any user that has been invited to use Login Protect will receive an email (the same one you have reviewed and
customized as the administrator).

After users have clicked the activation link at the bottom of the invitation email they will be asked to configure the
methods for receiving one-time passcodes. The available methods will be determined by the Login Protect settings for
that site under Methods and Notifications.

Logging In
A user accessing a URL that is protected with Login Protect will be prompted to enter a one-time passcode using the
following screen:

Based on the Login Protect configuration for this website, users can obtain the passcode by either opening their
Google Authenticator mobile application, entering their email address to receive the passcode by email, or by clicking
the Text Me button to receive the passcode in a text message.
After entering a valid passcode, users will be able to proceed to the website. Users remain authenticated for the
remainder of their session, or for 14 days if they select the Trust this computer for 14 days option.
Users who did not complete their Login Protect user activation may do so by clicking the Didn't Activate Login
Protect? link.


Web Protection - Security Settings

Define granular access control policies for your website.
Note: Starting June 7, 2020 we are rolling out the new Policy Management feature. If your account was created after
June 7, 2020, or your existing account has been migrated, the Block Specific Sources and Whitelist Specific Sources
settings are now configured using policies. For details, see Create and Manage Policies.
In this topic:
• Access the Security settings

• Set bot access control policy
• Select CAPTCHA provider
• Block specific sources (access control / ACL)
• Define exceptions
• Whitelist specific IP sources
Access the Security settings
To open the Security Settings, log in to your my.imperva.com account.

4. Click Security.
Set bot access control policy
Bot Access Control lets you define an access control policy for each client that accesses your website.
Imperva client classification
Imperva’s unique classification technology can tell whether your website visitors are humans or bots. Our client
database holds an extensive list of bot classifications and can identify the specific type of bot visiting your website.
Each bot is marked either as a Good Bot or a Bad Bot. Bad Bots are those bots that pose a threat to your website
security. For example, a vulnerability scanner or a DDoS attack bot. Googlebot (and all other search engine bots) is
marked as a good bot and not blocked by the Bad Bots rule.

For the list of the clients and client type categories that Imperva addresses, see Client Classification.
For more details on Imperva's mitigation capabilities for automated threats, see Bot Mitigation.
Set the bot access control options
Option Description
All good bots are allowed to access your website by

default. You can customize the list of good bots from
the Bot Access Control settings.
Note: Requests from good bots are also filtered by

the WAF. This is because some legitimate services
might be manipulated to send malicious requests to
your website.
Click the Good Bots link to edit the Good Bots List.
The Good Bots List displays a list of the bots that do
not pose a threat to your website. By default, each of
these bots is marked with a checkmark, which
means that they are not blocked by default.
All Good Bots (like Google and Pingdom) will be

allowed to access your site
Note: To add additional good bots to the list, such as

your own API client or mobile app, contact Imperva
support.

Option Description
All bad bots are denied access to your website by

default. You can customize the list of bad bots from
the Bot Access Control settings. For example, you
may want to whitelist a specific vulnerability
scanner your organization subscribes to.
Click the Also block link to add to the Bad Bots List.
To add a bot to the list, start typing its name. A drop-

down menu is displayed enabling you to select from
Imperva’s predefined list of bad bots, as shown
below:
Block Bad Bots (like comment spammers and

scanners)
Only bad bots that are in Imperva’s database can be

added. If you would like to add an additional bot to
this list, contact Imperva support.
If a bot cannot be classified by Imperva, it is

considered a Suspected Bot. In many cases these
bots are operated by legitimate service providers,
Require all other suspected bots to pass additional and in some cases these are malicious bots.
challenges
You can configure Imperva to filter out any
suspected bot by requiring the client to complete a
CAPTCHA test or additional challenges. This will
filter out bad bots, reduce unnecessary load from

Option Description
unwanted crawlers and services, and ensure that
only legitimate visitors can access your website.
Exceptions See Define exceptions.

Select CAPTCHA provider
You can choose to use GeeTest CAPTCHA instead of the default reCAPTCHA.
Availability: For Advanced Bot Protection and Account Takeover Protection customers only.
By default, the GeeTest CAPTCHA is displayed in Chinese. To display the CAPTCHA in English, contact Imperva Support
to request the change.
For GeeTest, select the difficulty level for the challenge that you want to present to visitors.
GeeTest AI technology determines the appropriate

Auto
difficulty level for the visitor.
A challenge with a standard level of difficulty is
Normal
presented to the visitor.
Hard A more difficult challenge is presented to the visitor.
The most difficult challenge is presented to the
Extra Hard
visitor.

Block specific sources (access control / ACL)
Enables you to restrict traffic based on the geo-

Block Countries
location of the visitor.
Enables you to restrict traffic to specific resources /
Block URLs
URLs.
Enables you to restrict traffic based on the source IP
Block IPs
of the visitor.
Define exceptions
To add an item to the Exceptions list for any of the security rules:
1. Click Add exception, or Exceptions if there are already existing exceptions defined.
2. In the Add exception rule on field, select the type of item to be added to the whitelist, such as URL, Client app
ID, IP, or Country.

For IP exceptions, single IPs, IP ranges, and subnets are supported. For example, 2.2.2.2, 3.3.3.3-3.3.3.5, or
10.10.10.10/24.
3. In the field to the right, fill in the value to exclude from the rule.
4. Click Add.
5. You can repeat the steps above to add additional rules.
6. Click Confirm.
Note: An exception rule will match only if all match criteria are satisfied. If you want to add an exception for multiple
and non-related scenarios, you can add multiple exception rules.
Whitelist specific IP sources
This option enables you to create a list of trusted IPs that are not inspected by Imperva's WAF and Security settings
entirely. If you would like to whitelist an IP for a specific rule, it is recommended that you do that from the rule
whitelist settings (see above) rather than adding a global whitelist rule.
Read More

Web Protection - WAF Settings

Define how Imperva's Web Application Firewall (WAF) responds to malicious visitors or requests.
• We are currently rolling out the new WAF Rules policy feature. When it is enabled for your account, the related
settings are no longer available on this page. For more details, see Create and Manage Policies.
• Monitor your Cloud WAF security posture on the go. For details, see Imperva Security Mobile App.
In this topic:
• Access the WAF Settings

• Define threat responses
• Threat types
• Add whitelist rules
For DDoS settings, see Web Protection - DDoS Settings.

Access the WAF Settings
To open the WAF Settings, log in to your my.imperva.com account.

4. Click WAF.
Define threat responses
For each type of threat, you can define how the Imperva Cloud WAF responds. By default, the WAF rules are set to the
Block Request option. The only exception is the Cross Site Scripting rule, which is set to Alert Only.
Option Description
A notification is sent to your Imperva account's
administrator/user (according to the Notification
Alert Only
settings) and an alert appears in the Security Events
page. The malicious traffic is not blocked.
Malicious requests are blocked. In addition, an alert
Block Request (Default)
and an event are generated.
Any user that has attacked your website will be
Block User
blocked from sending subsequent requests for 10

Option Description
minutes. In addition, an alert and an event are
generated.
Any IP that has attacked your website will be
Block IP
generated.
The event is not listed in the Security Events page
Ignore
and no action (such as blocking) is taken.
Threat types
Threat types include:
• Backdoor Protection
• SQL Injection
• Cross Site Scripting
Backdoor Protection
This option detects and quarantines backdoors to your website.
Backdoors are widely used by hackers trying to find a way into your site for malicious purposes, such as sending
spam and participating in DDoS attacks on other websites.
Usually the first thing a hacker does after gaining access to a compromised website is to plant a backdoor that can
later be used to obtain full access to the compromised server and to its root capabilities.
Select one of the following options:
Option Description
Any detected backdoor is automatically
Auto-Quarantine (default)
quarantined.

Option Description
Alert Only administrator/user (according to the WAF Settings)
and an alert appears in the Security Events page.
Ignore
Remote File Inclusion
Remote File Inclusion (RFI) is an attack that targets the web servers that run websites and their applications. It
represents an attempt to manipulate an application into downloading or executing a file from a remote location.
RFI exploits are most often attributed to the PHP programming language, however these exploits can also manifest
themselves in other environments. RFI works by exploiting applications that dynamically reference external scripts
indicated by user input without proper sanitation.
SQL Injection
SQL injection is used to take advantage of non-validated input vulnerabilities to pass SQL commands through a
web application for execution by a backend database. Attackers take advantage of the fact that programmers often
chain together SQL commands with user-provided parameters and can therefore embed SQL commands inside these
parameters. The result is that the attacker can execute arbitrary SQL queries and/or commands on the backend
database server through the web application.
Cross Site Scripting
Cross Site Scripting (XSS or CSS) is an attack that attempts to run malicious code on your website visitor’s browser.
A Cross Site scripting attack takes advantage of a website vulnerability in which the site displays content that includes
unsanitized user-provided data. For example, an attacker could place a hyperlink with an embedded malicious script
into an online discussion forum. The purpose of the malicious script is to attack other forum users who happen to
click on the hyperlink. Such a script could, for example, copy user cookies and then send those cookies to the
attacker.

Illegal Resource Access
An Illegal Resource Access attack attempts to access otherwise private or restricted pages, or tries to view or execute
system files. This is commonly done using URL Fuzzing, Directory Traversal or Command Injection techniques.
Add whitelist rules

The Imperva Cloud WAF whitelists enable you to specify conditions under which the WAF will not analyze a request.
Any item that you enter into the whitelist is considered trusted and safe by Imperva.
Note:
• The whitelist defined for one type of WAF protection does not affect the other types of protection. For example,
whitelisted items in the SQL Injection section do not affect how Illegal Resource Access behaves.
• A whitelist rule will match only if all match criteria are satisfied. If you want to whitelist multiple and non-related
scenarios, you can add multiple whitelist rules.
To add an item to the whitelist:
1. Click the Add whitelist option under the relevant type of WAF protection. For example under the Remote File
Inclusion option. The following displays:

2. In the Add whitelist rule on field, select the type of item to be added to the whitelist, such as URL, Client app
ID, IP, Country, User Agent or HTTP parameter.
3. In the field to the right, fill in the value to be whitelisted.
4. Click the Add button.
5. Multiple rules can be added to this window by following the steps above.
6. Click the Confirm button.
Tip: You can also add an item to the WAF whitelist directly from the Security Events page if you have identified a false
positive event.
Read More

• Web Protection - DDoS Settings

Web Protection - DDoS Settings

Define how Imperva reacts to a DDoS attack on your application or website.
Note: Monitor your Cloud WAF security posture on the go. For details, see Imperva Security Mobile App.
In this topic:
• Access the DDoS settings

• Configure DDoS settings
• Advanced settings
• Add allowlist rules
• Customize Slow HTTP mitigation
Access the DDoS settings
To open the DDoS Settings, log in to your my.imperva.com account.

4. Click WAF.
Configure DDoS settings
Select the desired WAF DDoS behavior from the drop-down menu:
Option Description
Off All DDoS mitigation rules are disabled.
On All DDoS mitigation rules are enabled.
DDoS mitigation rules are activated automatically

when Imperva detects that your site is under a DDoS
attack.
If the DDoS mode is set to Automatic, Imperva only

Automatic (recommended) enables the DDoS rules when known DDoS attack
patterns are detected or the request rate for all
traffic to the site exceeds a certain threshold. The
threshold is set by default to 1,000 requests per
second, but can be adjusted using the Advanced
DDoS Settings option.

Advanced settings
Click Advanced Settings to access additional DDoS settings:
Option Description
After Imperva has determined that a DDoS attack is

underway, it challenges suspicious bots with a set of
tests to filter out any kind of malicious visitor. Except
for the CAPTCHA challenge, these challenges do not
affect the user experience.
• No Challenge: Requests from suspicious bots

are not challenged during a suspected DDos
Challenge for Unknown Clients attack. However, requests are subsequently
challenged during the regular bot mitigation
process.
• Cookie Support: Suspicious bots are
challenged for Cookie support.
• Javascript Support: Suspicious bots are
challenged for Javascript support.
• Human Interaction (CAPTCHA): Suspicious
bots are required to complete a CAPTCHA test.
Consider Site to Be under DDoS

Specifies the request rate threshold beyond which
(Request Rate) Imperva enables DDoS mitigation rules.

Option Description
Allowed values: 10-10000 requests per second.
Request rate cannot be empty.
Tip: If you are activating a marketing campaign and

expect a significant increase in traffic over a short
period of time, you may want to increase this value
so it is not considered a DDoS attack.
Note that rates above 5000 RPS are considered high.

If you are setting a high threshold to handle a
temporary increase in traffic, remember to adjust it
when traffic returns to normal.
Blocking non-essential bots is designed to overcome

attacks carried out by bots that disguise themselves
as a legitimate service that is classified by Imperva’s
client classification engine.
Block Non-essential Bots
This option should be used only in extreme
situations and after consulting with Imperva’s 24x7
support team.
Add allowlist rules

The Imperva DDoS allowlist lets you specify conditions under which the DDoS rules will not analyze a request. Any
item that you enter into the allowlist is considered trusted and safe by Imperva.
An allowlist rule will match only if all match criteria are satisfied. If you want to allowlist multiple and non-related
scenarios, you can add multiple allowlist rules.
To add an item to the allowlist :
1. In the DDoS section, click Add allowlist:
The following displays:

2. In the Add exception rule on field, select the type of item to be added to the allowlist, such as URL, Client app
ID, IP, or Country.
3. In the field to the right, fill in the value to be allowlisted.
4. Click Add.
5. Add additional rules as needed by following the steps above.
6. Click Confirm.
Tip: Alternatively, you can add an item to the WAF allowlist directly from the Events page if you have identified a false
positive event.
Customize Slow HTTP mitigation
Override default mitigation settings for slow HTTP attacks.
Slow HTTP attacks are a type of denial-of-service (DoS) attack in which requests are sent in small chunks, one at a
time. This is problematic because if the HTTP request is incomplete, or if the transfer rate is very slow, server
resources are kept busy waiting for the rest of the information, and legitimate connections cannot be made.
To prevent slow HTTP attacks, we configure a request body timeout which determines the minimal number of bytes
we accept during a specified time period.
Imperva provides DoS mitigation for HTTP methods according to the default rate of a minimum of 5000 bytes received
every 30 seconds.
You can choose to override the default rates for any or all of the following methods: GET, POST, PUT, RPC_IN_DATA,
RPC_OUT_DATA.

Note: Slow HTTP attacks are not currently displayed on the Security Events page.
To override the default rates:
1. In the DDoS section, click Slow HTTP.
2. Under Override default rate, click the toggle to enable.
3. Select the methods for which you want to set different values, and configure the values.
The custom rate will be used only for the methods that you select. Other methods continue to use the default
rate.
Read More

• Web Protection - WAF Settings

Website Notification Settings

Get email notifications about threats to your website (Imperva WAF alerts) and a weekly PCI compliance report.
For an overview of other email notifications sent by Imperva, see Notifications.
In this topic:
• Open the Notification Settings

• Get notified about threats to your website
• Request PCI compliance reports
Open the Notification Settings
4. Click Notifications.
Get notified about threats to your website
Select the types of threats to your website that you want to receive notifications about. By default, notifications are
sent per site for DDoS and Backdoor Protect security events only.
Imperva will notify you by email. A single mail is sent for all alerts occurring within a 5-minute interval. The mail will
include a sample of up to three of the generated alerts, and details of the total number of alerts and visits.
You can view the full list of threat alerts in the Website Security Dashboard > WAF violations section, and then drill
down to more detailed information displayed in the Security Events page.
What else do I need to know?
You can define what actions to take when a threat is identified (per site) in Websites > <your site> > Settings > WAF.
For more details, see Web Protection - WAF Settings.
Request PCI compliance reports
Stay informed about changes to your security rule configuration and compliance with PCI 6.6 requirements.

In accounts where the new WAF Rules policy is available, the report is slightly different. The information provided
reflects the status of the website’s security rule configuration at the time the report is generated.

Permissions
Grant access to a user from another account to view or edit the site.
The user can then see the site listed in the Cloud Security Console Websites page.
The user you add must be an existing user in another account which is on the same or higher level subscription plan.
Note: The Permissions page applies only to users from other accounts. To manage permissions for users in the current
account and its sub accounts, see Account Users.
Access the Permissions settings
To open the Permissions Settings, log in to your my.imperva.com account.

4. Click Permissions.
Add user
Click Add User and fill in the details.

Error Responses
This topic explains how error responses are returned to clients.
In this topic:
• Overview
• Response format
• Response examples
Overview
Error responses are returned to website visitors in each of the following scenarios when a request is blocked:
Error type Description

The connection between the client and Imperva
Connection timeout
timed out.
Access denied Security rules were triggered.
Imperva could not parse the HTTP request sent by
Unable to parse request
the client.
Imperva could not parse the HTTP response sent by
Unable to parse response
the origin server.
Unable to connect to origin server Imperva could not connect to the origin server.
Initial connection denied - cookie or challenge The request is sent by a cookieless visitor or requires
required an HTML challenge.
Imperva could not establish an SSL connection to
Unable to establish SSL connection
the origin server.
The request is blocked pending a CAPTCHA
Initial connection denied - CAPTCHA required
challenge.
The request is blocked pending two-factor
Initial connection denied - 2FA required
authentication.
The request is attempting to access the site via SSL
Site not configured for SSL but the site is not configured for SSL in the Cloud
Security Console.
The request is attempting to access the site with
IPv6 not enabled for the site IPv6 but IPv6 is not enabled for the site in the Cloud
Security Console.

Response format
By default, error responses are returned in HTML format.
To return error responses in JSON or XML format, based on the Accept or Content-Type HTTP request headers:
1. On the Cloud Security Console top menu bar, click Application.

3. On the sidebar, click Origin and Network > General.
4. Under Additional Settings, enable the Enable content based error responses option.
When this option is enabled, responses are returned as follows:
Request header Error response
Accept header: contains xml, does not contain html

Default XML error response

Accept header: contains xml

Default XML error response
Content-type header: contains xml
Accept header: contains json, does not contain html Default JSON error response
Accept header: contains json

Default JSON error response
Content-type header: contains json
None Default HTML response

Response examples
JSON error response
{
“incidentId” : “3411854340000000422-34793753560490",
“hostName” : “test.example.com”,
“errorCode” : “20",
“description” : “The proxy failed to connect to the web server, due to TCP connection tim
“timeUtc” : “2019-03-12 12:37:19 UTC”,
“clientIp” : “1.2.3.4",
“proxyId” : “1111",
“proxyIp” : “5.6.7.8"
}
XML error response
<?xml version=“1.0” encoding=“UTF-8"?>

<incident incidentId=“3411854340000000422-12172160812450”>
<hostName>test.example.com</hostName>
<errorCode>20</errorCode>
<description>“The proxy failed to connect to the web server, due to TCP connection timeou
<timeUtc>2019-03-12 12:37:25 UTC</timeUtc>
<clientIp>1.2.3.4</clientIp>
<proxyId>1111</proxyId>

<proxyIp>5.6.7.8</proxyIp>
</incident>
Read More
• Website General Settings


Website Dashboard
Note: The old Website Dashboard is being deprecated. The new Website Dashboards provide an enhanced view for
exploring traffic, security, and performance. For documentation on the new Website Dashboards available in the new
UI, see Website Dashboards.
View metrics and real-time data for your website activity.
Open the Website Dashboard

3. On the sidebar, click Dashboards.

Overview
Dashboard Description
Traffic Overall statistics on the traffic flow for the site.
Overview of all the threats that have targeted the

site.
Security
Note: Content has been removed. Use the new
Website Security Dashboard instead.
Performance Caching statistics for the site.

Real-Time Live monitor for activity on the site.

Dashboard Description
A display of significant events on the site, such as

Activity Log
major threat alerts, or server up/down alerts.
Tip: To filter the displayed data:
• In the Timeline drop-down, select a time range option or choose custom dates.
• Select options in the legends below the graphs.
Traffic
View overall statistics on traffic flow for the site during the selected time frame.
Section Description
Select an option. The dashboard displays data for

Timeline
the selected time range.
Each data point represents the average number of

requests per second over the last 10 minutes.
To zoom in, click and drag a section of the graph.
Total: The average number of requests per second.
Traffic (requests/sec) Passed to origin: The average number of requests

per second that were passed on to the origin server.
Cached: The average number of requests per

second that were served from the cache.
Blocked: The average number of requests per

second that were blocked.
Visits by client/country
The distribution of visits by client or country.

Section Description
For details on Imperva's client classification
database, see Client Classification.
Sessions. The average number of times the website

Visits
was accessed over the last 10 minutes.
Requests. The average number of clicks on a page
Hits per second
over the last 10 minutes.
All bandwidth used by the site.
Accumulated bandwidth Bandwidth = average of bits per second (95th

percentile) * 3600 seconds * 24 hours * number of
days in selected time frame
The average number of bits of incoming and

outgoing traffic between clients and Imperva over
Bits per second
the last 5 minutes, based on calculation of the 95th
percentile.
The average number of hits per day during the
Daily hits specified time range. View the distribution of hits by
humans, bots, or blocked hits.
The percentage of clients accessing the site with the
HTTP versions
specified HTTP version.
The list of delivery rules defined for the site.
Hits: The number of times the rule was triggered.

Delivery Rules
Action: The corresponding action taken when the
rule was triggered.
Performance
View statistics related to caching for the site during the selected time frame.
Section Description
The amount of bandwidth saved every time content
Accumulated saved bandwidth was returned from the Imperva cache, instead of
from your origin server.
The rate of change of accumulated bandwidth,
Cached bandwidth
measured in Mb or Gb.
Cached requests The percentage of content returned to the client by

the Imperva cache.

Section Description
Static only: Resources cached according to
standard caching. For more details, see the Cache
Mode section of Cache Settings.
Total: All cached resources.
The distribution of requests according to Imperva

PoPs that handled them.
Requests by data center
For details on Imperva PoPs, see Imperva Data
Centers (PoPs).
The cache mode configured for the site on the

Cache Mode Websites > Cache page, under Cache Mode. For
From the time the Imperva proxy has decided to

send a request to the origin (before opening a
connection to the origin), until the origin finishes
Average response time sending the response to the proxy.

Real-Time
Monitor activity and statistics for your site in real time.
Note: There may be discrepancies between the data displayed on the Real-Time dashboard and the other
dashboards. Full data may not always reach and be presented on the Real-Time dashboard and may therefore be less
accurate than the offline dashboards that reflect complete information.
Section Description
The traffic currently flowing to the site.
The graph refreshes every 3 seconds.
Traffic graph Overall Traffic: Overall statistics on traffic flow for

the site. Here you can monitor statistics such as
response time in real time.
Per Origin Server: The distribution of requests

according to the origin server that handled them.

Section Description
Per Data Center: The distribution of requests
according to Imperva PoPs that handled them.
For details on Imperva PoPs, see Imperva Data

Centers (PoPs).
The origin servers configured for the site.
Click the server IP address to view its data in the

Traffic graph.
If the Imperva proxies cannot connect to a server

Servers
and it is considered "Down", a red icon is displayed
next to the server.
Origin servers are defined in the Settings > Origin

Servers page. For details, see Load Balancing
Settings.
View a sampling of real time requests.
Data is measured by session.
Left pane: Use the checkboxes to filter the displayed

data.
• Top 5 <X>: Common characteristics by which

Imperva identifies the client/end user.
• Latest Actions: The action taken by Imperva in
response to the threat.
• Blocked Actions: Sessions that requests that
Visitors Sample
were blocked.
• Client Characteristics:
• None: All requests that did not
receive a valid HTTP response.
• Not Determined: All requests that do
not support cookies.
Right pane: Samples of the current requests hitting

your site.
Each row represents a session. Click More to view

additional details.
Activity Log
View significant events on the site during the selected time frame, such as:

Activity Description
Events are displayed here according to your Threat
Alert settings on the Websites > Settings
Threat alerts
> Notifications page. For details, see Website
A change was made to website settings located on

one of these pages in the Cloud Security Console:
Change in security settings • Websites > Settings > Security. For details, see

Web Protection - Security Settings.
• Websites > Settings > WAF. For details, see
Web Protection - WAF Settings.
Origin server status, according to the site's load

Server status balancer monitoring settings. For details, see Load
Balancing Monitoring Settings.

Website Dashboards
Website Security Dashboard: See an overview of all the threats that have targeted your protected websites and
applications.
Website Performance Dashboard: View caching and traffic statistics for your Imperva-protected websites and
applications.
Website Real-Time Dashboard: View overall statistics on traffic flow for your websites.
Network Traffic Dashboard: Explore incoming traffic metrics for all websites in your Imperva account. The dashboard
presents data on both legitimate and malicious (DDoS) Layer 3/4 traffic.

Website Security Dashboard

See an overview of all the threats that have targeted your protected websites and applications.
In this topic:
• Open the Security Dashboard

• Dashboard overview
• Which security events affected my websites?
• All websites
Open the Security Dashboard
1. Log in to your account in the Imperva Cloud Security Console.
3. On the sidebar, click WAF > Dashboards > Security.
Dashboard overview
Section Description
The list of all websites in your account.
To view data for multiple websites, select them from

the Assets drop-down list and click View assets.
Websites
You can select up to 5 websites at a time. Click Apply
Selection to refresh the dashboard with data on all
selected websites.
Select any time range or choose a custom range.

Time range
Data is available for the last 90 days.
The number of total and blocked requests.

Requests over time
Requests and sessions that triggered a security rule

and were blocked or triggered an alert.
Distribution
For more details, see Distribution.

Section Description
Requests and sessions that triggered a security rule

WAF sessions by violation type
and were blocked or triggered an alert.
Toggle between details of WAF rules and security

rules.
Security settings
For more details, see Security settings below.
Distribution of sessions that triggered a security rule

WAF sessions by country
by country.
Usage and security statistics for all websites in your
All websites
account. For more details, see All websites below.
Which security events affected my websites?
View statistics on requests and sessions that triggered a security rule and were blocked or triggered an alert.
Distribution
Section Description
All requests Total number of requests for the website.
Requests blocked The number of requests that were blocked.
The number of times that a security rule was

triggered.
WAF sessions
This does not include ACL Policies that were
triggered.
WAF sessions by violation type
The distribution of violations by threat type.
Security settings
Toggle details between WAF rules and Security rules.
WAF rules:
Section Description
The rule type that was triggered.

Type
Click the type name to open the Security Events
page to view the events.

Section Description
DDoS violations and Backdoor Protect: These
violations are always blocked.
Suspected bots that triggered a CAPTCHA: The

number of failed CAPTCHA challenges out of all
CAPTCHAs that were presented.
The value in the format of x/y is displayed, where:
x = the number of requests that failed the CAPTCHA

challenge
y = the number of requests that were presented with

a CAPTCHA challenge
Suspected bots that triggered a CAPTCHA are not

counted as WAF violations.
The number of sessions in which the rule was

Sessions
triggered.
The current threat response setting for the rule type.
Ignore/Enable: When the setting is not enabled,

Ignore is displayed. Click Enable to open the
website settings to change the setting.
Current setting
ACL Policies: The View policies link opens the
Policies page. If a single site is selected on the
dashboard, the link opens the website level Policy
page. If multiple sites are selected, the link opens
the account level Policies page.
Security rules:
Section Description
The name of the user-defined security rule and its

ID number, as defined on the Rules page.
Rule name
Deleted Rule: The rule was recently deleted.
Hits The number of times the rule was triggered.

Section Description
The corresponding action taken when the rule was

Action
triggered.
All websites
View statistics for all websites in your account.
The data in the websites table reflects the previous 7 days, from 00:00 on the first day to 00:00 on the 7th day,
regardless of the time range you select at the top of the dashboard.
To view data for multiple websites, select them and click Apply Selection. You can select up to 5 websites, including
those currently selected in the Websites drop-down above.
When multiple websites are selected, the dashboard displays an aggregated view of data for all the selected websites.
Tip: You can search the table for a specific host.
Column Description
Website Name of the website.
server.
Number of visits to your website by legitimate
Human visits
human visitors, typically via a web browser.
Bot visits Total visits by all good and bad bots.
The number of times that a security rule was
WAF sessions
triggered.
The percentage of requests that triggered a security
Rule hits
rule, out of all requests.
The number of requests that were presented with a
CAPTCHA challenges
CAPTCHA challenge.
Website configuration status. For more details, see
DNS Status
Web Protection - Websites.
Creation date The date the website was configured in Imperva.

Website Performance Dashboard

Note: This new dashboard introduces improved usability, faster investigation time, and more actionable data, and is
currently available to all users.
For details on the previous website dashboards, see Website Dashboard.
View caching and traffic statistics for your Imperva-protected websites and applications.
In this topic:
• Open the Performance Dashboard

• Performance and traffic
• View audit events
• Data centers
• Waiting rooms
• All websites
Open the Performance Dashboard
3. On the sidebar, click WAF > Dashboards > Performance.
Dashboard overview
The dashboard displays data for the assets and time range you select.
Zoom: Click and drag an area of a graph to zoom in. Zooming into any graph updates the data displayed on the entire
dashboard.
Section Description
To view data for multiple websites, select them from

the Assets drop-down list and click View assets.
Websites
You can select up to 5 websites at a time. Click Apply
Selection to refresh the dashboard with data on all
selected websites.

Time range

Section Description
Filter to view specific audit event types.
According to the selection, indicators are displayed

on the Cached and total bandwidth and Cached
bandwidth rate graphs at the time the logged
action occurred. By default, all types are displayed.
Hover over an indicator to view the details.
Audit events
The Imperva Audit Trail contains a log of actions

performed on your website configuration settings by
account users, system processes, and Imperva
system administrators and support. For details, see
Audit Trail.
Expand graphs
Open an enlarged view of any of the dashboard
graphs.
The total number of requests.
Requests over time Hover over the graph to display more details. Each
data point represents the average value during the
time range specified in the popup.

Section Description
Caching and traffic flow statistics for the websites in
Performance and Traffic your account. For more details, see Performance
and traffic below.
Status information on your origin data centers and
Data Centers on Imperva data centers. For more details, see Data
centers below.
Distribution of visits by country. Displays up to 7

Visits by country items, with additional items are grouped together in
the Other category.
Distribution of visits according to Imperva's client

Visits by client classification mechanism. For more details, see
Client Classification.
Lists the rule names, actions and hits for all the
delivery rules defined for the selected sites.
• Rule Name: The name of the rule and its

ID number, as defined on the Rules page.
Delivery Rules • Action: The corresponding action taken when

the rule was triggered.
• Hits: The number of times the rule was

triggered.
For more details, see Create Rules.
Usage and performance statistics for all websites in

All websites your account. For more details, see All websites
below.
Performance and traffic
View caching and traffic flow statistics for the websites in your account.
Hover over a graph to display more details. Each data point represents the time range specified in the popup.
Trend data: Shows the change between the current period and the previous period.

Section Description
Generate a report for your site to help troubleshoot

connectivity issues between Imperva data centers
Connectivity report (PoPs) and your origin servers.
For details, see Connectivity Report.
All bandwidth used by the websites.
Cached bandwidth: The amount of bandwidth

saved because requests were served from the
Imperva cache instead of from your origin server.
Total bandwidth: All bandwidth used for responses

Cached and total bandwidth served from the Imperva cache and from your origin
server.
Bandwidth is calculated as the average of bits per

second (95th percentile) * 3600 seconds * 24 hours *
number of days in the selected time frame. For more
details on the 95th percentile calculation, see
Account Bandwidth Calculation.
The percentage of content returned to the client by

Cached bandwidth rate
the Imperva cache out of all content.
Total number of requests that received responses

from the Imperva cache instead of from your origin
server.
Cached requests Static only: Resources cached according to

standard caching. For more details, see the Cache
Mode section of Cache Settings.
Total cached: All cached resources.
The number of resources requested. For example, a

single requested page can have multiple resources,
and each resource counts as a hit.
Total hits
Also show average hits per second for the specified
time frame.

Section Description
The percentage of all requests that generated errors.
Possible error types:
Client: Client errors include failed requests that do

not comply with the HTTP RFC, client TCP timeouts,
and clients closing connections.
Server: Server and application errors include failed

requests due to responses that do not comply with
Requests with errors the HTTP RFC, server TCP timeouts, server SSL
errors, and servers closing connections.
Net: Network errors include failed requests due to

origin server TCP timeouts.
Other: Other errors typically indicate issues with the

website configuration and can include requests to
unsupported ports, requests using unsupported
protocols, and requests to websites that have no
valid destination IP addresses.
Total visits The distribution of visits by human or bot.
The average number of bits per second of incoming

Bits/second and outgoing (ingress and egress) traffic passing
between clients/end-users and Imperva.
The percentage of clients accessing the websites

HTTP version
with the specified HTTP version.
View audit events

You can view audit events that took place during the selected time range.

Hover over the event in the graph to see details of the action that was performed, such as changing website settings.
For more details on audit events, see Audit Trail and Audit Trail Event Types.
Data centers
View status information on your origin data centers and servers and response time data for the Imperva data centers.
Status (Origin data center)
The status of your origin data centers and servers configured for the selected websites.
Column Description
The data center and server names or IP addresses.
Indicates the number of servers that are up out of

Data Centers
the total number of servers in the data center.
May indicate the location of the origin server.
Average response time, in milliseconds, for all

servers in the data center. It is a simple (not
weighted) average of all active servers.
Avg. Res Time
Calculated as the time the Imperva proxy has
decided to send a request to the origin (before
opening a connection to the origin), until the origin
finishes sending the response to the proxy.

Column Description
The current status of the data center or server.

Expand a data center row to the status of its servers.
Data center status:
• Up: No active incidents. All servers in the data

center are active.
• Service degradation: One or more of the

servers in the data center are down.
• Down: Service outage. All servers in the data

Current status
center are down.
Server status:
• Up
• Service degradation: Displayed only for an

origin server configured according to a
CNAME. This status indicates that one or more
of the servers using this CNAME are down.
• Down
Availability of the server over the last 7 days.

History Displays the percentage of time the server was up on
each day.
Latency (Imperva's data centers)
View the response times, in milliseconds, of the Imperva data centers that handled requests for your websites by
region. Click a location to display the distribution by data center.
Waiting rooms
View statistics on actual usage of your waiting rooms during the specified time range.
Note:
• All statistics include only those users/sessions that match all conditions set for the waiting room.
• This section is displayed only for accounts that have Waiting Rooms configured. The Waiting Room feature is
currently being rolled out and may not yet be enabled for your account.

Column Description
Click the arrow next to the name to display more

details.
Name
Click the name to open the waiting room
configuration page.
The website name and ID that the waiting room is

configured for.
Website
Displayed when multiple websites are selected.
The number of visitors waiting in the queue at the

Currently in queue
present time.
The number of users currently active on the website

Current/max active users out of the maximum number of active users
allowed.
The New incoming users activation threshold. The

Rate threshold/min number of visitors per minute that are allowed
access to the website.
Inactivity timeout Inactivity timeout, from 1 to 30 minutes.
Total user visits The total number of users who visited the website.
The number and percentage of users that left the

Users left waiting room before being sent on to the requested
page.
The number and percentage of users that were sent
Users passed
on to the requested page after waiting in line.
Graphs: Displayed when you expand a waiting room row.
The rate of new users per minute trying to access the

New users/minute
website.
Active users The number of users accessing the website over

time.

Max active users indicates the user-defined

threshold for the waiting room.
The average length of time that users waited in the

Waiting time
queue before being sent on to the requested page.
All websites
View statistics for all websites in your account.
The data in the websites table reflects the previous 7 days, from 00:00 on the first day to 00:00 on the 7th day,
regardless of the time range you select at the top of the dashboard.
To view data for multiple websites, select them and click Apply Selection. You can select up to 5 websites, including
those currently selected in the Websites drop-down above.
Tip: You can search the table for a specific host.
Column Description
Host Name and Imperva ID of the website.
Requests Total number of requests.

server.
The number of requests that received responses
Cached requests from the Imperva cache instead of from your origin
server.
The percentage of content returned to the client by
Cached bandwidth
the Imperva cache out of all content.
The overall caching policy for the selected websites,

as defined on the Cache Settings page.
Possible values: Custom, Standard, Smart, or No

Cache mode
caching.
For more details on cache modes, see Cache

Settings.
Errors The percentage of all requests that generated errors.
The average number of hits per second. Hits are

Hits/second
defined as the number of resources requested.

Column Description
The DNS configuration status of the website. For
Configuration
details, see Web Protection - Websites.

Website Real-Time Dashboard

View overall statistics on traffic flow for your websites.
In this topic:
• Open the Real-Time Dashboard

• Traffic
• Visitor samples
• Imperva data centers
• Origin servers
Open the Real-Time Dashboard
3. On the sidebar, click WAF > Dashboards > Real-Time.
Dashboard overview
Metrics are measured every 3 seconds.
Hover over a graph to view more details about any data point.
To filter the data displayed in the graphs, click items in the legends.
To open an enlarged view, click next to any graph.
Save a graph in .png format from within the enlarged view.
Section Description

Websites
The dashboard displays data for the currently
selected website.
Data on current traffic.

Traffic
For more details, see Traffic below.
Distribution data according to the Imperva data

Imperva data centers
center that handled the requests.

Section Description
Distribution data according to the origin server that

Origin servers
handled the requests.
An overview of your origin servers.
The Name column indicates the origin server IP

address, as well as the origin data center in which it
is configured.
Click a server row to view more details.
Response time: From the time the Imperva proxy

Origin server summary decides to send a request to the origin (before
opening a connection to the origin), until the origin
finishes sending the response to the proxy.
Pending requests/sec: The number of requests

received by Imperva, forwarded to the origin server,
but not yet answered.
Connections/sec: The number of open TCP

connections between Imperva and the origin server.
Traffic
View a snapshot of current traffic metrics for your websites. Drill down into more details in the graphs.
Section Description
The total number of requests from humans and
Requests
bots.
The number of requests from humans and the
Human requests
percentage out of total requests.
All bandwidth used by the site.
Bandwidth Bandwidth = average of bits per second (95th

percentile) * 3600 seconds * 24 hours * number of
days in selected time frame.
The number of requests that were passed on to your

Requests passed to origin
origin server.
The number of requests that were served from the

Requests served from cache
Imperva cache.

Section Description
The number of requests that were blocked by
Requests blocked
Imperva.
Visitor samples
To view a sampling of real time requests, click Show visitor samples at the top of the dashboard.
Each block represents a session.
Tags display the challenges presented to visitors at the time of the request (cookie, JavaScript, or CAPTCHA), and well
as the HTTP version used by the visitor.
To search the samples, enter a search string or IP address.

Imperva data centers
Real-time data according to the Imperva data centers handling the requests.
Origin servers
Real-time data on your origin servers.
Click a server row to view more details in the Details pane on the right. You can select multiple servers to view
simultaneously.

Network Traffic Dashboard

Explore incoming traffic metrics for all websites in your Imperva account. The dashboard presents data on both
legitimate and malicious (DDoS) Layer 3/4 traffic.
• Examine emerging attacks in real-time, or analyze past attacks up to 90 days back.

• View the total bandwidth volume, packet rate, traffic type, and PoP utilization.
• The displayed data reflects traffic to all websites in the account and its sub accounts.
Note: The displayed data reflects incoming traffic only (from visitors to Imperva). For CDN usage and billing statistics,
see the Subscription page for your account: Management > Subscription.
In this topic:
• Open the Network Traffic Dashboard

• Bandwidth and packet rate graphs
• Real-time data
• Historical data
• Website groups
• Advanced analytics
• Events

Open the Network Traffic Dashboard


2. On the sidebar, click WAF > Dashboards > Network.
Bandwidth and packet rate graphs
The graphs display peak bandwidth and packet rate values for the selected time period, for all sites in your Imperva
account.
Select options for viewing bandwidth and packet rate data. Your selections are reflected in the data displayed in the
bandwidth graph (bits per second) and packet rate graph (packets per second), and in the tables below the graph.
View by
Overall All traffic.
The global distribution of all incoming traffic across

Imperva PoPs.
PoP
For the list of PoP codes and locations, see Imperva
Data Centers (PoPs).
The breakdown of packet types by common

Traffic Type
protocols and attack vectors.

Traffic
Passed traffic and blocked traffic are displayed

separately in the graphs.
All
Available when viewing overall traffic only.
The sum of passed and blocked traffic is displayed

Total
as a unified graph.
Clean traffic that is routed through Imperva and
Passed
passed on to your protected sites.
Blocked DDoS traffic that was blocked by Imperva.
In the bandwidth (bits per second) graph, you can compare your data to the blue 95% percentile indicator. The
indicator is displayed when you select the following view settings:

2. Traffic > All
For more details on calculation of the 95th percentile, see Account Bandwidth Calculation.
Filter the graphs
In the legend below a graph:
Click an item to show data for that item only.
To multi-select or clear specific items from the view, use Alt+click.
To select all, double-click an item in the legend.
At the bottom of the graphs, select options to examine the data according to actual values or distribution:
Bandwidth in bps. Packet rate in

Show values
pps.
View each PoP or traffic type as a
Show distribution
percentage of the total traffic.

Real-time data
By default, the Network Traffic Dashboard displays real-time data.
Data resolution is 3 seconds.
Hover over the graph to focus in on a specific point in time. In this example, you can see that 16.87% of the total traffic
was coming in from London.
Historical data
You can view data for the previous 90-days.
At the top of the dashboard, select an option, or choose a custom time period.

The dashboard displays the maximum values reached during the selected time period.
In the graphs, you can zoom in to a maximum data resolution of 15 seconds to analyze short attacks.
To zoom in, click and drag an area of the graph.
Hover over a point in the graph for more details. In this example, the graph is now showing a resolution of 15 minutes
per point.

Grab another area of the graph to zoom in again for a closer look. Here, the maximum resolution of 15 seconds is
displayed.
Website groups
A website group is group of protected websites in your account that share a set of Imperva anycast IPs and other
network resources. (Web traffic is routed to these IPs in the Imperva network instead of to your origin server, enabling
Imperva to inspect each request and detect any malicious activity.)
Most accounts typically have only one website group. Under some circumstances, a different configuration is required
and some of your protected sites are grouped separately. For example, when using a dedicated network or when
network traffic isolation is needed to meet regulatory requirements.
To display the Website Group table:
Select View By > Overall.

• Expand the website group to view the sites included in the group. The list of sites is available only when viewing
data from a previous or custom time period. It is not available in real-time view.
• Click a Site ID to open a site’s Website Dashboard. For more details, see Website Dashboard.
Advanced analytics
See top traffic patterns for DDoS traffic on your sites that was blocked by Imperva or clean traffic that was routed
through Imperva and passed on to your origin servers.
View a breakdown of traffic by source or destination IP, by source or destination port, or by packet size for a website
group.
To display advanced network traffic analytics:
1. In the Website Group table, click a Website group name.
2. On the analytics page that opens, select a previous time period or a custom time period. (Analytics are not
displayed in real-time view.)
3. Filter to display blocked or passed traffic.
For more details on the Analytics page, see Analytics: DDoS Protection for Networks and IPs.

Events
View the log of security events detected by Imperva. Each row represents a single session that contains one or more
suspicious requests.
Filter by Event type or Time of event.
Tip: Click Export to CSV to download the event log.
Column Description
Displays time stamp 5 minutes after start of a DDoS

Time
event, or 3 hours after a DDoS event ended.
The following types of security events can appear in

the event log:
• DDoS event has started: Imperva has

detected a DDoS attack and has started
mitigation. (See SLA in the Subscription page
for further details. For more information, see
Event Subscription Status.)
A start event is generated when 30% of total

traffic within a 5-minute period is blocked. The
time stamp displayed in the log is the end of
that period. This is visualized by the below
graph, which displays clean vs. blocked traffic
within a 5-minute span. If blocked traffic (red
area) reaches 30% of the total traffic (sum of

green and red areas) in the sliding span, a

DDoS event is generated.
Note: Traffic is analyzed in two aspects: bits

per second (bps) and packets per second
(pps). The start event is generated if the 30%
threshold is reached in one or both aspects.
• DDoS event has ended: The DDoS attack has

ended. Imperva has stopped mitigation. (See
SLA in the Subscription page for further
details. For more information, see
Subscription Status.)
A stop event is generated when there is no

blocked traffic for a period of 3 hours. The
time stamp displayed in the log is therefore 3
hours after the attack ended.
Details Displays the IP address range affected by the event.
For DDoS start events, displays the location of the

first Imperva data center detected.
PoP
Note: This column has been deprecated.
Displays attack statistics. A high ratio of blocked

Total / Passed / Blocked (bps) traffic signifies volume based attacks, or attempts to
overwhelm internet bandwidth with bogus requests,
such as UDP floods, ICMP floods, and other spoofed-

packet floods. The attack's goal is to saturate the

bandwidth of the attacked website, and magnitude
is measured in bits per second (bps). A hyphen
indicates that the traffic statistic occurred prior to
the feature implementation in 2020.
Total traffic: Statistics include all traffic, including

suspicious traffic.
Passed: Legitimate traffic allowed through.
Blocked: Displays the magnitude of blocked volume

based attacks.
Displays attack statistics. A high ratio of blocked

traffic signifies network protocol attacks on server
resources or those of intermediate communication
equipment, such as firewalls and load balancers.
Measurements are in packets per second (pps). A
hyphen indicates that the traffic statistic occurred
prior to the feature implementation in 2020.
Total / Passed / Blocked (pps)
Total traffic: Statistics include all traffic, including
suspicious traffic.
Passed: Legitimate traffic allowed through.
Blocked: Displays the magnitude of blocked network

protocol attacks.
Displays traffic types, depending on type of DDoS

event detected.
• If a DDoS start event is detected, displays

Additional Info traffic type (e.g. DNS, TCP, UDP).
• If a DDoS stop event is detected, click Analyze

Attack to view additional information
recorded during the attack.

View Security Events

The Security Events page displays a log of security events detected by Imperva.
Events are created when a security rule is triggered. Rules include built-in security rules, as well as custom security
rules that you have defined for your protected sites.
The Security Events page enables you to view events per session, and then drill down into specific requests.
Note:
• You can also get a list of events using the API. For details, see Get visits in Traffic Statistics and Details API.
• Monitor your Cloud WAF security posture on the go. For details, see Imperva Security Mobile App.
• We are currently rolling out new security event infrastructure. This enhancement may not be immediately
available in your account. Once the new infrastructure is enabled for your account, you may notice the following
changes:
• Newer events are using the new infrastructure, while older events continue to be based on the previous
infrastructure. When you move from a time range that is using the old infrastructure to one that is using
the new infrastructure or back again, a pop up is displayed indicating that the page has been redirected
by Imperva. For example, if you view data for the last 7 days, and then select the option for the last 30
days, the page is redirected.
Data for all time ranges will eventually be based on the new infrastructure and available on the new
page. The page will no longer be redirected.
• The URL of the old and new page are different:
• Current page: The URL includes events-page in the path. (No change.)
• New page: The URL includes event-page-ng in the path. (Accounts rolled out with new
infrastructure will be temporarily redirected to this new path, depending on the data range
selected. After approximately 90 days of time range data has been collected, the URL redirect
will be removed.)
• When viewing an event on the new page, the Policy ID of a triggered policy is now part of the request
details. Previously, it was part of the session details. Similarly, the Edit policy option is now available at
the request level instead of at the session level.
In this topic:
• Open the Security Events page

• Security events snapshot
• View events
• View requests
• Filter the events
• Add an exception

• The three-strike rule

Open the Security Events page
To open the Security Events page:
3. On the sidebar, click Security Events.
The banner at the top of the page enables you to select the data you want to view. When you change the selections,
the data on the page is immediately updated.
Main filter Description
The websites in your account.
For an account with sub accounts:
Websites • In the parent account, all sites in the account

and all its sub accounts are available.
• In a sub account, only sites defined in the sub

account are available.
Select a time frame for the events you want to view.

Time range
Event data is available for the last 90 days.
The data storage region.
Only events stored in the currently selected storage

region are displayed. If the storage region was
changed within the past 90 days, less than 90 days'
worth of data is displayed. To view events from the
previous region during that time period, click the
Data Region
pop-up banner.
For more details on the data storage region settings

for your site, see Website General Settings.
For more details on data privacy, see Data Storage

Management.
Security events snapshot

This quick view provides an at-a-glance look at overall event classification for your site.

The statistics here reflect the last 7 days, regardless of the time period selected in the top filter.
View events
Each row under Sessions represents a single, cookie-based session that contains one or more suspicious requests.
Session details:
Field Description
The client application type.

Client Type
For more information on the client types, see Client
Classification.
Entry Page The requested URL.

Method The HTTP request method used.
Details provided by the User-Agent request header,
User Agent
such as client application name and version.
The session start time.
• Open/active sessions are displayed first.

• Closed/completed sessions are displayed after
Start Time
any open sessions.
• Within each category (open/closed), the
events are displayed in reverse chronological
order.
A unique identifier assigned to the session. This ID

can be useful, for example, for identifying events in
Session ID
SIEM integration logs, Attack Analytics, or when
contacting Support.
Policy ID The ID of the account policy that was triggered. For

more details, see Create and Manage Policies.

Field Description
If the ID is listed as deleted, this indicates that the
policy was deleted after the event occurred. For
example: Policy ID: 1234 (deleted)
Note: When viewing an event based on the new

event infrastructure, the Policy ID of a triggered
policy is now displayed under the request details.
For more details, see View requests below.
Country The country where the request originated.
The IP of the client that sent the requests.
Click the link to view IP reputation information

according to Imperva Reputation Intelligence.
Source IP
Reputation Intelligence leverages reputation data
from across the Imperva customer base and 3rd
party providers to help in incident response. For
details, see Reputation Intelligence.
Number of resources requested during the session.

For example, a single requested page can have
Hits
multiple resources, and each resource counts as a
hit.
Page Views Number of pages viewed during the session.
HTTP Version The HTTP version used in the session.
As part of the Imperva classification process, client
Cookies support for cookies, JavaScript, and other attributes
may be determined and presented here.
Indicate the suspicious behavior that was detected

in the event. For example:
Threat-type indicators Note: The Bad Bots tag does not necessarily mean
that the request came from a bad bot. It indicates
that the client was initially suspected or unknown
and was challenged, in order to verify its
authenticity.
Imperva classifies a client using a step-by-step

process. A client may be considered suspicious
during the process as we challenge it. If it passes the

Field Description
challenge it may be classified as legitimate later on
in the process.
If you have enabled the Require all other

Suspected Bots to pass additional challenges
option in the security settings for your site, Imperva
enforces a much stricter policy against unknown
clients, treating every unknown client as suspicious
by default until proven otherwise by our security
classification.
Therefore, you may see the bad bot tag that was
generated earlier on in the process, while the Client
Details column lists it as a legitimate client, such as
Chrome. The client listed in the Client Details
column is the final, authoritative classification.
You can set the following actions for the client

application detected in an event:
Modify the bot access control settings for this

website:
• Add to Bad Bots list: Add the identified bot to

the website's Bad Bots list.
• Don't block this Bot: Add the identified bot to
the website's Good Bots list.
Modify the policy that was triggered:

Set actions
• Edit Policy: Modify the ACL or allowlist policy
that was triggered. Editing a policy affects all
assets to which the policy is applied.
Note: When viewing an event based on the

new event infrastructure, the Policy ID of a
triggered policy is now displayed under the
request details. For more details, see View
requests below.
Learn more:

• Web Protection - Security Settings
Click to view details of the individual requests in the

More details
event.

View requests
Requests per event: In the event, click More details to view requests. Each row represents a suspicious request in the
session. Requests in the session that are not suspicious and do not trigger alerts are not displayed.
Request table:
Column Description
Request ID A unique identifier assigned to the request.
Threat type. Indicates the suspicious behavior that

Type
was detected in the event.
URL The page that the client requested to open.
Method The HTTP method used in the request.

Indicates if the request triggered an alert or was
Action
blocked.
Request details:
Field Description
A unique identifier assigned to the request. It can be

useful for tracking or reporting.
Incident ID
Incident IDs are listed in Imperva security messages
that are displayed to site visitors. The Incident ID is
in the format <Session ID>-<Request ID>.
Site ID Unique identifier of the protected website.
What happened as a result of the request.
For example:
Status • Client disconnected while receiving

response: The client closed the connection.
• Blocked by security rules: Imperva blocked

the request.
Query String The query string part of the request URL.

Threat Pattern The malicious pattern identified in the request.

Field Description
The ID of the account policy that was triggered. For

more details, see Create and Manage Policies.
If the ID is listed as deleted, this indicates that the

policy was deleted after the event occurred. For
Policy ID example: Policy ID: 1234 (deleted)
Note: When viewing an event based on the old event

infrastructure, the Policy ID of a triggered policy is
displayed under the session details. For more
details, see View events above.
An internal Imperva ID that identifies the rule that

Attack Codes
was triggered.
Request actions:
You can perform the following actions for an individual request. Actions affect only the website that received the
specific request.
Action Description
Add an exception to the triggered rule.
This action is displayed for requests that triggered

the following WAF rules:
• DDoS
Add exception to rule
• Backdoor protection
• Bad bots
For more details, see Add an exception below.
Add an exception to the WAF Rules policy.
Add exception to policy This action is displayed for requests that violated
the WAF Rules policy. For details, see Create and
Manage Policies.
View rule
View the triggered rule.

Action Description
custom (user-defined) rules. For details, see Manage
Rules.
Add or remove the backdoor from the backdoor

quarantine list.
Quarantine
the backdoor protection rule. For details, see Web
Filter the events

Filter the data displayed on the Security Events page using the filter pane on the right of the page.
Option Description
To apply a filter to the displayed data, make your

selections and then click Apply All at the bottom.
Apply All
If you make any changes to the filter options, you
must click Apply All again to apply the filters.
Removes all filters selected in the right pane.

Reset All
It does not affect the options selected in the top
filter bar (Assets, time period, etc.).
Add an exception
To add an exception to a rule, expand a request and click Add exception.
Note: This option is not available for all event types.
You can add an exception for a specific item in the request, such as its URL, Parameter, IP, or Country. The item then
bypasses the specific rule, such as an Illegal Resource Access violation. This rule will no longer be applied to requests
that meet your defined criteria.
Adding an exception is useful when you want to tweak a rule in order to avoid false positives. Be as specific as possible
with the criteria you define in order to limit exposure.
The three-strike rule
Imperva intelligently analyzes traffic in order to detect suspicious behavior. When a client sends repetitive, clearly
malicious requests, Imperva may block this session to prevent zero-day attacks. The 3-strike rule occurs automatically
when 3 requests in the same session trigger specific WAF rules that we have classified as extremely high-risk.


Web Protection - SSL/TLS

This topic describes how Imperva handles secure communication.
In this topic:
• SSL certificates
• The SSL process
• TLS version support
• Supported cipher suites
SSL certificates
To support secure websites (HTTPS), Imperva must host a valid SSL certificate for the website domain. Imperva
supports two types of certificates for this purpose:
Imperva-generated certificate
As part of the activation process, Imperva requires that a secure website add its domain to an existing Imperva
certificate. This certificate will be presented to any visitor trying to access your website, indicating that the connection
is secure.
The Imperva certificate is used by default for both SNI and non-SNI supporting clients. Server Name Indication (SNI) is
a TLS extension that enables a client to indicate the hostname it wants to connect to at the start of the handshake
process. Many older browsers do not support SNI. If you choose to provide us with your existing domain certificate in
addition to the Imperva certificate, your certificate is used for SNI-supporting clients, and the Imperva certificate
continues to be used for non-SNI supporting clients.
The process for adding your domain to an Imperva certificate is triggered automatically from the Add Site wizard
when you first onboard your website to Imperva, or using the Add site API. This process requires that you prove that
you are the owner of the domain you are adding to Imperva using one of three available methods:
• Email validation: A validation email will be sent to one of the email addresses associated with your domain. A
list of email addresses is displayed during the process. If the addresses are no longer in use or you wish to use a
different one, contact Support to request the change. The requested email address must be listed in your
domain’s Whois record.
• DNS validation: You will be provided with a unique DNS entry to add to your domain DNS zone.
• Meta tag validation: You will be provided with a unique HTML string to be added to one of the URLs on your
website.
If you did not complete SSL validation during the onboarding process and your site is already onboard with Imperva,
you can validate domain ownership using the email or DNS methods.
Once you have chosen a validation method and completed the validation steps, Imperva automatically adds your
domain to the Imperva certificate and provides DNS instructions. This is the final step in setting up your domain on
Imperva.
Note: If your site uses certificate pinning, it is not recommended to use an Imperva-generated certificate due to
occasional changes that are required on the Imperva side, such as certificate renewals, updates, and migrations. If
you choose to use certificate pinning, upload a custom certificate instead.

Original domain certificate (optional)
You may choose to add your existing domain certificate to Imperva in addition to the Imperva-generated certificate.
This can be done by uploading the certificate and private keys to Imperva via the Cloud Security Console. For details,
It is important to note that these uploaded certificates are presented only to SNI-supporting clients. A list of SNI-
supporting clients can be found here: https://en.wikipedia.org/wiki/Server_Name_Indication.
Which certificate does Imperva use?
The Imperva proxy first checks to see if a custom certificate was uploaded to the specific site. If one is not found, the
proxy looks at other sites in your account.
If the proxy identifies a certificate uploaded to another site in your account that has a SAN corresponding to the site in
question, then that custom certificate is used.
For example, suppose a custom certificate was not uploaded for your site support.example.com, but a certificate for
the wildcard domain *.example.com has been uploaded for another site in your account. The custom certificate for
*.example.com is used.
If you do not want the certificate for *.example.com used for your site, you need to upload a separate custom
certificate for the specific site.
If no matching certificate is located in any site in your account, the Imperva-generated certificate is used.
For websites onboarded to Imperva after October 20, 2021, the certificate selection method has changed. To optimize
the selection mechanism, the Imperva proxy now selects a certificate in this order:
3. A custom certificate from another website in your account with a SAN corresponding to the website in question.
The SSL process
HTTPS traffic arrives at Imperva, where Imperva terminates the SSL connection. It decrypts the traffic, analyzes it, and
filters out malicious visitors and requests. The next step for legitimate requests is for Imperva to return a response to
the visitor from the cache, or forward the request on to the origin server if necessary. Imperva encrypts the traffic at
this point before sending it on.
All communication between visitors <--> Imperva (Connection A) is handled by the certificates stored in Imperva.
Communication between Imperva <--> your site (Connection B) is handled by the original domain certificate located
on your web server.

Does Imperva add latency to SSL termination?
We employ the following advanced techniques, designed to speed up the process and minimize latency:
A normal SSL handshake requires 2 round trips (4

packets). Session resumption enables the client and
the server to complete an SSL handshake for
connections after the first connection (2nd, 3rd, etc)
in one round trip, by reusing some of the work done
Session resumption when the first connection was established.
Imperva supports both session identifiers and

session tickets for session resumption. Session
tickets are used if supported by the client.
Otherwise, session identifiers are used.
When establishing SSL connections, clients need to

verify the certificate presented by the server. One of
the checks the client makes is to ensure the
certificate was not revoked by its CA. In order to do
that, the client needs to contact the CA, which slows
OCSP stapling
down the connection process. OCSP allows the
server to check the revocation status of the
certificate and send it to the client as part of the
connection, so the client doesn't have to contact the
CA itself.
HTTP/2 enables a client to send multiple
simultaneous requests over a single SSL connection.
HTTP/2 The result is that the HTTP/2 enabled clients do not
need to open as many connections as HTTP/1.x
clients.
Imperva servers are optimized to run encryption
Optimized hardware related workloads by offloading some of the
encryption workload to hardware.

When traffic arrives at Imperva, can Imperva decrypt it and send me clear traffic?
No. To provide data security and meet PCI requirements, encryption is required during all legs of the journey.
Can our origin server send clear traffic to Imperva and have Imperva encrypt it before sending it back to
visitors?
No, for the same reason.
Do Imperva and your origin servers need to use the same TLS versions and cipher suites?
No. The connection between visitors <--> Imperva, and the connection between Imperva <--> your origin server are
two separate connections. Each segment can use a different TLS version and cipher suite.
TLS version support
TLS 1.3, 1.2, 1.1, 1.0, and SSLv3 are supported for connectivity between clients (visitors) and the Imperva service. TLS
1.2 is the minimum supported version, by default.
Note: As of July 1, 2022 Imperva will no longer support the SSLv3 security protocol and the RC4 cipher.
PCI-DSS v3.2 compliance
PCI-DSS compliance requires disabling the use of TLS 1.0 as of July 1, 2018. To comply with this requirement, and due
to the known vulnerabilities in TLS 1.1, Imperva has defined TLS 1.2 as the default minimum supported version. This
also applies to the Imperva Cloud Security Console and the Imperva API.
Connectivity between a website’s origin server and the Imperva service is the responsibility of the Imperva customer.
Opting out
A client with an unsupported TLS version will not be able to establish a connection to Imperva. The client (a browser,
for example) may show the following SSL error message: ERR_SSL_VERSION_OR_CIPHER_MISMATCH, and will not be
able to access the site.
If you need to keep supporting TLS v1.0 and TLS v1.1, you can opt out and choose to enable support for all TLS
versions, on a per site basis. Opting out means that clients will be able to establish connections to your site using TLS
v1.0, v1.1, and v1.2. This is not recommended. To remain PCI compliant, do not enable this option.
Choosing to enable the option to support all TLS versions may require migration of your sites to the new Imperva
service network, which offers additional security options, customization, and visibility. As a result, you may be
required to update the following:
• Update of the A-record for your domain to point to the new IPs provided by Imperva.

• Revalidation of your Imperva-generated certificate/SAN for your opted-out sites: When possible, SSL certificates
currently in use will be moved automatically to the new platform. For certificates that cannot be moved
automatically, you will be required to revalidate ownership of your domain in order to issue new SSL
certificates. This typically requires that you add the relevant authorization string in a DNS TXT record to be
viewed by the CA. You will receive instructions on how to complete the revalidation.
Note: If you want to set TLS 1.1 as the minimum supported version for your site, contact Support.
To opt out of TLS 1.2 enforcement, enable support for all TLS versions:
From the Imperva Cloud Security Console:
1. Enable the Support All TLS Versions option for the account. For details, see Account Settings.
2. Enable the Support All TLS Versions option for each site that you want to support versions of TLS earlier than
1.2. For details, see Web Protection - General Settings.
Using the API:
1. Use the Modify Account Configuration operation in Account Management API.

2. Use the Set support for all TLS versions operation in Site Management API.
Supported cipher suites
For the full list of cipher suites supported by Imperva, see Supported Cipher Suites.
Read More

View SSL Certificates

View certificate details and status for all websites in your account.
In this topic:
• Overview
• Open the SSL Certificates page
• Domains pending ownership validation
• Certificates
• SSL Certificates API
Overview
After onboarding a website to Imperva and configuring SSL support, you can view certificate status details here. This
page provides status information for the certificates configured for all websites in your account.
For more details on Imperva's SSL support for your websites, see Web Protection - SSL/TLS.
To view settings or configure SSL support after your site is onboarded, see Web Protection - General Settings.
Permissions
By default, the account admin can view the SSL Certificates page. In addition, any user who is assigned a role that
includes the View SSL Certificates permission can also view the page.
Open the SSL Certificates page
3. On the sidebar, click SSL/TLS > SSL Certificates.
Domains pending ownership validation
This section lists all the domains in your account with SANs that require validation of domain ownership.
SANs (Subject Alternative Names) are used in Imperva-generated certificates, which cover multiple domains. Each
SAN identifies a domain that is covered by the certificate. SANs that require user action are listed here.
You must complete the validation process in order for Imperva to approve your domain and include it in the Imperva-
generated SSL certificate.
Your domains are listed according to the validation method you chose when you started the process to configure SSL
support for the domain — either during website onboarding or after, through website settings.
Validate by adding DNS records
Column Description
Domain name
The domain requiring validation of ownership.

Column Description
Expand the domain name column to view the SANs
covered by the domain.
The type of DNS record used for validating domain

Type
ownership.
Depending on the specified record type, add this

value as a TXT or CNAME record to your
DNS configuration to validate ownership of the
domain.
Value
Tip: Click the copy button to copy the value string.
Imperva then verifies that the record has been

added to your DNS zone file. This may take a few
minutes.
The value for the DNS record that is used for

Record expires validation is provided to Imperva by the certificate
authority and expires after 30 days.
The validity period of the SAN is typically 1 year,

SANs expire after which you are required to revalidate domain
ownership.
Validate by email
Column Description
The domain requiring validation of ownership.

Domain name
Expand the domain name column to view the SANs
covered by the domain.
The email address you selected during website

onboarding or when configuring SSL support. An
Email address
email with a validation link was sent to this email
address.
Date of the last email sent to the specified email

Last email sent
address.

Column Description
The validity period of the SAN is typically 1 year,
SANs expire after which you are required to revalidate domain
ownership.
Certificates
The list of certificates configured for all websites in your account.
Column Description
For Imperva-generated certificates: Indicates the

certificate name and the ID of the Imperva request
to the CA. Click the down arrow to expand the row
and view all the SANs and websites covered by this
certificate. For more information, see SAN details.
Name (Order ID)
For Custom certificate: Indicates a certificate that
you have uploaded to Imperva for your website.
Click the Custom certificate link to open the
website settings to view or manage the certificate
configuration.
Custom certificate: The website for which this

Website
certificate was issued.
Imperva-generated certificate:
• Active: The certificate is in use for the specified

website.
• In progress: The current certificate in use for

the website is set to expire in the near future
and must be renewed. This certificate is being
prepared to replace the old one.
Status
• Under renewal: This certificate is in use but is
set to expire in the near future. Imperva has
started the renewal process.
Custom certificate:
• Active: The certificate is in use for the specified

website.
• Will expire soon: The certificate is set to expire

and you need to upload a new one to maintain

Column Description
SSL support. This status is activated 60 days
before the expiration date.
• Site mismatch: The certificate does not match

the website's domain.
• Expired: For secure communication, remove

this certificate and replace it with a valid
certificate.
SANs (#) The number of SANs covered by this certificate.
The certificate's expiration date.

Expiration date
Imperva-generated certificates are valid for 6
months.
SAN details
Expand a certificate row to view details on the SANs covered by the certificate.
Column Description
SAN The Subject Alternative Name (SAN).
The number of websites covered by this SAN.
Click the number to view the website names and

their Imperva IDs.
Websites covered
A wildcard SAN such as *.example.com may cover
several subdomains of example.com, such as
dev.example.com and docs.example.com.
The methods that can be used to validate ownership

of the domain. Validation may be required by
Imperva and the CA when providing or renewing an
Validation method Imperva-generated certificate.
Note: When the Automatic tag appears, no user

action is required and the SAN status is In process.
SAN status • Validated: The SAN is covered by the

certificate.

Column Description
• Approved pending publication: The SAN is
ready for publication.
• In process: You have onboarded a new site and

requested SSL support, or started the SSL
support configuration process after
onboarding. Imperva is processing the request
and checking to see if the SAN is approved by
the CA, or if it requires you to validate domain
ownership.
• Pending user action: You are required to

validate ownership of the domain. Click the
icon at the end of the row for instructions.
SAN added The date that the SAN was added to the certificate.
The date that revalidation of your domain
Revalidation required ownership will be required in order for Imperva to
renew the certificate.
Click the icon for validation instructions.

Instructions
For details, see Domains pending ownership
validation.
SSL Certificates API
Get certificate details and status for your account using the Imperva API.
For instructions on using the SSL Certificates API, see SSL Certificates API Definition.

Upload a Custom Certificate for Your Website on

Imperva
Upload your own SSL certificate to Imperva so it can be presented to your web site visitors. PFX, PEM, and CER file
formats are supported.
This certificate is presented to SNI-supporting clients only. Adding your domain to an Imperva SAN certificate is
required to handle non-SNI supporting clients, even if you are uploading your existing certificate. A list of SNI-
supporting clients can be found here: https://en.wikipedia.org/wiki/Server_Name_Indication.
The certificate must contain the full chain – root CA , intermediate CA, and the origin server certificates. For details,
see Extracting the Full Chain Certificate Using Qualys SSL Labs.
Note:
• The certificate's public key must be less than 4096 bits.
• The certificate must include the SAN for the website’s domain.
• Each time you upload a custom certificate to Imperva for your website, the Enable HTTP/2 setting on the
Website Delivery Settings page is reset according to account-level HTTP/2 default settings, located in Account >
Account Management > Account Settings. For details, see Delivery Settings and Account Settings.
The following options are available:
Option Description
Upload the current certificate installed on your

Use an existing certificate
origin server to Imperva.
Upload a certificate to Imperva that is different from

Upload a new certificate
the current certificate installed on your origin server.
Upload a certificate to Imperva that is different from
Upload a new certificate without a private key the current certificate installed on your origin server
and does not contain a private key.
Upload a certificate that is already in use for another

website, and also covers this website. You are not
required to upload the private key again.
Upload a certificate that was already uploaded to
another website, without uploading the private key
This is especially useful when the existing certificate
was generated using a CSR and you want to use it for

Permissions
The Manage custom certificates permission is required to upload, replace, and delete custom certificates for your
websites.
This permission is granted to the Account Admin user by default. The Account Admin or any user with Manage users/
Manage user roles permissions can assign this permission to other account users as needed.
Upload a custom certificate to Imperva
In the Imperva Cloud Security Console, open the Website General Settings page:
1. On the top menu bar, select Application.
2. On the sidebar, select Websites > <your site> > Website Settings > General.
3. Under SSL Support > Custom certificate, click Configure.
4. On the Configure Custom Certificate page, select one of the following options:

1. Select Use the existing certificate on your

website (default option). Imperva retrieves
and displays the details of the certificate
installed on your origin server.
2. Follow the onscreen instructions to upload

your certificate's RSA private key. PFX, PEM,
Use the existing certificate on your website
and CER file formats are supported.
You may also be required to enter a

decryption passphrase.
Imperva then validates the provided key to

verify that it matches the certificate.
1. Select Upload a new certificate.
2. In the browse window, locate and select the

SSL certificate file to upload to Imperva.
PFX, PEM or CER file formats are supported.
Do not include periods (.) in the certificate
filename.
Upload a new certificate 3. Follow the onscreen instructions to upload

your certificate's RSA private key. PFX, PEM,
and CER file formats are supported.
You may also be required to enter a

decryption passphrase.
Imperva then validates the provided key to

verify that it matches the certificate.
Prerequisite: This option is available only after

you have generated a CSR using the Imperva
Cloud Application Security API. For details on the
full process, see Upload a Certificate without a
Private Key.
1. Select Upload a new certificate without

Upload a new certificate without its private key its private key.
2. In the browse window, locate and select the

SSL certificate file to be uploaded to
Imperva. PFX, PEM or CER file formats are
supported. Do not include periods (.) in the
certificate filename.

Guidelines:
▪ The certificate must cover this website's

domain.
▪ Applies to websites directly under the same

Upload the certificate that was already uploaded parent account, or in the same subaccount.
to another website
Select the Use the certificate that was already
uploaded to another website option and follow
the onscreen instructions to upload the
certificate.
You are not required to upload the private key.
Read More
• ECC Certificate Support


ECC Certificate Support

In addition to RSA certificates, Imperva Cloud WAF now supports ECC certificates.
In this topic:
• Overview
• Upload an ECC certificate
Overview
You can upload your own ECC certificate to Imperva so it can be presented to your website visitors.
ECC certificates have a smaller key size than RSA certificates, so less data is passed to the client during the
TLS handshake. This results in faster page load times, as well as offering better support for mobile devices.
ECC certificates provide a security level comparable to or surpassing that of an RSA 2048 certificate.
Guidelines:
• Connecting clients must support ECC or the TLS handshake cannot be completed with an ECC certificate. If you
want to also support non-ECC supporting clients, upload an RSA certificate as well.
• By default, Imperva supports the prime256v1 (secp256r1) Elliptic Curve Digital Signature Algorithm (ECDSA)
only.
• Imperva presents your ECC certificate to SNI-supporting clients only. Adding your domain to an Imperva SAN
certificate is required to handle non-SNI supporting clients.
Upload an ECC certificate
Upload your certificate and private key to Imperva.
On the Web Protection - General Settings page, under SSL Support > ECC custom certificate, click Configure and
follow the onscreen instructions.
• Upload a Custom Certificate for Your Website on Imperva.


Upload a Certificate without a Private Key

This topic explains the process of uploading a custom certificate for your site to Imperva, without providing a private
key.
Remove the security overhead of managing and sending private keys over the web. Imperva manages the private key
for you, according to our security standards.
Step Description
Generate a certificate signing request using the

Create New CSR operation of the Imperva Cloud
1. Generate a CSR
Application Security API. For details. see Site
Management API.
Use the CSR content from the API response to create

a CSR file, and send it to the CA. The CA sends a
certificate without a private key back to you.
2. Send CSR file to CA
Note: The API output contains a "\n" newline
character. Before sending the CSR file to the CA,
remove the "\n" or replace it with a newline
character that works for your system.
Upload the certificate to Imperva using one of the

following:
• UI: The Imperva Cloud Security Console

General Settings page. For details, see
3. Upload certificate to Imperva
Upload a Custom Certificate for Your Website
on Imperva.
• API: The Upload custom certificate
operation. For details, see Site Management
API.

Upload a Custom Certificate with HSM Support

Upload a custom certificate for your website to Imperva, while maintaining your private key in an external key
management and encryption service.
In this topic:
• Overview
• Configure the HSM
• HSM details required by Imperva
• Upload your certificate and HSM details
• View certificate status
Overview
When you onboard a secure website to Imperva, there are two alternatives for installing SSL certificates on the
Imperva proxy servers. You can opt to have Imperva generate a new certificate for your site, or you can upload your
own custom certificate.
If you choose to use your own certificate, but regulatory requirements demand that your certificate's private key be
hosted in an HSM, you can upload own certificate without the private key while maintaining the private key in a 3rd
party cloud HSM service.
This topic describes how to upload your custom certificate to Imperva without the private key, and store your key in a
cloud HSM service instead.
Fortanix Data Security Manager (DSM) SaaS is the HSM service currently supported for this integration.
Configure the HSM
Before uploading your certificate to Imperva, you need to have a Fortanix account.
Perform the following steps to set up the Fortanix side of the integration. Refer to the Fortanix documentation for
more details: Fortanix Data Security Manager with Imperva Cloud WAF.
Note: In the event of a Fortanix outage, reliance on a single region can leave the protected site without SSL support. In
addition, if you have end-users around the world, it is recommended to enable the service across multiple regions to
optimize performance. Therefore, at least 2 regions are recommended for reliability of service.
1. Sign up for Fortanix Data Security Manager and create an account.
2. Create a group for purposes of this Imperva integration. The group will contain a collection of security objects,
such as your certificate and key, and enable you to assign access policies to these objects.
3. Create an application for Imperva Cloud WAF. The application will be used to authenticate Imperva to Fortanix
Data Security manager using an API key.
4. Create a security object and import your cryptographic key, using Base64 format.

HSM details required by Imperva

When configuring the integration on the Imperva side, you need to provide Imperva with the following details from
the Fortanix Data Security Manager:
• The URI. This is the location of your assets in the HSM service. In this case, it's the URI (host name) of the
Fortanix region as it appears in the security object. For example, api.amer.smartkey.io.
• The key ID. This is the UUID of the Fortanix security object.
• The API key. This is the REST API authentication key from the Fortanix application you created.
Upload your certificate and HSM details
To configure the integration, upload your certificate and the details of your Fortanix account using the Imperva API.
There are three API operations available for managing your certificate.
• Upload certificate: Upload your certificate and HSM credentials to Imperva. The certificate must use Base64
encoding.
• Remove certificate: Remove the certificate from Imperva.
• Test connectivity: When you upload your certificate and HSM credentials, Imperva automatically checks the
connection. If you later make changes in your Fortanix configuration, it is recommended to run this API call to
check that Imperva can still successfully connect to your Fortanix account.
For full details on the API for HSM Support, see Cloud WAF v2 API Definition.
As with all Imperva APIs, you also need to provide your Imperva API key and ID as headers in the request. For more
details, see Authentication.
View certificate status
After you upload your certificate to Imperva, you can see the status in the Cloud Security Console. It is listed on the
Website Settings > General Settings page, under SSL Support custom certificate status.
In the event that you want to remove the certificate from Imperva, you can also delete it on the General Settings
page.
See also:
• API Key Management
• Authentication


Revalidate Your Imperva Certificate

This topic describes how to complete the certificate revalidation process.
For more info on the Imperva-generated certificate, see Web Protection - SSL/TLS.
In this topic:
• Overview
• Validate ownership of your website
• Validation methods
Overview
Subject lines of the mail: "Domain revalidation required" or "Domain revalidation deadline"
It is critical to review the required action and deadline as specified in the email and take prompt action. If your
SSL.
Validate ownership of your website
3. On the sidebar, click Websites.

4. In the Status column for the relevant site, click Revalidate SSL. The Activate SSL Support page opens.
5. Select one of the methods below to validate ownership of your site:
After website ownership has been validated, Imperva starts the process of revalidating the SSL certificate for the site
via the CA. An email is sent to you from Imperva when the process is complete.
Note:
• The Revalidate SSL button is displayed until Imperva receives confirmation from the CA that the revalidation
process has completed successfully.
• If you have multiple sites that are handled by one certificate using a wildcard, the Revalidate SSL button is
displayed for each site. For example, you may have two sites named one.example.com and two.example.com,
and your certificate is configured for *.example.com. You do not need to repeat the revalidation process for the
additional sites. When the process is complete, the status for all relevant sites is updated in the Cloud Security
Console.

Validation methods
Validate your website ownership by adding a DNS record
1. Click Validate by adding DNS records (selected by default).
2. Click the Record type dropdown and select one of the following:
▪ CNAME: This option ensures automatic revalidation of the site in the future by Imperva.
▪ TXT: This secondary option is for organizations that do not allow the use of a CNAME for site validation or
do not want Imperva to automatically manage this site's revalidation in the future.
3. Log into your DNS management console and open your DNS Zone file. If you are using a DNS management
service, log into it to make the change.
Note: Field names may vary between different DNS providers.
4. Set the Record type to match what you selected from the dropdown.
5. Copy the Host string into the DNS Record name field:

CNAME example: _delegate_validation.<domain>
This defines your domain's delegation to Imperva.
TXT example:
6. Copy the Value string into the DNS Value field:
CNAME example:
TXT example:
7. On the Activate SSL Support page, click I added the records button (it will match your Record type selection).
Imperva verifies that the value of the new record(s) has been added to your DNS zone file. This may take a few
minutes.
Validating your website ownership by email
1. Click Validate by e-mail.

2. Select an email address from the drop-down menu where you want to receive the validation link. The drop-
down menu is populated with default emails for the domain (e.g. admin@, administrator@, etc.). To add emails
to this list, see Adding Emails for Ownership Validation.
You can test whether these email addresses are correct by clicking the Send a test email to all the addresses
link which sends test emails to all the listed addresses. This enables you to check whether you receive these
emails, thus indicating that the addresses are correct. The test emails sent in this manner do not contain a
validation link.
3. When you have selected an email address from the drop-down menu, click the Send button. Imperva sends the
validation email to the selected address.
4. Open the email you received and click on the validation link.
5. On the Activate SSL Support page, click the I clicked the link button to indicate that you have clicked the link
in the validation email.


Adding Emails for Ownership Validation

Website ownership is authenticated by email when onboarding a site or revalidating your Imperva certificate.
Approved emails appear in the drop-down menu on the Activate SSL Support page (Validate by e-mail). This
dynamic list contains the default emails for the domain, as provided by the CA (e.g. admin@, administrator@, etc.), as
well as emails you have added. After you select an email, Imperva sends it a validation link.
To add emails to the list for ownership validation:
• Configure each email as a DNS TXT record and place it on the "_validation-contactemail" subdomain of the
domain being validated. This subdomain is only used to store additional email addresses that will appear on
this drop-down menu.
• The entire value of this TXT record must be a valid email address, without any additional padding or structure,
as follows:
_validation-contactemail.domain.com 400 IN TXT additionalemail@domain.com.
• You can delete any added email by removing its TXT record.
• Revalidate Your Imperva Certificate

CAA Compliance
As of September 2017, the CA/Browser Forum Baseline Requirements require all Certificate Authorities (CAs) to check
for Certificate Authority Authorization (CAA) records before issuing or renewing certificates.
A CAA record enables domain owners to specify on their DNS which CAs are authorized to issue certificates for their
domain.
CAA records are not mandatory, but they are recommended. CAA use helps you limit the CAs that can issue certificates
for your domain, and can prevent unauthorized issuance of certificates.
A CA can issue certificates for domains with one of the following:
• no CAA records
• a CAA record that names the specific CA
If your DNS zone file currently contains CAA records, but does not contain a record for the CA you are requesting
a certificate from, that CA cannot issue or renew a certificate for your domain.
CAA Checking
When you onboard a new SSL site or enable SSL for an existing site, Imperva checks for CAA compliance to ensure the
successful issuing of certificates. This applies to Imperva-generated certificates (including multi-domain SAN
certificates) only.
If your domain is using CAA, make sure you have the
Before onboarding an SSL site:
CAA records required by Imperva.
1. If your domain is using CAA, make sure you

have the CAA records required by Imperva.
2. In the Imperva Cloud Security Console,
navigate to Websites > Website Settings >
Before configuring SSL for an existing site:
General.
3. In the SSL Support section, under Actions,
click Test CAA records to verify your
configuration.
To ensure a smooth renewal process at the end of a

certificate's validity period, add the required CAA
records to your DNS. If your domain is non-
For an existing SSL site:
compliant, Imperva may disable SSL support. Email
notifications are sent to you prior to any action
taken by Imperva.
Configure CAA records
Prerequisite: Your domain's DNS software or provider must support CAA.
1. Log in to your DNS management console and access your DNS zone file.

2. Do one of the following:

▪ Remove any CAA records of other CAs that are using the issue or issuewild property.
▪ Add the following records:
• CAA 0 issue “globalsign.com”
• CAA 0 issuewild "globalsign.com"

Supported Cipher Suites

The following cipher suites are supported by default by Imperva for secure communication over HTTPS.
Note:
• Imperva has defined TLS 1.2 as the default minimum supported version. If you need to support earlier versions,
you must enable the Support All TLS Versions option. For details, see the TLS version support section in Web
Protection - SSL/TLS.
• As of July 1, 2022Imperva will no longer support the SSLv3 security protocol and the RC4 cipher.
In this topic:
• Supported ciphers between visitors and Imperva

• Supported ciphers between Imperva and the origin server
Supported ciphers between visitors and Imperva
TLS 1.3
Standard Name (RFC) OpenSSL Name

TLS_AES_128_GCM_SHA256 TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256 TLS_CHACHA20_POLY1305_SHA256
TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE-RSA-AES128-SHA
TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256 AES128-SHA256
TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA


TLS_RSA_WITH_CAMELLIA_256_CBC_SHA CAMELLIA256-SHA
TLS 1.1 and 1.0

Supported ciphers between Imperva and the origin server
Imperva proxies connect to the origin server declaring support for TLS 1.3.
If the origin server chooses an earlier TLS version, the proxy will accept it.
When TLS version 1.2 or earlier is chosen by the origin server, it can use ciphers from the TLS 1.2 list below that are
available in the TLS version chosen.
TLS 1.3

TLS_CHACHA20_POLY1305_SHA256 TLS_CHACHA20_POLY1305_SHA256
TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDHE-ECDSA-AES256-SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDHE-ECDSA-AES256-SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ECDHE-ECDSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE-ECDSA-AES128-SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE-RSA-DES-CBC3-SHA


TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE-ECDSA-DES-CBC3-SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDHE-RSA-RC4-SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ECDHE-ECDSA-RC4-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE-DSS-AES128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
TLS_RSA_WITH_RC4_128_SHA RC4-SHA
TLS_RSA_WITH_RC4_128_MD5 RC4-MD5
See also:

Client Certificate Support

If your site needs to support client certificates, you can upload your CA certificate to Imperva and configure your
websites to use it.
Note:
• Client certificates are supported for websites configured in Imperva for SSL and using a custom certificate.
• Client certificates are supported for SNI clients only. We do not support client certificates for non-SNI clients.
• Client certificates are supported per domain, not per URL.
In this topic:
• Overview
• Configure client certificate support
• Client certificate validation using a CRL
• Certificate Manager API
Overview
The growing distribution of mobile apps, smart cards, and electronic IDs means you may need to implement a higher
level of protection, such as two-factor authentication.
In addition, IoT services may rely on embedded client certificates on end devices to validate device authenticity.
For example, Imperva client certificate support enables you to:
• Use X.509 smart card certificate identification

• Apply a second factor of authentication
• Validate device authenticity and avoid forgery
• Validate the authenticity of the mobile app used to access your website
Configure client certificate support
Upload your client CA certificate to Imperva and configure your websites to use it.
For detailed instructions, see Configure Client Certificate Support.

Client certificate validation using a CRL
Once client certificate support is enabled for your site, you can upload a Certificate Revocation List (CRL) file to verify
whether certificates are valid and trustworthy. For details, see Upload a CRL.
Certificate Manager API
You can also upload and manage client certificates and CRLs via the API. For details, see Certificate Manager API.

See also:
• Configure Client Certificate Support


Configure Client Certificate Support

To support client certificates, upload your client CA certificate to Imperva and configure your websites to use it.
Note: To learn more about Imperva client certificate support, see Client Certificate Support.
In this topic:
• Overview
• Open the Client CA Certificates configuration pages
• Upload a CA certificate to your account
• Assign a certificate to a website after upload
• Configure client certificate support settings
• View certificate details
• Send client certificate details to origin server
Overview
To configure client certificate support for a website:
1. Upload a CA certificate to your account.

2. Assign the certificate to websites in your account.
3. Configure optional client certificate support settings for your websites.
Note: When you first assign a certificate to a website, the client certificate is not required by default, and traffic
is still permitted to access the site without presenting the client certificate. To require the client certificate for
the TLS handshake, see Configure client certificate support settings .
Guidelines:
• The certificate must be in PEM format. Supported file extensions include .pem, .crt, and .cer.
• The “Basic Constraints” section of the certificate must indicate that this is a CA certificate, as shown in this
example.
• If more than one certificate is used for signing, they should be concatenated.
• If the certificate is a sub certificate, the entire certificate chain is required.
• If the certificate is signed by a recognized CA, it must include the chain up to but not including the root
certificate.

• If the certificate is self-signed by the site owner's CA, the full chain must be provided including the root
certificate. If the certificate is signed by the root itself, no chain is required.
• We recommend that the file you upload contains only one certificate.
• You can add up to 1000 CA certificates to your account.
• You can assign up to 120 certificates per site.
Permissions:
By default, the account admin user can manage client CA certificates for the account and websites in the account.
Other users can be granted the following permissions as required:
• Manage client CA certificates for account

• Manage client CA certificates for sites in a sub account
The Client CA Certificates pages are displayed only to users with the appropriate permissions.
Open the Client CA Certificates configuration pages
The Client CA Certificates pages enable you to manage the certificates for your account and websites.
Account-level. The account-level Client CA Certificates page enables you to upload your client CA certificates and
then assign them to websites in your account.
1. Open the Account Management > SSL/TLS > Client CA Certificates page.
2. Click More > Edit for a certificate and modify the list of assigned websites.
Website-level. The Client CA Certificates page located within settings for a specific website enables you to view the
certificates assigned to the website, or assign a certificate from the account to the website.
1. In the Application area, select a website.
2. Under SSL/TLS, click Client CA Certificates.

Upload a CA certificate to your account
Upload the CA certificate that is used to sign all client certificates. Then assign it to websites in your account.
For accounts with sub accounts: You can upload a client CA certificates to the parent account only. You can then
assign the certificate to any website in the account or in any of the account's sub accounts.
To upload a certificate, open the account-level Client CA Certificates page and click Upload New.
Option Description
Uploaded file The file name of the uploaded certificate file.
Name Give a descriptive name to the certificate.
Assign to websites
Assign this certificate to the selected websites.

Option Description
The drop-down includes all websites in the account
that are configured for SSL and using a custom
certificate.
Assign a certificate to a website after upload

To assign a certificate to websites after the upload process, or change the assigned websites, do one of the following:
• On the account-level Client CA Certificates page, click More > Edit for a certificate and modify the list of
assigned websites.
• On the website-level Client CA Certificates page, click Assign and select a certificate from the drop-down.
Configure client certificate support settings
Configure client certificate support settings for a website on the website-level Client CA Certificates page, under
Configuration Settings.
Note: These settings apply to all certificates assigned to the website.
Option Description
When enabled, the end-user is required to present

the certificate during the initial TLS handshake in
Require client certificate order to access the site.
By default, the client certificate is not required.
If client authentication is also required, the

authentication information can be sent to your
origin server. The information is sent in a header
added by Imperva to the client request before it is
sent on to the origin server.
When enabled, the contents specified under Header

value are sent to the origin server in the header
specified under Header name. By default, set to
Send client certificate details to origin server false.
Header name: The name of the header to send

header content in. By default, the header name is
clientCertificateInfo.
Header value: The content to send in the header

specified in the Header name field. Options include:
• Full client certificate: The full CA certificate in

Base64 (ASCII).

Option Description
• Fingerprint: The CA certificate's fingerprint in
SHA1.
• Common name: The CA certificate's common
name (CN).
• Serial number: The CA certificate's serial
number.
Note: For more details, see Send client certificate

details to origin server below.
Enable and/or disable client certificate support on

specific hosts and ports.
Enter the specific hosts or ports on which to enable

or disable the feature.
Restrict client certificate support
For multiple hosts or ports, enter a comma-
separated list.
If left blank, client certificates are supported for all

hosts/ports.
To limit access, you can provide the SHA fingerprint

of specific client certificates.
Restrict client certificate fingerprints If left blank, all fingerprints are accepted.
For multiple fingerprints, enter a comma-separated

list.
View certificate details

You can view details for client CA certificates on the Client CA Certificates page in your account or website.
• The account-level Client CA Certificates page displays all client CA certificates uploaded to your account.
• The website-level Client CA Certificates page displays all client CA certificates assigned to the website.
Column Description
(Optional) The user-provided name for the

certificate.
Name
If a name is not provided, the file name of the
uploaded certificate is used by default.
Serial Number The certificate's serial number.

Column Description
The name of the Certificate Authority (CA) that
Issuer
issued the certificate.
Valid From The first day of the certificate's validity period.
Valid To The last day of the certificate's validity period.
The date the certificate was uploaded to the

account.
Creation Date
Available from: Account-level page only.
Enables you to rename the certificate, or change the

websites to which the certificate is assigned.
Edit (under More)
Available from: Account-level page only.
Account-level page: Deletes the certificate from your

account.
Note: You cannot delete a certificate from the

Delete (under More)
account when it is assigned to websites.
Website-level page: Removes the certificate from the

specific website.
Send client certificate details to origin server

In this section:
• Send client certificate details to origin server

• Sending additional client parameters to the origin server
• Convert header details into a certificate object
Send client certificate details to origin server
If client authentication by the website is also required, Imperva can send the authentication information to your
origin server in a request header. For details, see Configure client certificate support settings above.
Sending additional client parameters to the origin server
If you need to pass additional client parameters to the origin server, and your service plan includes Delivery Rules, you
can create delivery rules and use the following variables. If not, the Support team can implement it for you.
For more details on using these variables in delivery rules, see Create Rules.

Convert header details into a certificate object
After you receive the client certificate information, you can convert it into a certificate object.
Here is an example using ASP.NET code:
byte[] clientCertBytes = Convert.FromBase64String(certHeader);

certificate = new X509Certificate2(clientCertBytes);
Here is an example using Java code:
byte[] clientCertificateBytes = Base64.getDecoder().decode(certHeader);

certificate = CertificateFactory.getInstance("X.509").generateCertificates(new ByteArrayInpu
See also:

• Upload a CRL

Upload a CRL
If client certificate support is enabled for your site, you can upload a Certificate Revocation List (CRL) file to verify
whether certificates are valid and trustworthy.
Note: To learn more about client certificate support, see Client Certificate Support.
In this topic:
• Guidelines
• Upload a CRL file
Guidelines
• The CRL file must be in PEM format, using Base64 encoding.
• The CRL file cannot be larger than 1MB.
• You can upload multiple CRLs per site.
• You cannot upload multiple CRL files to a site that include the same issuer.
• To replace an existing CRL, delete the CRL file and upload a new one.
Upload a CRL file
For instructions on uploading a CRL file, see the Certificate Manager API.
The Certificate Manager API definition file provides a full, formatted, and interactive version of the Certificate Manager
API that you can use to learn about the API, or test the APIs using with your API ID and key. You can also download the
definition file.

Certificate Manager API

Upload and manage CA certificates and CRL files for your account to use for client certificate support.
In this topic:
• Client certificate APIs

• CRL APIs
• Certificate Manager API Definition
Client certificate APIs
If your site needs to support client certificates, you can use the API to upload your CA certificate to your Imperva
account, and then configure your websites to use it.
CRL APIs
If client certificate support is enabled for your site, you can use the API to upload a Certificate Revocation List (CRL)
file to verify whether certificates are valid and trustworthy.
Certificate Manager API Definition
For instructions on using the Certificate Manager API, see Certificate Manager API Definition.
The definition file presents a full, formatted, and interactive version of the Certificate Manager APIs that you can use
to learn about the APIs, or test them using your API ID and key. You can also download the definition file.
See also:
• Configure Client Certificate Support

• Upload a CRL

Certificate Manager API Definition

Create and Manage Policies

Create policies to centrally configure settings and apply them to multiple websites in your account.
Note:
• We are currently rolling out the new WAF Rules policy type. It may not yet be available in your account.
• Starting in March 2022, website WAF settings in existing customer accounts will be migrated to the new
WAF Rules policy over a period of several months. (Migration of an individual account takes only several
minutes.)
• The migration process takes the WAF settings (located on the Application > Websites > Website
Settings > WAF page) that were configured for your websites and automatically converts them to
policies.
• If multiple websites contain identical settings, a single policy is created and assigned to the relevant
websites.
For more details on the migration process, see FAQ: WAF Settings Migration.
For more details on the WAF Rules policy, see WAF Rules policy below.
In this topic:
• Overview
• Create a policy
• Policy types
• Upload IP addresses in bulk
• Add an exception
• Apply a policy to websites
• Set a policy as default
• View and manage policies
• Policy Management API
Overview
Manually configuring a large number of sites can be resource-intensive, time-consuming, and error-prone. Policy
Management introduces the ability to centrally configure and manage settings, save them as a policy, and then apply
the policy to multiple sites in your account.
At the account (or sub account) level:
• Create up to 1,000 editable policies

• Apply policies to websites in the account
• Set a policy as default to apply it automatically to all new websites created in the specified account
At the website level:

• View and edit policies applied to the website

• Apply policies to the website
• Remove policies from the website
Policy types
Imperva offers several types of policies. Each type covers a specific area of Imperva functionality, such as access
control lists (ACLs) or Allowlists, and has its own set of specific fields available to configure. For details, see Policy
types.
Permissions
By default, the account admin user can manage policies for the account and for websites in the account. The following
permissions can be added to roles and assigned to other users in the account or in its sub accounts as required.
• View policy
• Add/Duplicate policy
• Edit policy
• Delete policy
• Add exception to policy
• Edit exception in policy
• Delete exception from policy
• Apply policy to assets
The Policies pages are displayed only to users with the appropriate permissions.
Create a policy
In the Cloud Security Console:

3. Click Create Policy.
Note: You can create a maximum of 1,000 policies.
General tab
Select the type of policy you want to create and fill in the details.
Field Description
Policy Name A descriptive name for the policy.
Description Optional.
Activates or deactivates the policy for all specified

assets (websites).
Enable Policy
Note: WAF Rules policies are created in the enabled
state and cannot be disabled.

Field Description
Policy Type Select a policy type. For details, see Policy types.
Configuration tab
The fields available for configuration in the policy vary based on the policy type that you select. For details on the
available policy types and their fields, see Policy types below.
Applied on tab
Apply the policy to assets, or restrict access to the policy.
Field Description
This option is available in the account-level page

only.
By default, the policy is available for the parent

(root) account and all of its sub accounts.
You can opt to make the policy available only to

specific sub accounts in your account or only to the
parent account.
• When a policy is available for a sub account, it

can be viewed and applied on the Policies
page in the sub account and in its websites.
• Only assets related to the selected sub
accounts are displayed in the Apply to assets
Available for and Enable as default policy sections.
• If a specific sub account is not selected, the
policy is not listed on the Policies page in the
sub account and in its websites, and cannot be
applied.
Note: If you opt to select specific sub accounts, or

make a change to the list of selected sub accounts,
the assets available under the Apply to assets and
Enable as default policy sections are updated
accordingly.
For example, if the policy was applied to sites under

"sub account A" and you remove "sub account A",
the policy is removed from the websites in "sub
account A" to which it was applied.

Field Description
Applies the policy to the selected assets (websites).
When creating a policy in an account that has sub

accounts, the list of available assets includes sites in
Apply to assets the account and sites in all of the account's sub
accounts.
When creating a policy in a sub account, only sites in

the specific sub account are displayed.
Automatically applies the policy to all new websites

created in the account and/or in the account's sub
Enable as default policy accounts.
For more details, see Set a policy as default.
Policy types
Each policy type covers a specific area of Imperva functionality. When you create a policy, the fields available for
configuration vary based on the policy type.
Policy types are categorized as one of the following:
• Simultaneously applied policies: (ACL and Allowlist policies): Multiple policies of these types applied to a
single website. For example, two ACL policies can be assigned simultaneously to the same website.
• Individually applied policies: (WAF Rules policy). Only one policy of this type can be applied to a single
website. If another individually applied policy is applied to the same website, it replaces the policy currently
applied to the website.
ACL policy
Block specific countries, URLs, or IPs from accessing your sites. In each of the sections, you can click
to add an exception to the policy. For more details, see Add an exception below.
Field Description
Restricts traffic based on the geo-location of the

visitor. You can block one or more countries by
clicking inside or searching within the Add country
Block Countries
field and selecting the relevant continent or country
from the list.
Note:

Field Description
• Contiguous transcontinental countries, such
as Russia and Turkey, span more than one
continent. At Imperva, Russian Federation and
Turkey appear in the drop-down for Europe,
and not Asia. Nevertheless, selecting the
country will block the country's traffic across
all of its continents. For example, although
Turkey appears under the Europe drop-down
selection, selecting Turkey also blocks Asian
Turkey.
• If you want to block a continent that contains

a transcontinental country, it doesn't block
the country in another continent. For
example, selecting Europe will block only IPs
that are within the European continent. To
block all of Europe, including the Asian parts
of Turkey, create a policy that blocks Europe,
and another policy that blocks Turkey. Then
apply both policies.
Restricts traffic to specific resources / URLs (up to

Block URLs
150 URLs per policy).
Restricts traffic based on the source IP of the visitor.

You can block up to 20,000 IPs per policy.
Block IPs
Single IPs, IP ranges, and subnets are supported. For
example, 2.2.2.2, 3.3.3.3-3.3.3.5, or 10.10.10.10/24.
Allowlist policy
Add a list of trusted IPs that are not inspected by Imperva's WAF and Security settings.
If you would like to add an IP to an allowlist for a specific rule, it is recommended that you add an exception to a
specific rule (see below) rather than adding a global Allowlist rule.
Field Description
Allowlist IPs Enter IP addresses, IP ranges, or subnets.
WAF Rules policy
Define how Imperva's Web Application Firewall (WAF) responds to malicious visitors or requests.
Each WAF rule in the WAF Rules policy addresses a different type of threat to your web applications. For each WAF
rule, you can define a mitigation level (such as alert or block), or keep the default settings. By default, the WAF rules
are set to the Block Request option. The only exception is the Cross Site Scripting rule, which is set to Alert Only.

For each rule, you can also click to add an exception to the policy. For more details, see Add an
exception below.
Default WAF Rules policy
Each Imperva account and sub account includes a default WAF Rules policy.
The default account policy is automatically applied to new websites created in the account or sub account.
Additional WAF Rules policies
You can create additional WAF Rules policies.
A WAF Rules policy is always created in the enabled state, and cannot be disabled.
A website must have exactly one WAF Rules policy applied to it.
• If you apply a WAF Rules policy to a website, it replaces the policy that is currently applied to the website.
• If you remove a WAF Rules policy from a website, the account’s default policy is automatically applied to the
website.
WAF rules
WAF rule Description
Cross Site Scripting (XSS or CSS) is an attack that

attempts to run malicious code on your website
visitor’s browser.
A Cross Site scripting attack takes advantage of a

website vulnerability in which the site displays
Cross Site Scripting content that includes unsanitized user-provided
data. For example, an attacker could place a
hyperlink with an embedded malicious script into an
online discussion forum. The purpose of the
malicious script is to attack other forum users who
happen to click on the hyperlink. Such a script
could, for example, copy user cookies and then send
those cookies to the attacker.
An Illegal Resource Access attack attempts to access

otherwise private or restricted pages, or tries to view
Illegal Resource Access or execute system files. This is commonly done using
URL Fuzzing, Directory Traversal, or Command
Injection techniques.

WAF rule Description
Remote File Inclusion (RFI) is an attack that

targets the web servers that run websites and their
applications. It represents an attempt to manipulate
an application into downloading or executing a file
from a remote location.
Remote File Inclusion
RFI exploits are most often attributed to the PHP
programming language. Nevertheless, these exploits
can also manifest themselves in other
environments. RFI works by exploiting applications
that dynamically reference external scripts indicated
by user input without proper sanitation.
SQL injection is used to take advantage of non-

validated input vulnerabilities to pass SQL
commands through a web application for execution
by a backend database. Attackers take advantage of
the fact that programmers often chain together SQL
SQL Injection commands with user-provided parameters and can
therefore embed SQL commands inside these
parameters. The result is that the attacker can
execute arbitrary SQL queries and/or commands on
the backend database server through the web
application.
Note: The following WAF rules are defined at the website level on the Website WAF Settings page:
• Backdoor Protect. For more information, see Web Protection - WAF Settings.
• DDoS settings. For more information, see Web Protection - DDoS Settings.
Mitigation level
For each WAF rule, you can define how the Imperva Cloud WAF responds.
Option Description
Ignore
administrator/user (according to the Notification
Alert Only
Settings) and an alert appears in the Security Events
page. The malicious traffic is not blocked.
Malicious requests are blocked. In addition, an alert
Block Request
and an event are generated.

Option Description
Any user that has attacked your website will be
Block User
generated.
Any IP that has attacked your website will be
Block IP
generated.
Upload IP addresses in bulk
You can add a list of IP addresses in .csv format. This is supported everywhere on the Policies pages where IP
addresses are entered.
Guidelines:
• The file can include individual IP addresses, subnets, or ranges. For example:
1.1.1.1/25
2.2.2.2
2001:db8:3333:4444:5555:6666:7777:8888
3.3.3.3-3.3.3.5
• The entries must be listed in a single column - one entry per line.
• The file can contain up to 10,000 entries.

Add an exception
You can add exceptions to any of the rules in an ACL or WAF Rules policy. You cannot add exceptions to an Allowlist
policy.
In the account or sub account level page:
When you create or edit a policy, you can add an exception and apply it as follows:

Option Description
The exception is applied to all assets listed under
Apply to all assets with this policy Apply to assets in the policy (all websites in the
account).
Apply to specific assets The exception is applied to the selected assets only.
In the website-level page:
When editing a policy that is applied to your site (Policies page > More > Edit), you can add, edit, or delete an
exception.
When viewing the exception settings for a site in a sub account:
• Only exceptions applied to the specific site are displayed.

• Editing or deleting an existing exception affects all assets to which the exception is applied — not only to the
specific site.
• When adding an exception, you can apply it only to the specific site.
Wildcards:
• You can use a wildcard character (*) in an exception on a URL only at the end of the URL path.
• Wildcards are not supported in an exception on a WAF Rules policy HTTP parameter. If used, the asterisk (*) is
considered part of the parameter value. For example, example* will match only example*, but not example.
How exceptions work:
An exception rule will match only if all match criteria are satisfied. If you want to add an exception for multiple and
non-related scenarios, you can add multiple exception rules. Each exception rule is evaluated independently.
For example, suppose you created a Block Countries rule and need to add a few exceptions.
You want to add an exception for IP 1.2.3.4 on a specific URL, and for IP 5.6.7.8 under any circumstance.
If you created one exception rule, it would look like this:
Exception on URL /index.php and IP 1.2.3.4 or 5.6.7.8
This will bypass the block rule for either of the IPs on URL /index.php only.
Instead, you need to create two separate exception rules for this scenario:
Exception on URL /index.php and IP 1.2.3.4
Exception on IP 5.6.7.8
Apply a policy to websites
There are several ways to apply a policy to websites in your account:

Account or sub account level:
When creating or editing a policy, you can apply the policy to selected websites in the account, as described above in
Create a policy.
• If the account has sub accounts, you can apply the policy to sites in the account and to sites in any of the
account's sub accounts.
• When you create a policy in a sub account, you can apply the policy to sites in the specific sub account only.
You can also apply the policy by default for new sites created in your account. For details, see Apply a policy to
websites below.
Website-level:
On the Websites > Security > Policies page, click Apply to select existing policies to apply to the website.
Set a policy as default
You can apply a policy by default to all new websites created in an account. This setting does not affect existing sites
in the account.
In the policy, click Enable as default policy, and select the parent account and/or any sub accounts under the
account.
• When you select the parent account, the setting applies only to new sites created directly under the parent
account. It does not apply to new sites created under the sub accounts.
• If you move a site between a parent account and a sub account, or between sub accounts, any policies set as
default in the destination account are automatically applied to the site. In addition, policies that were already
applied to the site in the source account are still applied.
View and manage policies
On the Policies page in your account or website, you can view and manage your policies:
• Account-level: Application > WAF > WAF Policies. The Policies page displays all policies created in your
account.
• Sub account-level: Application > WAF > WAF Policies. The Policies page displays all policies created in your
sub account or applied to your sub account by the parent account.
• Website-level: Application > Websites > Security > Policies. The Policies page displays all policies applied to
your website.
Field Description
The name and unique identifier assigned to the

policy when it was created.
Policy Name (ID) You can define the policy name. The ID is
automatically assigned by the system.
Click the policy name to view or edit the policy.

Field Description
The policy type, which covers a specific area of
Type
Imperva functionality.
Description Available from: Account or sub account page only.
The policy will be automatically assigned to new
Marked as default websites created in the accounts or sub accounts
specified in the policy.
The number of websites to which the policy is
Applied to
currently applied.
The date the policy was created or last edited, and

the user who performed the action.
Last modified (For policies that were automatically created from

existing website settings during migration to Policy
Management, the name of an Imperva admin user
may be listed.)
Status Enabled or disabled.
Opens the policy and enables you to modify

settings.
Edit (under More)
When you update a policy and click Save, changes
are immediately applied.
Creates a copy of the selected policy.

Duplicate (under More)
Available from: Account or sub account page only.
Enables/disables the policy for all sites in the

account to which it is applied.
When a policy is disabled, it is not active and has no

impact on your account.
Enable/Disable (under More)
The advantage of disabling a policy as opposed to
deleting it from the account or removing it from sites
is that you can easily turn it back on.
Delete (under More)

Deletes the policy from your account.

Field Description
Note: You cannot delete a policy from the account
when the policy is applied to websites.
Removes an applied policy from the website. (The

policy is not deleted from the account.)
Remove (under More)
Available from: Website-level page only.
Tips:
• Use the free-text Search bar at the top of the page to locate policies according to details in the table, such as
type or policy name.
• Use the Filters drop-down to view policies by either Enabled or Disabled policy status.
• Click Download CSV to download the list of policies in .csv file format.
Policy Management API
Create and manage policies for your account using the API.
For instructions on using the Policies API, see Policy Management API Definition.
The definition file presents a full, formatted, and interactive version of the Policies APIs that you can use to learn
See also:

Policy Management API Definition

FAQ: WAF Settings Migration

This topic addresses questions about the migration of website WAF Settings to the WAF Policies feature.
Overview
WAF settings were previously defined separately for each protected website. With Imperva Policy Management, you
can define a policy and apply it to multiple websites.
For existing customers, we need to migrate your existing settings to the new WAF Rules policy.
policy.
What is the new WAF settings feature?
The new WAF Rules policy enables you to manage WAF settings for your websites exactly as you do today, but in a
centralized location for your entire account or subaccount.
How do I move from the existing to the new WAF settings policies?
You don’t need to do a thing.
Imperva runs a migration process that moves of all your existing WAF settings into the new WAF Rules policies.
What does the migration process actually do?
The zero-downtime migration process imports your website-level WAF settings into WAF Rules policies for the account
or subaccount in which the website is defined.
If there are settings that are common to more than one website, a single policy is created. All the relevant websites are
listed in the policy.
The automatically generated policies will be named as follows:
• Generated WAF Rules Policy <number>: A policy created from a website's configuration.
• Generated Default WAF Rules Policy for <account id>: The default policy created for the account or sub account.
(Each account and subaccount has its own default policy.)
When will the migration process take place? Will I be notified before the migration?
The migration rollout time schedule is described in the release notes.
What happens if the migration process fails?
Migrating is a fully reversible process. Moreover, if the migration process fails, your website-level settings remain
unchanged and accessible.

Who do I contact if something is wrong after the migration process is completed?
Please contact Imperva Support.
Can I choose to stay with the existing WAF settings?
Unfortunately no.
Once the migration process is complete for all customers, the old (existing) WAF settings will be removed from the
application.
Where in the application do I find the new WAF policies?
The WAF policy configuration is available in the account or subaccount. After logging in to the Cloud Security Console,
navigate to Application > WAF > WAF Policies.
Can I manage the WAF Settings both at the account and subaccount level?
Yes, you can. You can define and manage central policies for all websites in the account or subaccount in which the
websites are defined.
Will the existing WAF settings be deleted?
Yes.
Once the migration process is complete for all customers, the old (existing) website-level WAF settings will be
removed from the application.
How do I assign WAF settings to a site?
In the new WAF Policy feature, you can define a new policy and easily assign it to any of the websites that reside under
your account or subaccount. For details, see Create and Manage Policies.
Is there any change in the APIs I use for managing my WAF settings?
Yes. Once your account is migrated, you can no longer use the following APIs to configure WAF settings and
exceptions:
In addition, details of the WAF settings and exceptions will be removed from the following Site Management APIs:

• Get site status
• All other Site Management APIs that return details of the site’s WAF settings configuration
I'm using Terraform. Are there changes there as well?
Yes. Once your account is migrated, you can no longer use the incapsula_waf_security_rule and
incapsula_security_rule_exception Terraform resources with the following rule_id values to configure WAF settings
and exceptions:
Instead, use the incapsula_policy Terraform resource.
Note: As of August 1, 2022, following the migration of WAF settings for all customer accounts to the new WAF Rules
policy, the old WAF setting APIs and old Terraform resources mentioned above will be decommissioned.
See also
• Migration release note: February 20, 2022 Release.

• Policy Management: Create and Manage Policies.

Bot Mitigation
This topic discusses Imperva's mitigation capabilities for automated threats.
Overview
Automated threats are characterized by unwanted, automated actions that have a detrimental effect on a web
application, often through the misuse of legitimate functionality, rather than by attempting to exploit unmitigated
vulnerabilities. These threats are further discussed here: https://www.owasp.org/index.php/
OWASP_Automated_Threats_to_Web_Applications .
Automated threats are often carried out by the malicious use of bots. A bot is generally defined as an application that
performs an automated task, typically a simple, repetitive task performed at a much higher rate than people
performing these tasks manually could achieve.
Bots can be categorized as follows:
• Good bots are used for productive purposes, such as for gathering data for search engines (googlebot), for
commercial purposes (finding you the best deal), or for chatbots (customer service).
• Bad bots are used for malicious purposes, such as to automate attacks such as denial-of-service attacks, to buy
up seats for shows or concerts, or to sabotage gaming sites.
Who are you?
To mitigate automated threats, we first ask the question, "Who are you?". Imperva's bot protection solution is based
on identifying the threat according to our system of client classification.
Based on the classification, we can categorize the bot as good, bad, or unidentified. Unidentified bots are ones for
which we don't have a classification and are not listed in our client database. By default, we treat an unidentified bot
as suspicious because it is an unknown, but it may be harmless. For the list of the clients and client type categories
that Imperva addresses, see Client Classification.
Once we have categorized the bot, we are ready to decide whether to challenge suspicious visitors and verify their
authenticity, alert you of suspicious activity, or block requests that pose a threat to your website.
As a customer, you can easily configure bot mitigation options in the Cloud Security Console:
• define an access control policy

• customize the list of good/bad bots
• define exceptions
• block specific sources (countries, URLs, IPs)
For more details, see Web Protection - Security Settings.

What are you trying to do?
Imperva also provides protection against automated threats that are characterized not by the tool used but by intent
or actions, such as service abuse.

To mitigate these threats, we ask the question, "What are you trying to do?".
For example, requests from a browser can be legitimate or malicious. Consider a brute force attack, in which a large
number of consecutive "guesses" are generated in order to obtain some desired data, such as login credentials. So
even if we determine that the client/source of the request is seemingly legitimate, the goal of the action is not. To
protect against such an account takeover attack, in which there is an attempt to gain unauthorized access to and
control of an account, you can create customized security rules for your web applications.
Examples
Threat What does it do? Imperva mitigation
Block bad bots (enabled by

default).
Inspects applications looking for
For example ShellShock
Vulnerability scanning weaknesses and possible
vulnerability scanner or Qualys
vulnerabilities to exploit.
scanner.
Web Protection - Security Settings
Stop DDoS attacks (enabled by

Target an application in order to
Distributed denial of service default)
make it unavailable to legitimate
(DDoS) attacks
users or purposes.
Web Protection - DDoS Settings
Identify valid login credentials by Configure custom rules:

trying different values for
• Rules
usernames and/or passwords,
Credential Cracking
such as brute force attacks used
For example:
against authentication processes
of an application. • Account Takeover
Malicious, questionable,
undesirable, or unsolicited
Spamming information added to public or Default functionality
private content, databases, or user
messages.
Configure custom rules:

Collect application content and/or
Scraping
other data for use elsewhere. • Create Rules
For example:

Threat What does it do? Imperva mitigation

• Anti-scraper engine -
CAPTCHA for bots
Read More
• Web Protection - Security Settings

• Security Rule Use Case Examples

Client Classification
Mitigation of malicious bot activity and Layer 7 DDoS attacks starts with identifying the source of the attack. This
mitigation uses Imperva’s advanced client classification technology.
In this topic:
• Overview
• Client types
• Client IDs
Overview
Mitigation of Layer 7 DDoS attacks also leverages Imperva’s client classification technology.
Based on this classification system, Imperva determines whether to challenge suspected visitors and verify their
authenticity, alert you of suspicious activity, or block requests that pose a threat to your website.
Note: In addition to Imperva's existing security and application delivery logic, you can create and apply your own
customized security and access control rules for specific client types or applications. For details, see Create Rules and
Rule Filter Parameters.
Client types
The client application type, such as Browser or SpamBot. Note that some bots can be used for multiple purposes and
can fall into more than one category. For example, a Java library can be used for scraping purposes or attack
purposes.
Client Type Details

Browsers and other applications with browsing
Browser
capabilities. For example: Chrome, Firefox
ClickBot A bot that clicks ads on a web page.
A bot that posts spam to sites in comments or
CommentSpamBot
forums.
General, known crawling bots that harvest data from
a website to use for their own purposes, such as for
a search engine. Examples include bots with an
unknown purpose and/or name, bots that can
Crawler
search for adult content as part of a parental control
service, or bots that scan for a site that offers jobs
opportunities. For example: Applebot, Trend Micro
Crawler
A client that fetches feeds, such as an RSS feeds or
FeedFetcher using an API. For example: Yahoo Pipes, Facebook
External Hit

Client Type Details

(Developer Tool). All tools that can be programmed
for any purpose, malicious or not. For example,
HackingTool scripts or command line tools such as Wget and lwp-
request, or programming language libraries that
enable web requests such as Java or Python urllib.
A client that is a proxy that masks another client that
MaskingProxy Imperva cannot classify. For example, anonymous
proxies, security gateways, or anonymizer services.
A bot that searches data and indexes it for later use
SearchBot
by a search engine. For example, Googlebot, Bingbot
Tools or services that send requests to a website for
a positive purpose, usually by the site owner or host,
SiteHelper such as health checkers, broken link checkers, or
performance checkers. For example: Rackspace
Monitoring Agent, Amazon Route 53 Health Checks
A bot that assists in sending spam by harvesting
SpamBot email addresses or other personal information for
spam purposes.
All other bots that do not fit an Imperva client
Unknown
classification or bots whose purpose is unknown.
Automatic tools or commercial scanners that
VulnerablityScanner explore vulnerabilities in web applications. For
example: Nikto, Skipfish, Qualys
A bot that attempts to attack websites, such as by
Worm SQL injection or cross-site scripting. For example:
MaMa CaSpEr
A bot that is used to perform DDoS attacks. For
DDoSBot
example: Nitol, Cyclone
Client IDs
The Imperva ID number assigned to the client application.
Note: You can also retrieve a list of all the client applications using the API. For details, see Get client application info
in Integration API.
Name Client ID Client Type

1 Firefox Browser
2 Internet Explorer Browser
3 Chrome Browser
4 Safari Browser
5 General Crawler Crawler
6 Googlebot SearchBot
7 Bot Unknown
8 Opera Browser
9 Camino Browser


10 Wget HackingTool
11 Maxthon Browser
12 Google Translate MaskingProxy
13 Skipfish VulnerabilityScanner
14 Google Services SiteHelper
15 Verisign ips-agent Crawler
16 Baidu Spider SearchBot
17 SiteUptime SiteHelper
18 Guardster MaskingProxy
19 Yahoo! Slurp SearchBot
20 NimbuBot SiteHelper
21 Nikto VulnerabilityScanner
22 Are My Sites Up? SiteHelper
23 mon.itor.us SiteHelper
24 Load Impact SiteHelper
25 Host Tracker SiteHelper
26 Konqueror Browser
27 SurveyBot SearchBot
28 Facebook External Hit FeedFetcher
29 Google AppEngine HackingTool
30 PycURL HackingTool
31 Twingly Recon SearchBot
32 Twitter Bot FeedFetcher
33 DataSift Bot Crawler
34 PostRank Bot SearchBot
35 Kosmix Voyager SearchBot
36 mxbot Crawler
37 Knowmore Bot SearchBot
38 OneRiot Bot SearchBot
39 Morfeus Scanner VulnerabilityScanner
40 Netcraft Survey Bot SearchBot
41 libwww-perl HackingTool
42 Comodo Certificates Spider SiteHelper
43 Jayde Crawler SearchBot
44 Qualys Scanner VulnerabilityScanner
45 SeaMonkey Browser
46 MSN/Bing Bot SearchBot
47 cURL HackingTool
48 XML Sitemaps Generator SiteHelper
49 Python urllib HackingTool
50 BrowseX Browser


51 Twiceler SearchBot
52 ChromePlus Browser
53 SRWare Iron Browser
54 Avant Browser
55 Flock Browser
56 Opera Turbo MaskingProxy
57 CatchBot SearchBot
58 Pingdom Bot SiteHelper
59 Dotcom Bot SiteHelper
60 Montastic Bot SiteHelper
61 Google Feedfetcher FeedFetcher
62 Yandex Bot SearchBot
63 Stack Rambler SearchBot
64 Panscient Bot SearchBot
65 FindLinks SearchBot
66 Babel Server MaskingProxy
67 Babel Distort MaskingProxy
68 Google AdsBot SearchBot
69 Speedy Spider SearchBot
70 ExaBot SearchBot
71 Voila Bot Crawler
72 Gigabot SearchBot
73 Flight Deck Bot Crawler
74 Nokia S60 Browser
75 MJ12 Bot SearchBot
76 PHP HackingTool
77 Java HackingTool
78 MSIE Crawler Crawler
79 HTMLParser HackingTool
80 Kisiwa VSE Crawler
81 Alexabot Crawler
82 ICC-Crawler Crawler
83 GeoHasher Crawler
84 obot Crawler
85 YaCy-Bot SearchBot
86 YaCy Proxy MaskingProxy
87 DotBot Crawler
88 Prism Browser
89 Websense Crawler Crawler
90 picmole Crawler
91 .NET WebClient FeedFetcher


92 Daum Bot SearchBot
93 Website Optimization Analyzer SiteHelper
94 SpamBot SpamBot
95 Lightspeed Crawler Crawler
96 CCBot Crawler
97 Larbin HackingTool
98 drone Crawler
99 DTS Agent SpamBot
100 Google Toolbar Browser
101 DNS Digger Explorer Crawler
102 CFNetwork FeedFetcher
104 WordPress SiteHelper
105 Opera Mini Browser
106 Ask Crawler SearchBot
107 Trend Micro Crawler Crawler
108 Jakarta Commons HttpClient HackingTool
109 Incutio XML-RPC PHP HackingTool
110 L.webis Crawler
111 Rome Client HackingTool
112 Google Bot Impersonator Crawler
113 SpamBot CommentSpamBot
114 TalkTalk Bot Crawler
115 Microsoft Office Import Crawler
116 Netnir Rank Check Crawler
117 Microsoft WebDAV MiniRedir Crawler
118 Aria eQualizer Crawler
119 Yeti (Naver Bot) SearchBot
120 Mail.Ru Bot SearchBot
121 Anonymouse MaskingProxy
122 Web Link Validator SiteHelper
123 Nutch Based Crawler Crawler
124 Xenu's Link Sleuth SiteHelper
125 MLBot Crawler
126 spbot Crawler
127 WebMoney Advisor Bot Crawler
128 BlackBerry Internet Browser Browser
129 OSSProxy MaskingProxy
130 python-requests HackingTool
131 lwp-request HackingTool
132 Android Browser Browser
133 Lynx Browser


134 RuleSpace Bot Crawler
135 Corbina Bot Crawler
136 AgHaven Bot SearchBot
137 Digsby Favicon Fetcher Crawler
138 Dom2Dom Crawler
139 Seexie Bot SearchBot
140 Setoozbot SearchBot
141 Botnet Agent 141 Worm
142 ia_archiver SearchBot
143 Chinese Bot Crawler
144 PickUpJob Bot SearchBot
145 Blue Coat Gateway MaskingProxy
146 NetApp NetCache MaskingProxy
147 Latvian Comment Spammer CommentSpamBot
149 Labhoo Bot SearchBot
150 Makam Bot Crawler
151 Linkspimp Crawler
152 BuiltWith Bot Crawler
153 Blekko ScoutJet SearchBot
154 IBM SAI Crawler Crawler
155 Scooper Bot SearchBot
156 Windows Media Player Browser
157 OmgiliBot SearchBot
158 Microsoft Internet Transfer Control HackingTool
159 Bixo Labs Crawler Crawler
160 Crawler Crawler
161 Soso Spider SearchBot
162 Envolk Bot SearchBot
163 Windows RSS Platform FeedFetcher
164 Facebook Platform Crawler
166 Dillo Browser
167 DuckDuckBot SearchBot
168 Google Wireless Transcoder MaskingProxy
169 Websense Content Gateway MaskingProxy
170 Squid MaskingProxy
171 SQL Injection Digger VulnerabilityScanner
172 Chinese Bot Crawler
173 Comment Spammer CommentSpamBot
174 SQL Injection Worm Worm
176 WinHttpRequest HackingTool
177 Cyveillance Bot Crawler


179 Google Desktop Crawler
180 Picsearch SearchBot
184 hoge Crawler
185 SpamBot SpamBot
187 PHP OpenID SiteHelper
188 Sogou Spider SearchBot
189 008 (80legs Crawler) Crawler
190 TurnitinBot Crawler
191 Null Bot Crawler
192 TextDigger Bot Crawler
193 IronPort MaskingProxy
194 Apache HttpClient HackingTool
196 NetProxy.info MaskingProxy
197 Vulnerability Scanner VulnerabilityScanner
198 Change Detection Bot SiteHelper
199 Camont Spider Crawler
200 LinkedIn Bot Crawler
201 Snapbot SearchBot
203 Careerjet Bot SearchBot
204 FlaxCrawler SearchBot
205 KAIST Bot Crawler
206 JomjaiBot Crawler
207 Qt HackingTool
208 Parked Domain Ad ClickBot ClickBot
209 Incapsula Service SiteHelper
210 SpokeSpider Crawler
211 MSIE Content Type Checker Browser
212 Statools Bot Crawler
213 my6sense Bot Crawler
214 TwengaBot-Discover SearchBot
215 CyberPatrol Webbot Crawler
216 MaMa CaSpEr Worm
221 SearchDNA Bot Crawler
224 RSS Feeder FeedFetcher
229 Solomono Bot SearchBot
230 Moreno Bot Crawler


234 @@Version SQL Injection Worm Worm
235 Jaxified RSS Feeder FeedFetcher
236 Seznam Bot SearchBot
237 Sygol Bot SearchBot
238 Sphider Crawler
240 Havij SQL Injection Tool VulnerabilityScanner
241 Keywen Bot SearchBot
242 Playstation Browser
243 SimplePie RSS Feeder FeedFetcher
245 Swish-e Crawler
246 Cligoo Robot Crawler
247 MSR-ISRCCrawler Crawler
248 NTT DoCoMo Mobile Phone Browser
249 Unknown CommentSpamBot
250 Hailoo Bot SearchBot
251 Google Custom Search SearchBot
252 Global Report RSS Feeder FeedFetcher
253 Youdao Bot SearchBot
254 Organization Proxy MaskingProxy
255 IWSS MaskingProxy
256 FindFiles.net Bot SearchBot
257 WebSense WebDefence MaskingProxy
258 Cyberoam Security Gateway MaskingProxy
259 Masking Proxy MaskingProxy
260 Yahoo External Cache Crawler
261 RFI Worm Worm
262 JSky VulnerabilityScanner
263 BlogLines FeedFetcher
264 N-Stalker VulnerabilityScanner
265 FeedBurner FeedFetcher
266 Conduit Toolbar Browser
267 FeedDemon FeedFetcher
Acunetix Web Vulnerability
268 VulnerabilityScanner
Scanner
Microsoft Internet Security and
269 MaskingProxy
Acceleration Server
270 MikroTik HTTP Proxy MaskingProxy
271 Apple PubSub FeedFetcher
272 Lusca Web Proxy MaskingProxy
273 Nessus Vulnerability Scanner VulnerabilityScanner


275 Ad ClickBot ClickBot
276 Paessler Monitor SiteHelper
277 Periscope It SiteHelper
PathDefender Bot (Mcafee
ScanAlert)
279 WebSitePulse SiteHelper
280 UrlCheck SiteHelper
281 SQLMap VulnerabilityScanner
282 Netsparker VulnerabilityScanner
283 Blue Coat Gateway Prefetcher MaskingProxy
284 Webmetrics Monitoring Service SiteHelper
286 FlipboardProxy FeedFetcher
287 Discobot Crawler
288 Covario IDS Crawler
289 Mobile Safari Browser
290 Cotendo MaskingProxy
291 Unidentified Proxy MaskingProxy
293 Yottaa SiteHelper
294 JikeSpider Crawler
295 Magpie Crawler Crawler
296 Panopta SiteHelper
297 BuyDo DDoSBot
298 GSA Crawler Crawler
300 muieblackcat HackingTool
301 Joomla! Worm Worm
302 Spinn3r SearchBot
303 Imperva MX Server Crawler
304 awstats scanner VulnerabilityScanner
305 Microsoft Web Services Client SiteHelper
306 Lycosa Crawler
Websiteprotection Vulnerability
Scanner
308 Hyperspin SiteHelper
309 ClickTale bot SiteHelper
310 CrystalSemanticsBot Crawler
311 Pinterest Bot Crawler
312 Proximic Bot Crawler
313 HP WebInspect VulnerabilityScanner
314 Google Plus Share Crawler
315 HTTrack HackingTool
316 Microsoft Lync SiteHelper


317 Amazon aranhabot SiteHelper
318 elkMonitor SiteHelper
319 Acoon Bot SearchBot
320 Grepnetstat SiteHelper
321 Gnip Bot Crawler
322 Radian6 Bot Crawler
323 Topsy Butterfly SearchBot
324 tra.cx.pider Crawler
326 Android Dalvik VM FeedFetcher
328 kSOAP FeedFetcher
329 Microsoft ATL SOAP requests HackingTool
330 InternetVista Site Monitor SiteHelper
331 Aihit bot Crawler
332 NetSeer Crawler Crawler
333 EvriNid bot Crawler
334 InfoSeek SideWinder Worm
335 Updowner bot Crawler
336 OpenIndex Bot SearchBot
337 Sucuri Bot SiteHelper
Microsoft Windows Network
338 Crawler
Diagnostics Bot
339 Whitehat Vulnerability Scanner VulnerabilityScanner
340 SiteLock Vulnerability Scanner VulnerabilityScanner
341 IBM AppScan VulnerabilityScanner
342 HuaweiSymantecSpider Crawler
343 CareerBot Crawler
344 Microsoft Adidxbot Crawler
345 Yahoo Pipes FeedFetcher
Project Wonderful Ad/Compliancy
346 Crawler
Bot
347 AhrefsBot Crawler
348 Google Partner Monitor SiteHelper
349 Grapeshot Bot Crawler
350 Pixray Seeker Crawler
351 Bountii Bot SearchBot
352 YourCronTask SiteHelper
353 Outbrain Crawler
354 ShopWiki Bot SearchBot
355 Server Density SiteHelper
356 CodeGuard Bot SiteHelper
357 VaultPress Bot SiteHelper
358 ExB Language Crawler Crawler


359 Moreover Bot Crawler
360 OviBrowser Browser
361 phpMyAdmin Scanner Worm
362 200Please Bot SiteHelper
363 WBSearchBot Crawler
364 Security Metrics VulnerabilityScanner
GlobalSign Domain Verification
365 SiteHelper
Agent
366 Amazon ProductAdsBot Crawler
367 Zing Botabot Worm
368 FeedWordPress FeedFetcher
369 Superfeedr Bot FeedFetcher
370 Techmixx Spider Crawler
371 Yandex Browser Browser
372 Rogerbot Crawler Crawler
373 Yunyun Spider SearchBot
374 Webkit Browser Browser
375 Worio Search SearchBot
376 JMonitoring SiteHelper
377 CukBot Crawler
378 Siteencyclopedia Bot Crawler
379 JobRoboter Bot Crawler
380 Artmixx Bot Crawler
381 Thumbshots Bot Crawler
382 AboutUs Bot Crawler
383 CitiStreet Search SearchBot
384 Gravitybot Crawler
385 AddLinkBuilding Crawler
386 FreeWebMonitoring Bot SiteHelper
387 SLI-systems Crawler Crawler
388 Wiju Crawler Crawler
389 UptimeRobot SiteHelper
390 Jabse Search SearchBot
391 HTTP_Request2 Bot HackingTool
392 WebmasterCoffee Bot Crawler
393 UltraSpider3000 SearchBot SearchBot
394 FriendFeedBot Crawler
395 BigBozzBot SearchBot
396 HubSpot Crawler Crawler
397 Caliperbot Crawler
398 imrbot Crawler
399 OpenfosBot SearchBot


400 iisbot Crawler
401 FedcontractorBot SearchBot
402 DrupalBot Crawler
403 Riddler Bot Crawler
404 SiteExplorer Bot Crawler
405 NewsGator Bot Crawler
406 A6-Indexer Bot Crawler
407 Affectv Bot Crawler
408 Amazon CloudFront Client SiteHelper
409 SnapSitemap SiteHelper
410 Keynote SiteHelper
411 Ezooms Crawler
412 ApacheBench HackingTool
413 Feedly FeedFetcher
414 Internet Explorer Mobile Browser
415 Rackspace Monitoring Agent SiteHelper
417 PhantomJS HackingTool
418 Google Webmasters Tools Agent SiteHelper
420 W3C - Feed Validation SiteHelper
421 W3C - CSS Validator SiteHelper
422 W3C - Link checker SiteHelper
423 W3C - Mobile OK Checker SiteHelper
424 W3C - Unicorn Unified Validator SiteHelper
425 W3C - Markup Validator SiteHelper
W3C - Nu Markup Validation
426 SiteHelper
Service
427 W3C - Internationalization Checker SiteHelper
428 Browser Browser
429 Firefox (NC) Unknown
430 Internet Explorer (NC) Unknown
431 Chrome (NC) Unknown
432 Safari (NC) Unknown
433 Ararat Synapse FeedFetcher
434 SiteTruth SiteHelper
435 Picasa Web Albums Bot Crawler
436 SEMrushBot Crawler
437 Easou Spider SearchBot
438 CheckParams Crawler
439 goo Crawler
440 Flipboard Mobile Client FeedFetcher
441 Nessus Cloud VulnerabilityScanner
442 Chinese Vulnerability Scanner VulnerabilityScanner


443 Playstation Browser Browser
445 Adbeat Crawler
446 AlertSite Scan Service VulnerabilityScanner
447 6Scan Scan Service VulnerabilityScanner
448 Beyond Security Scan Service VulnerabilityScanner
Symantec Vulnerability
Assessment Service
450 Unknown Tor-based bot MaskingProxy
451 Malicious Tor Client VulnerabilityScanner
452 seomatik.pl Crawler
453 Google Proxy MaskingProxy
454 Linkdex Crawler
455 VocusBot Crawler
456 IstellaBot Crawler
457 meanpath Crawler
458 SiteMonitor SiteHelper
459 FeedBooster FeedFetcher
460 Aol Reader FeedFetcher
461 feedzirra FeedFetcher
463 Arachni VulnerabilityScanner
464 Embedly Crawler
465 Coc Coc SearchBot
466 XBMC FeedFetcher
467 SEO Gears DIY SiteHelper
468 UCBrowser Browser
469 IceRocket SearchBot
471 UniversalFeedParser FeedFetcher
472 Tweeted Times Crawler
473 Ning Crawler
474 Scrapy Crawler
475 Silk Browser
476 Cutwail 1 DDoSBot
477 HOIC DDoSBot
478 CA Nimsoft Monitor SiteHelper
479 SlowLoris DDoSBot
480 XChange FeedFetcher
481 AutoComplete+ for Magento SiteHelper
482 Mobile Chrome Browser
483 Google Search App Browser
484 ADmantX Crawler
485 360Spider SearchBot
486 PayPal IPN SiteHelper


487 New Relic SiteHelper
488 2Checkout SiteHelper
489 Qt Bitcoin Trader FeedFetcher
490 Bitcoin Widget FeedFetcher
491 Gomez Agent SiteHelper
492 Windows Phone SDK WebClient FeedFetcher
493 Cutwail 2 DDoSBot
494 MSG DDoSBot
495 Nitol DDoSBot
496 Koogle DDoSBot
497 Rhino DDoSBot
498 Cyclone DDoSBot
499 TheGarden DDoSBot
500 ChinaZ DDoSBot
501 PCRat DDoSBot
502 Gyoarazujo DDoSBot
503 Sentry MBA VulnerabilityScanner
504 ARME Attack DDoSBot
505 Nitol / Rincux DDoSBot
506 Nitol / Reconyc DDoSBot
507 MozMSH DDoSBot
508 PiplBot Crawler
510 Authorize.net SiteHelper
511 Bitcoin Checker FeedFetcher
512 DirtJumper DDoSBot
513 HAX DDoSBot
514 CopperEgg SiteHelper
515 YisouSpider Crawler
516 WordPress Brute Forcer DDoSBot
517 Androm DDoSBot
518 EXALEAD CloudView FeedFetcher
519 PageFreezer Crawler
520 CommentLuv FeedFetcher
521 LoadImpact SiteHelper
522 Haasonline Trade Server FeedFetcher
523 WhiteHat Aviator Browser
524 OWASP DirBuster VulnerabilityScanner
525 CheckHost SiteHelper
526 Blitz SiteHelper
527 Repost SiteHelper
528 Disqus SiteHelper


529 AddThis SiteHelper
530 ActiveSG FeedFetcher
531 ShipStation SiteHelper
532 Site24x7 Tools SiteHelper
533 Tor's Hammer DDoSBot
534 FE Client SiteHelper
535 HULK DDoSBot
536 Referrer SpamBot SpamBot
537 Qualys SSL Labs SiteHelper
538 Shopping.com Bot SiteHelper
539 MaxPatrol Scanner VulnerabilityScanner
540 BOT/0.1 (BOT for JCE) VulnerabilityScanner
541 Luna DDoSBot
542 G-Bot DDoSBot
543 Zscaler MaskingProxy
544 Sitebeam Bot SiteHelper
545 JetPack SiteHelper
546 Baidu Translate SiteHelper
547 ICS DDoSBot
548 MixRankBot Crawler
549 CN Bot Crawler
550 Skys Bot SiteHelper
551 SmartTV Browser
552 eHarmony iOS Client FeedFetcher
553 Bitrix Bot SiteHelper
554 vk.com Bot SiteHelper
555 Joomla! HackingTool
556 GHP DDoSBot
557 Cliqzbot Crawler
558 Crowsnest SiteHelper
559 360webscan VulnerabilityScanner
560 BLEXBot Crawler Crawler
561 XoviBot Crawler
562 FlamingoSearchEngine Crawler
563 LinkPad Bot Crawler
564 nlcrawler Crawler
565 SMTbot Crawler
566 Slackbot Crawler
567 GoogleProducer FeedFetcher
568 Prerender SiteHelper
569 OmniExplorer Crawler


570 App.net Crawler
571 DDoS Bot 571 DDoSBot
572 SputnikBot Crawler
573 SuperFish Crawler
574 BinaryCanary SiteHelper
575 DomainAppender Crawler
576 LeikiBot Crawler
577 DiffBot Crawler
578 OpenLinkProfiler Crawler
579 Opera Feedfetcher FeedFetcher
580 SQLi Dumper VulnerabilityScanner
581 gimmeBot Crawler
582 AdsafeMedia Crawler
583 Megaindex Link Analyzer Crawler
584 TrovitBot Crawler
585 Wotbox Crawler
586 Veracode DAST VulnerabilityScanner
587 feedjira FeedFetcher
588 Genieo Crawler
589 Go HTTP library HackingTool
591 SEOstats Library HackingTool
592 HaleBot Crawler
593 Amazon Route 53 Health Check SiteHelper
594 webOS Browser Browser
595 Nagios Monitoring Service SiteHelper
596 WeSEE Bot Crawler
597 BetGenius Bot Crawler
598 Python-httplib2 HackingTool
599 Nintendo Browser Browser
600 THC Hydra VulnerabilityScanner
601 LTX71 VulnerabilityScanner
602 okHTTP HackingTool
604 PHP Backdoor Bot Worm
605 Owlin Bot FeedFetcher
606 Sphereup Bot Crawler
607 Findxbot Crawler
608 Drakma - Lisp HTTP client HackingTool
609 Curious George Crawler
610 UptimeTracker SiteHelper
611 Cryptowatch-Observer Crawler
612 Boardreader Crawler


613 FatBot Crawler
614 Trendiction-Bot Crawler
615 Sistrix crawler Crawler
616 Known Vulnerability Scanner Worm
617 Apple Bot Crawler
618 DEEPCRAWL Bot Crawler
619 SpotXchange Bot Crawler
620 Family Tree Builder SiteHelper
621 Chef Client SiteHelper
622 Veooz Crawler Crawler
623 HyperCrawl Crawler
624 MagpieRSS FeedFetcher
625 Wget BusyBox HackingTool
626 Browser Impersonator HackingTool
627 Epiphany Browser Browser
628 Trustwave Scanner VulnerabilityScanner
629 UnityPlayer SiteHelper
630 MegaIndex Crawler Crawler
631 Domain Re-Animator Bot Crawler
632 SetCronJob Bot SiteHelper
633 Mail.ru Chrome Bot Crawler
634 Begun Bot Crawler
635 MrBlack DDoSBot
637 Hackeroo DDoSBot
638 ThousandEyes Bot SiteHelper
639 MeWeBot Crawler
640 Augure Bot Crawler
641 Screaming Frog SEO Spider Crawler
642 PHP DDoS Tool DDoSBot
644 CloudServerMarketSpider Crawler
645 OpenHoseBot Crawler
646 GroupHigh Bot Crawler
647 simplereach Crawler
649 ControlScan Scanner VulnerabilityScanner
650 Comodo Hacker Guardian Service VulnerabilityScanner
651 Microsoft Edge Browser
652 PageSpeedGrader SiteHelper
653 Qwant Bot SearchBot


654 Nitol B DDoSBot
655 Joe Dog Siege DDoSBot
656 Swiftbot Crawler
657 GTmetrix SiteHelper
658 Referrer SpamBot 2 SpamBot
659 SaleForce Apex Web Services SiteHelper
660 dlvr.it SiteHelper
661 Testomatobot SiteHelper
662 Chef Knife Opscode HackingTool
663 SiteLock WAF Connector SiteHelper
664 DomainSigma Crawler
665 OwnCloud News SiteHelper
666 tweetedtimes SiteHelper
667 Page2RSS FeedFetcher
668 Zemanta Aggregator Crawler
669 Trackuity SiteHelper
670 LinkapediaBot Crawler
671 BitlyBot Crawler
672 MojeekBot SearchBot
673 Gluten Free Crawler Crawler
674 PRTGCloudBot SiteHelper
675 Spundge Crawler
677 Zabbix Web Monitor SiteHelper
678 Microsoft Office Outlook FeedFetcher
679 GoARM / Ramgo DDoSBot
680 CF Bypass DDoSBot
681 SEOkicks Crawler
682 TxOddsRobot SiteHelper
684 DeuSu SearchBot
685 BnF Bot Crawler
686 Parsijoo SearchBot
687 NTENTbot Crawler
688 TrackIFBot SiteHelper
689 NewsleBot Crawler
690 MUSObot SiteHelper
691 seo4ajax Crawler
692 Kodi FeedFetcher
694 UniLeipzigASV Crawler
695 NLB Archive Bot Crawler
696 parsely Crawler
697 Lipperhey Crawler


698 SurdotlyBot Crawler
699 Yourls SiteHelper
700 New Zealand Library Crawler
701 British Library Crawler Crawler
702 BazQux FeedFetcher
703 BuzzSumo Crawler
704 CocCoc Browser Browser
705 WebCEO SiteHelper
706 EtaoSpider SearchBot
707 Tiny Tiny RSS SiteHelper
708 Searchmetrics Bot Crawler
709 PaperLiBot Crawler
710 NewsBlur FeedFetcher
711 EveryoneSocial Bot Crawler
712 Livelap Bot Crawler
713 Yahoo! JAPAN SearchBot
714 Chartbeat uptime monitor SiteHelper
715 Moneybookers Payment Agent SiteHelper
716 Shellshock Vulnerability Scanner VulnerabilityScanner
717 Joomla Vulnerability Scanner VulnerabilityScanner
718 Siteimprove SiteHelper
720 Yandex TAPOC MaskingProxy
721 Indeed Crawler
722 Linkfluence Bot Crawler
723 LOVOO Client FeedFetcher
724 Fever FeedFetcher
725 Integralads Crawler Crawler
726 Google Docs FeedFetcher
727 Yahoo Ad Monitoring Crawler
728 Yahoo Link Preview FeedFetcher
729 Typhoeus HackingTool
730 WiseGuys Crawler Crawler
731 Google Apps Viewer FeedFetcher
732 Avira SafeSearch SearchBot
733 Bloglovin FeedFetcher
734 Weebly SiteHelper
736 Chilkat HackingTool
737 Puffin Browser Browser
738 SecurityHeaders.io SiteHelper
739 Brave Browser


740 QQBrowser Browser
741 Spotify FeedFetcher
742 Rigor SiteHelper
743 AOL Desktop Browser
744 Catchpoint SiteHelper
745 Uptimebot SiteHelper
747 Ruby HTTP library HackingTool
748 Social News Desk SiteHelper
749 BlueSnap SiteHelper
750 AppSpider VulnerabilityScanner
751 Mechanize HackingTool
752 Raintank Collector SiteHelper
753 Sogou Browser Browser
754 Mac Calendar Agent FeedFetcher
755 Awesomium HackingTool
756 DistributorDataSolutions Spider Crawler
757 StackDriver SiteHelper
758 skimbot Crawler
759 Netvibes SiteHelper
760 Comic Rocket Crawler
761 Facebook Mobile App Browser
762 WhatsApp Mobile App FeedFetcher
763 IYstudio DDoSBot
764 Zapier SiteHelper
765 SWCD FeedFetcher
766 MetaComment Crawler
767 MuckRack Crawler
768 Appcelerator Titanium HackingTool
769 Goad DDoSBot
771 PrintFriendly FeedFetcher
772 Weborama Crawler
773 LuaSocket HackingTool
774 Pcore-HTTP HackingTool
775 AdobeAIR FeedFetcher
776 T-mobile client Browser
777 Samsung Browser Browser
778 InternetMemory crawler Crawler
779 RePEc crawler Crawler
780 Grabber VulnerabilityScanner
781 Transparent health checker SiteHelper
783 StatusCake SiteHelper


784 RavenCrawler Crawler
785 SkyClient FeedFetcher
786 celltrak FeedFetcher
787 Mirai DDoSBot
788 GnowitNewsbot Crawler
789 LogicMonitor SiteHelper
790 Hardenize SiteHelper
791 Cloudinary SiteHelper
792 SXMLiveAudioPlayer FeedFetcher
793 OWASP ZAP VulnerabilityScanner
794 Botify Crawler
795 YouNow Client FeedFetcher
796 Cabify Client FeedFetcher
797 Medusa VulnerabilityScanner
798 Amazon SNS Agent SiteHelper
799 NightmareJS HackingTool
800 ActiveSync FeedFetcher
801 Cialis SpamBot SpamBot
802 SQL Injection Scanner VulnerabilityScanner
803 Canadian Pharmacy SpamBot SpamBot
804 Microsoft-CryptoAPI FeedFetcher
805 Hackney HackingTool
806 GetIntent Crawler Crawler
807 WormlyBot SiteHelper
808 G2APAY SiteHelper
809 Themes SpamBot SpamBot
810 Google WebLight MaskingProxy
811 Reverse B64 SpamBot SpamBot
813 P.A.S Client SpamBot SpamBot
814 Let's Encrypt Helper Bot SiteHelper
815 Generic Bot 815 SpamBot
816 Mashery Proxy MaskingProxy
818 BUbiNG Crawler
819 WordPress Bruteforcer VulnerabilityScanner
820 SpamTorte v2 SpamBot
821 ZumBot SearchBot
822 PowerShell HackingTool
IRESS Exchange Communications
824 FeedFetcher
Service
825 HC bot SpamBot


826 Konfabulator widget engine SiteHelper
827 Headless Chrome HackingTool
828 Incapsula Cracker HackingTool
829 Auto Spider VulnerabilityScanner
831 NeumobBot FeedFetcher
832 Struts Bot VulnerabilityScanner
833 GeoPeeker SiteHelper
834 Cloudflare AMP Discovery Fetcher SearchBot
835 Vivaldi Browser
836 WhatWeb SiteHelper
837 SiteBulb Crawler
838 BruteforceBot HackingTool
839 RootsMagic SiteHelper
840 Electron HackingTool
841 Generic Vulnerability Tool 841 VulnerabilityScanner
842 WireX DDoSBot
844 Splash HackingTool
846 Telegram FeedFetcher
847 ZmEu Vulnerability Scanner VulnerabilityScanner
848 Jorgee Vulnerability Scanner VulnerabilityScanner
850 TheOldReader FeedFetcher
851 G2Reader FeedFetcher
852 StartMe Bot Crawler
853 SendGrid SiteHelper
854 Imperva MX-Server SiteHelper
856 Kapow Extraction Browser FeedFetcher
857 JuriScraper FeedFetcher
858 Bitvore Crawler
859 Quanta-computing SiteHelper
860 WAFNinja VulnerabilityScanner
862 BufferBot FeedFetcher
863 SkypeForBusiness FeedFetcher
864 Tplmap VulnerabilityScanner
865 WPScannerBot VulnerabilityScanner
866 WPScan VulnerabilityScanner
867 BrandVerity Crawler
868 Manzama Crawler
869 WordPress DoS Tool HackingTool
870 Jaunt HackingTool
871 MageReport HackingTool


872 Dcrawl Crawler
873 Bot 873 HackingTool
874 Wallarm Scanner VulnerabilityScanner
875 Bot 875 HackingTool
876 Movable Ink FeedFetcher
877 Spam 404 877 SpamBot
878 SpamBot 878 SpamBot
879 Microsoft Exchange Online SiteHelper
881 Akamai Image Server SiteHelper
882 MeltwaterNews Crawler
883 Digimind Crawler
884 comScore Crawler Crawler
885 iPhone Calendar Agent FeedFetcher
886 MauiBot Crawler
887 Tableau Desktop FeedFetcher
888 python-aiohttp HackingTool
890 Alamofire Swift http library FeedFetcher
891 Node.js HackingTool
892 node-fetch HackingTool
893 Bot 893 Unknown
894 ManageWP SiteHelper
895 Uptrends Site Monitor SiteHelper
899 Android Download Manager FeedFetcher
900 AlexaMediaPlayer FeedFetcher
901 YahooMailProxy FeedFetcher
902 AFNetworking FeedFetcher
905 Apple Core Media FeedFetcher
906 SessionCam Tag tool SiteHelper
908 Microsoft BITS FeedFetcher
909 Dynamic Signal FeedFetcher
910 Guzzle PHP HTTP client HackingTool
911 WeChat WebView Browser
912 Yelp iOS App FeedFetcher
913 Yelp Android App FeedFetcher
917 Detectify Scanner VulnerabilityScanner
919 Needle Node.js HackingTool
920 Amazon Echo device FeedFetcher
923 LG SmartTV Browser
924 ATO Wordpress Client Worm


927 ATO Client Worm
934 RestSharp Client HackingTool
935 JAX-WS SiteHelper
936 Runscope API SiteHelper
938 Intuit Mint FeedFetcher
940 Instagram FeedFetcher
941 RyteBot Crawler
942 Sonos Speaker FeedFetcher
943 Cambridge Audio FeedFetcher
944 Spiceworks Agent SiteHelper
945 Nimbostratus Crawler
Azure Traffic Manager Endpoint
946 SiteHelper
Monitor
947 OpenBullet HackingTool
948 RedWolf DDoSBot
949 OnCrawl Crawler
950 Adyen Payment Client SiteHelper
951 Freeu Browser Browser
952 Amigo Browser Browser
953 Azure AD SiteHelper
954 AspiegelBot SearchBot
955 Datadog Synthetics SiteHelper
956 Hookshot HackingTool
957 Fornova SiteHelper
Apple App Site Association CDN
958 SiteHelper
bot
959 Nightmare Stresser DDoSBot
960 Line FeedFetcher
961 purplemet SiteHelper
963 Expanse Crawler
964 Microsoft Power BI FeedFetcher
965 Sajari Crawler
966 Nuclei VulnerabilityScanner
967 Postman HackingTool
968 Baqend SiteHelper
969 Google PageSpeed SiteHelper
971 Safe Exam Browser Browser
972 Neeva SearchBot
973 Stamps FeedFetcher
974 ZIQY SiteHelper
975 Smartly.io SiteHelper


Rules
Use the Imperva rules proprietary scripting language to implement your own security, delivery, and access control
rules on top of Imperva's existing security and application delivery logic.
In this topic:
• Overview
• Filters, triggers, and actions
• Rule management and revisions
• Monitor rule activity
Overview
Custom rules can be manually coded or generated using a dedicated GUI that helps you get acquainted with the rule
generation process.
Web application owners and security engineers can use the rules to improve the security and performance of their
websites and applications. For example, rules can be created to:
• Prevent bots from accessing a site’s registration form

• Restrict access to a specific part of an application based on IP address
• Limit the rate of requests to a website
• Manipulate traffic routes and redirects
• Control a request's URL structure, headers and cookies
Filters, triggers, and actions
The rule syntax was designed for simplicity. It relies on a few dozen descriptively-named parameters and a set of
logical operators. These elements are combined to form a trigger that leads to one of the pre-defined actions. To
illustrate just how intuitive this language is, here's an example of a rule that restricts public access to your
application’s admin:
In this case, the trigger is a combination of two filters - one to mark the restricted URL and another to prevent access
from all external IPs. Overall, the rules enable you to create policies based on:
• HTTP request methods (Post or Get)

• Header values
• URL parameters
• Client types (e.g., browser, search engine, feed fetched, etc.)
• IPs and Geo-locations
• Access rates on a request or session level

• Cookie and JavaScript support

• Pool of over 900 predefined client signatures (e.g., GoogleAds, CroneTask, WordPress bots, etc.)
The resulting actions may also vary, with options ranging from “Silent Alert”, to initiation of additional challenges
(e.g., CAPTCHA, JS, etc), to absolute blocking of a visitor or even null-routing of all traffic from a specific IP address.
Rule type Available rule actions
• Alert
• Block Request
• Block Session
Security and access control rules • Block IP
• Require Cookie Support
• Require Javascript Support
• Require CAPTCHA Support
• Redirect URL
Application delivery rules • Rewrite (URL, Header, Cookie)
• Forward
All in all, with its vast number of possible combinations, the rules allow for limitless possibilities, giving you the
flexibility you need to deal with any possible security scenario.
Rule management and revisions
Rules are managed at the site level for every protected web domain. In addition to creating, editing, and deleting
rules, the rules management interface enables revision management. Imperva maintains a list of revisions for every
rule, enabling administrators to review an audit trail of all rule changes and easily revert to a previous rule revision, as
needed.
Monitor rule activity
Similar to other Imperva security features, you can also monitor rule activity in a website's Dashboard and Events
pages.
Read More
• Create Rules
• Manage Rules

Create Rules
Create application delivery rules, or implement your own security and access control rules on top of Imperva's
existing security logic.
You can configure up to a maximum of 500 custom rules per site.
In this topic:
• Create a rule
• Define a rule filter
• Delivery actions
• Security actions
Create a rule
To open the Rules page to create a new rule, log in to your my.imperva.com account.

3. On the sidebar, click Security > Rules.
4. Click Add Rule.
The Add/Edit Rule page includes the following elements:

Field/Option Description
Define a filter to determine when the rule is applied.
The filter defines the conditions that trigger the rule

action. If left empty, the rule is always run.
Rule Filter
The rule filter can include up to 2048 characters.
For details, see Define a rule filter.
Rule Action Define the action you want Imperva to take for every
request that matches the rule.

For details, see:
• Delivery actions
• Security actions
• Create Rate Rules
• Create Simplified Redirect Rules
Give the rule a meaningful name.
Note:
• The Rule Name may not contain special

characters. Only alphanumeric, space, period
Rule Name (“.”), and underscore (“_”) characters are
allowed.
• Rate Rules: A rate rule name may not contain
special characters, including the underscore
("_") character or periods ("."). Only
alphanumeric characters, hyphens ("-"), and
spaces are allowed.
Enable or disable the rule.

Enable Rule
Note: The rule must be enabled if you want to use
the Test Rule option below.
Available for Security rules only.
Send an email notification whenever this rule is Note: Accounts with access to Notification Settings
triggered must also configure Real-Time WAF Alert
Notifications in Notification Settings. For more
details, see Notification Settings.
Activates the rule for a select number of IPs only.

When you create a rule, Imperva will detect your IP
and use that as the default IP for testing.
Test Rule Only on My IP Addresses
Rules propagate across the system immediately to
ensure that changes are applied in near real time.
In order to minimize the risk to your production

environment, it’s recommended to activate a new

or modified rule in test mode prior to activating
in production.
Save the rule and enter a revision comment. The

comment is stored as part of the rule revision for
future reference.
Note: The revision comment may not contain

Save
special characters. Only alphanumeric, space,
period (“.”), and underscore (“_”) characters are
allowed.
For details on revision history, see Manage Rules.
Define a rule filter

Define a filter for the rule using predefined parameters.
For the full list of parameters, see Rule Filter Parameters.
Example:
Under If, select the part of the request or the

Matched object sessions to which the filter is applied. For example,
Client IP or Country. For full details on the available
parameters, see Rule Filter Parameters.

Defines how the filter value is matched.
Operator
Most filter parameters support only a subset of the

list of operators. For example, the QueryString filter
parameter supports only the ‘equal to’ and ‘not
equal to’ operators. When a filter parameter is
selected (see Matched object above), only the
supported operators will be displayed in the
operator field.
For the full list of filter parameters and the

supported operators for each, see Rule Filter
Parameters.
Value The value to be matched.
When you define a filter and click +Add, the filter

Editor syntax is added to the Editor. You can add as many
filters as required. The filters are added to the rule
syntax using the AND logic. For information about

combining filters using the OR logic, refer to the

Syntax Guide.
Alternatively, you can add filters directly using the

native syntax. Every rule is checked for syntax
validity before it is saved. For details, see the Syntax
Guide.
Note: When defining application delivery rules (not

security rules) an empty rule filter will match any
request.
Verifies the rule syntax. Validation is also performed

Validate
automatically whenever you save a rule.
Delivery actions
Define the action you want Imperva to take for every request or response that matches the rule filters.
Note: When a server is identified as 'down' by the Imperva Load Balancer, our proxies start to send active monitoring
requests to the origin server that is defined for the site, using the site’s Host header. (Origin servers are defined for the
site in the Cloud Security Console in Websites > Settings > Origin Servers.)
If there are custom delivery rules defined for the site, such as forward or rewrite rules, they are not run.
Therefore, the default origin server itself must be able to receive requests from the proxy so that we can confirm
server availability.
For more details on active monitoring, see Load Balancing Monitoring Settings.
In this section:
• Redirect URL
• Rewrite request
• Rewrite response
• Forward
• Replacement logic and wildcards
• Variables
Redirect URL
Redirect a URL. When a request matches a condition of a redirect rule, Imperva responds with a 30X response code
which redirects the client to a different URL.
The redirected URL can be fixed for all requests matching the rule condition or, alternatively, can be customized based
on the specific request line of each request.
The supported redirect codes are: 301, 302, 303, 307 and 308 (Redirect codes W3C specification ).
Redirect rules are the first type of rules to be evaluated. This means that if a redirect action has been triggered,
Imperva will stop inspecting the request for other rules.

Example: Redirect to a new site.
Original request: http://www.oldsite.com/sport/football
Redirected request: http://www.newsite.com/sport/football
Note: Redirect to FQDN and redirect to HTTPS in Website > Settings > General have a higher priority than rules in the
Rules table. To maximize ease-of-use, it’s recommended to define all redirect rules in the Rules table.
Rewrite request
The rewrite/remove actions can be used to modify, add, and remove different request attributes such as URL,
headers, and cookies. Imperva receives the request from the client, applies the relevant changes, and then forwards
the request to the origin server. Responses to Rewrite actions are cached by default.
Use the Add new if missing option to add a header or cookie that is absent from the original request. Note: You
cannot use this option when the To field contains wildcard variables $1, $2, ..., as Imperva cannot determine the value
of the header.
Available rewrite actions:
Action Description
Modifies the path to which a specific request is

Rewrite Request URL targeted. In such a case, the client enters a certain
path in his browser, while the server uses a different
path to serve the requested resource.

Action Description
User enters www.mysite.com/football in his browser

and is served by the www.mysite.com/sport/football
page with no change to the request line.
Notes:
• The URL doesn’t include the scheme or host

name/domain - only the request path.
• The URL should start with a “/”.
• If the host name/domain needs to be
rewritten, a header rewrite action rule for the
Host header should be defined.
• Wildcards and variables are supported in URL
rewrite.
Modifies or adds a request header before passing

traffic to the origin server.
The user has to indicate the header name, whether

the header should be added if it is absent from the
original request, and the new header value.
Rewrite Request Header
When rewriting the Host header, the following
aspects should be kept in mind:
• Host header modification affects SNI host

name as well
• In case the modified Host header value (host
name/domain) is served from a different

Action Description
origin server, a Forward rule should be
configured to direct the request to the
appropriate origin server (data center)
Notes:
• To add a header that is absent from the

original request, use the Add new if missing
option.
• Wildcards and variables are supported in
Header rewrite.
• A header can be removed using the Remove
Header action.
• The following headers are restricted and
cannot be rewritten: Cache-Control, Content-
Type, Content-Length, Transfer-Encoding and
Content-Encoding.
Remove Request Header Removes a specific request header so that it won’t

be sent to the origin server.

Action Description
In this example, the X-Old-Header header will be

removed from any request in which it appears.
Remove multiple header occurrences: Removes all

occurrences of the specified header from the
request. By default, only the first occurrence of the
header is removed
Modifies or adds cookies that are sent by the client

to the origin server. The cookie name and value
should be indicated.
Rewrite Request Cookie If the web application expects to receive a cookie to

identify a specific client characteristic (e.g., device
type), a new cookie can be sent to the origin without
actually setting a cookie on the client side (the
cookie is created on the Imperva edge and sent to
the origin).

Action Description
The value of the theme cookie will be set to light for

requests towards the origin (theme=light).
Notes:
• To add a cookie that is absent from the

original request, use the Add new if missing
option.
• Wildcards and variables can be used for cookie
rewrite.
• A cookie can be removed using the Remove
Cookie action.
Remove Request Cookie Removes a specific cookie set on the client, which
means that it won’t be sent to the origin server.

Action Description
The cookie theme will be removed.
Rewrite response
The rewrite/remove actions can be used to do the following, before the response is returned to the client.
• modify, add, and remove headers from the response

• rewrite the HTTP response status code
• replace the default error response and error code
Imperva receives the response from the origin server, applies the relevant changes, and then returns the response to
the client.
Use the Add new if missing option to add a header that is absent from the original response.
Wildcards and variables are supported for header rewrite.
Note: You cannot use the Add new if missing option when the To field contains wildcard variables $1, $2, ..., as
Imperva cannot determine the value of the header.
Action Description
Modifies or adds a response header before passing

the response back to the client.
Enter the header name, the new header value, and

Rewrite Response Header
whether the header should be added if it is absent
from the original response.
Note: The following headers are restricted and

cannot be rewritten: Cache-Control, Content-Type,

Action Description
Content-Length, Transfer-Encoding and Content-
Encoding.
Removes a specific response header so that it won’t

be sent back to the client.
Remove Response Header
In this example, the X-Old-Header header will be

removed from any response in which it appears.
Remove multiple header occurrences: Removes all

occurrences of the specified header from the
response. By default, only the first occurrence of the
header is removed.
Modifies the status code in the response from the

origin server before sending it back to the client.
Rewrite Response Code
The Response Status Code field accepts any 3-digit
number.
Replaces the default error response and error code

that are returned to the client when a request is
Rewrite Response Error
blocked. For details, see Create Custom Error
Response Rules.
Forward
Responses to Forward actions are cached by default.

Select the data center to which a specific request

will be sent.
The target data center can include a single origin

server or multiple origin servers in a load balanced
mode.
To use a data center for forwarding, select the

Support only forward rules option on the Origin
Server settings page.
Data centers that are configured to support

forwarding can accept requests only through the
Forward rule, and cannot be used to support Global
Server Load Balancing.
Forward to Data Center GSLB between Data Centers used for Forwarding is
not supported.
The data centers that are configured to support

forwarding are displayed in the Target Data Center
drop-down list.
Forward matching requests to a specific port on the

origin server.
Context: Select one of the following:

Forward to Port
• Use Port Value: Enter a port number.
• Use Header Name: Enter the name of the
request header that includes the port number
in the format IP:PORT.
Value: Enter the port number or header name.

Note: A custom rule configured with the Forward to

Port action overrides the Port Forwarding setting
on the Delivery Settings page.
Replacement logic and wildcards
When defining delivery actions, such as rewrite or redirect, string replacements can be a useful tool for keeping the
number of rules under control and easy to manage.
String replacements work in the following way:
• There are always From and To fields.

• The string in the From field represents the full string to be replaced and may include wildcards.
• In order for a rule to apply, there must be an exact match on the From field. This is an additional filtering layer
on top of the rule criteria filter.
• The To field represents the full string replacement target. It may contain a reference to the wildcards used in the
From field, causing replacements to behave in a dynamic manner during request runtime.
• The asterisk wildcard * can be used in the From field, each * can be referenced using the $ character in the To
field.
• The asterisk will match the first instance in the string (unlike in regular expressions).
• A rule can support up to nine different asterisks: $1 will refer to the first *, $2 to the second *,...,$9 to the ninth *
Example: Using wildcards in a redirect rule.
Original request: http://www.mysite.com/sport/football

Redirected request: http://www.mysite.com/football/sport
Variables
The following variables can be used in the To field, for both redirect and rewrite actions:
Variable Description Sample Values

$scheme Request scheme/protocol. http or https
$host Host header value - the host name. www.mysite.com
$path Request line path. /sport/football/results.php
$args Request line arguments. country=US&year=2016
/sport/football/results.php?
$url $path + ? + $args
country=US&year=2016
The client's outgoing port number.

$src_port It can be used, for example, to 777
distinguish users behind NAT.
$continent Two character continent code. EU
Two character ISO 3166-1 country

code.
$country When the country cannot be NL

identified, such as for an IP using
an anonymous proxy, the code 00
is used.
Two character state, province, or

$state CA
region, where applicable.
$city City name. Amsterdam
$latitude Approximate latitude coordinates. 4.863890
Approximate longitude
$longitude 52.300830
coordinates.
Postal/zip code. May be available
$postalcode for requests from specific 1191
countries.
The Imperva ID for the client
$client_id application. For the full list, see 15
The client application type. For the
$client_type Browser, SpamBot
full list, see Client Classification.
$tls_version TLSv1.3
The TLS version.


One of TLSv1.3, TLSv1.2, TLSv1.1,
TLSv1.0, SSLv3.
The Unix timestamp - an integer

value representing the number of
$epoch microseconds that have elapsed 1502617252081
since the beginning of the Unix
epoch (January 1, 1970).
The Autonomous System Number.
$asn It can be used to send the client's 1680
ASN to the origin in a header.
The ID number of the Imperva
$proxy_id 1321, 577, 974
proxy that handled the request.
The 3-letter code of the Imperva
$pop data center through which the IST, FRA, NYC
request was routed.
The 3-letter code of the Imperva

data center through which the
request was routed, in the event
$origin_pop that Dynamic Content Acceleration IST, FRA, NYC
(Origin PoP) is enabled for the
website. For details, see Dynamic
Content Acceleration.
A unique identifier assigned to the

$session_id 7810007910000525005
session.
A unique identifier assigned to the
$request_id 30543417808161
request.
The ID number of the protected
$site_id 78672523
website.
The ID number of the Imperva
$account_id 225390
account to which this site belongs.
Certificate represented in base-64
ccrt
ASCII encoding
Certificate represented in PEM
format — Base64 ASCII encoding
ccrt_pem which includes the "-----BEGIN
CERTIFICATE-----" and "-----END
CERTIFICATE-----" lines.
Common name. Represents the
ccrt_cn server name protected by the SSL *example.com
certificate.
The serial number — a unique
ccrt_serial identifier assigned by the CA that 101
issued the certificate.


Information on the certificate
ccrt_subj CN=*example.com,OU=cwaf,O=exampleco,L=pt,ST=PT,C
owner's identity
/C=IL/ST=PT/L=pt/O=exampleco/
ccrt_rfc_s Subject in rfc2253 format.
OU=cwaf/CN=*example.com
The unique identifier of the SHA1
ccrt_fp
certificate as SHA-1. Fingerprint=AD:22:94:15:5A:74:5C:27:F4:D1:14:74:6F:75:C
SHA256
ccrt_sha25 The fingerprint as SHA-256.
Fingerprint=B3:C0:FA:AD:36:2F:56:54:31:22:5C:24:26:EA:A
The DNS field from the subject
ccrt_dns DNS:*example.com
alternative names (SAN).
Examples:
Use variables to redirect requests to a new path (/football), maintaining the original scheme, domain, and
arguments.
Original request: https://www.mysite.com/sport/football/results.php?country=US&year=2016
Redirected request: https://www.mysite.com/football?country=US&year=2016
Use variables to rewrite request headers.

Identify the Imperva data centers that are most frequently used for your visitors. In this example, every
request that reaches your origin server will include the Imperva-PoP header with the value of the Imperva
data center that handled the request.
Security actions
Define the action you want Imperva to take for every request that matches the rule filters:
Rule action Description Notes

Generates a non-blocking alert for
Alert Useful for testing new rules.
this event.
Blocks the current request and
Block Request Preferred block action.
generates an alert.
Blocks the current session and Session is based on the Imperva
generates an alert. Any session cookie - not the
Block Session
subsequent request from the same application's session (e.g.
session is blocked. JSESSIONID).
Blocks the current IP and
generates an alert. Any Use with caution. Clients
Block IP subsequent request from the same originating from a VPN, proxy, or
IP is blocked for a period of 10 NAT may be inadvertently blocked.
minutes.

Rule action Description Notes
Enables you to define an

alternative WAF action for a subset
of your domain for a specific threat
type.
This can be useful if your website

Overrides the global WAF setting
hosts several applications and you
Override WAF Settings defined on the Web Protection -
want to define a different threat
WAF Settings page.
response for one or more of the
applications, such as Alert instead
of Block.
For more details, see Override

WAF Settings.
Requires any client that matches

May be of limited value when
Require Cookie Support the rule filters to support cookies
working with APIs.
in order to complete the request.
Requires any client that matches
the rule filters to support
Since the JavaScript test is
Javascript in order to complete the
embedded in an HTML page, this
Require Javascript Support request. Since the Javascript test
action should only be enabled for
is embedded in an HTML page, this
HTML resources.
HTML resources.
Requires any client matching the
rule filters to pass a CAPTCHA test
Since the CAPTCHA test is
in order to complete the request.
Require CAPTCHA Support Since the CAPTCHA test is
HTML resources.
HTML resources.
Read More


Create Rate Rules

In addition to built-in rate parameters, you can create custom rates to use in security and delivery rules. A rate filter
triggers the rule when the rate passes a specified threshold.
For example, you can create a security rule for the following scenario:
If a client accesses /login.html from China more than 20 times per minute, block it.
This new functionality boosts your ability to mitigate brute force or scraping attacks, which use a high rate of activity
to gain unauthorized access to resources. It also helps detect uncommon or irregular user behavior. Custom rate rules
are an extension of our existing mitigation capabilities in which you can create custom security or delivery rules to
meet a specific need.
Note: Due to the asynchronous nature of the system, rate rules may be triggered only after the rate count passes the
threshold by several requests. Therefore, rate rules are recommended for use cases that are tolerant to such events.
For example, you might want to use it to make sure that a specific API is not called more than 500 times in a minute.
In this topic:
• How does it work?

• How to create custom rate rules
• Using a rate rule in the API
How does it work?
Step1: Create a rate rule.
A new Count (Rate) action is available in rules. A rate rule counts the number of requests received that match your
specified criteria within a specified amount of time. For example, how many requests for your site's login page are
received per minute.
• Rates can be counted per IP or per session.

• Rate rules are run after redirect rules.
• You can create up to 32 counters (rate rules) per site.
• The rate is counted per proxy, not globally.
Step 2: Use the rate as a filter in a security or delivery rule.
Once the rate rule is created, you can create a new security or delivery rule, using the rate in the rule filter. For
example, if the login rate you defined above is greater than 12, send an alert.
Note: A custom rate rule that is used by another rule cannot be disabled or deleted.
How to create custom rate rules
To create a rate rule:
1. In the Cloud Security Console, navigate to Websites > Rules.

2. Click Add Rule to create a new rule.

3. Create the rule filter according to your needs.
For more details, see Create Rules and Rule Filter Parameters.
4. Under Rule Action, select Count (Rate).
Context: IP or Session.
Interval: Enter a value between 10 and 300. It must be a multiple of 10.
5. Give the rule a name and save it.
A rate rule name may not contain special characters, including the underscore ("_") character or periods (".").
Only alphanumeric characters, hyphens ("-"), and spaces are allowed.
The rule is now listed under Rates on the Rules page.

To create a rule using the custom rate:
1. On the Rules page, click Add Rule to create a new rule.

2. In the rule filter, in the If field, select Custom Rate.
3. In the Rate field, select a custom rate you previously created.
In this example, you select a rate you created called Login Rate that measures requests for your site's login
page:
Tip: You can include multiple filters and rates in a single rule.
4. Fill in the remainder of the fields, selecting the Security or Delivery rule action you want, such as Alert.
Using a rate rule in the API
A rate rule name may not contain special characters, including the underscore ("_") character or periods ("."). Only
alphanumeric characters, hyphens ("-"), and spaces are allowed.
When using a rate rule in the API, make sure to follow the accepted syntax for rule filters, as follows.
If the name of your custom rate rule includes spaces, replace the spaces with hyphens ("-") to use the rate rule as a
filter in another rule.
For example, on the Rules page, if a custom rate rule named Login Rate rule is used in another rule, it would look like
this:
In the API, use login-rate instead of Login Rate.

Read more
• Create Rules

Create Simplified Redirect Rules

Redirect rules enable you to redirect client requests to a different URL, responding with a 30X response. Simplified
redirect rules provide basic redirect functionality and enable you to create up to 20,000 redirect rules per site in your
account. This is in addition to the 500 regular redirect rules, other delivery rules, and security rules you can create per
site.
In this topic:
• Enable simplified redirect rules for your account

• Create a simplified redirect rule
• Guidelines
• Create simplified redirect rules using the API
Enable simplified redirect rules for your account
Before you can create simplified redirect rules for your sites, you need to enable the functionality in your account.
1. Log in to your my.imperva.com account and do one of the following:
On the top menu bar, select Account > Account Management to open Account Settings.
2. Select Allow sites to add a large number of redirect rules.

Create a simplified redirect rule
On the Cloud Security Console sidebar, click Security > Rules to access the Rules page and create a new rule.
Guidelines
Simplified redirect rules must be configured as follows:
Rule Fields
Field Requirements
Rule Filter The rule filter must be left empty.
Rule Action Select Simplified Redirect.
• The URL can include hostname and/or request

line path. It may not include the scheme/
protocol (http/https). For more details, see
From URL format.
• Must be unique - no other simplified rule may
have the same path in the From field.
• May not include wildcards.
To • Must contain scheme and hostname, or

scheme and hostname variables. For example,

Field Requirements
https://www.example.com/abc or $scheme://
$host/abc.
• Path may be empty. For example, https://
www.example.com.
• May not include $numeric. For example, $1, $2
that are used in regular redirect rules to
correspond to wildcards in the From field are
not allowed.)
For more details on configuring the From and To fields in redirect rules, see Create Rules.
URL format
The URL in the From field can use any of the following formats
Priority URL in the "From" field Example

1 host/path?query_string www.example.com/news?red=1
2 host/path www.example.com/news
3 host www.example.com
4 path?query_string /stores?blue=1
5 path /stores
The incoming request is evaluated to see if there is an exact match to one of the simplified redirect rules. If a request
matches more than one rule, the priority goes according to the order above.
For example, a request for www.example.com/stores?blue=1 will be redirected according to rule #3 above, and not #4,
because it is matched to rule #3 first.
Alternatively, a request for www.demo.com/stores?blue=1 will be redirected according to rule #4.
Note: To match any request to a given host, the URL must not include a /. For example www.exampe.com/ will only
match requests for /, while www.example.com will match a request for any path.
Create simplified redirect rules using the API
Create and manage simplified redirect rules using the standard API rule operations.
For rule action, use RULE_ACTION_SIMPLIFIED_REDIRECT.
For details, see Cloud WAF v2 API Definition.
Read More
• Create Rules
• Site Management API


Create Custom Error Response Rules

Control the error response that is returned to the client when a request is blocked.
A custom error response rule enables you to replace the default error response and error code that are returned to the
client.
In this topic:
• Create a custom error response rule

• Error types
• Custom error response API
Create a custom error response rule
In the Cloud Security Console, navigate to Websites > Rules to access the Rules page and create a new rule. You can
create up to 50 custom error response rules per site.
Configure the rule as follows:
Rule Filter
For details, see Create Rules.
Rule Action
Field Requirements
Action Select Rewrite Response > Error.
Select the error type that triggers this rule.

Error Type
For descriptions of the available error types, see
Error types.
Select the standard HTTP status code to return when

the rule is triggered.
Response Status Code
Options include 4xx client error codes and 5xx server
error codes.
Response Body Define the response to return when the rule is

triggered.

Field Requirements
Accepted formats are JSON or XML. Use the sample
template that is provided or edit as desired.
Click Restore Default to cancel your edits and

restore the default template.
Error types
Select the error type that you want to trigger the custom error response rule.
Error type Description

All error types All error types trigger this custom rule.
Connection timeout
timed out.
the client.
the origin server.
Initial connection denied - cookie or challenge The request is sent by a cookieless visitor or requires
required an HTML challenge.
the origin server.
challenge.
The request is blocked pending two-factor
Initial connection denied - 2FA required
authentication.
Security Console.
The request is attempting to access the site with
IPv6 not enabled for the site IPv6 but IPv6 is not enabled for the site in the Cloud
Security Console.
Custom error response API
Create and manage custom error response rules using the standard API rule operations.
For rule action, use RULE_ACTION_CUSTOM_ERROR_RESPONSE.
For details, see Cloud WAF v2 API Definition.
See also:
• Rules

• Error Responses

Override WAF Settings
Create a custom rule to override WAF settings for a subset of your protected website, enabling you to apply a more
granular mitigation strategy.
In this topic:
• Overview
• How to override a WAF setting
• Example
Overview
You can create a custom rule to override the global WAF setting defined on the Web Protection - WAF Settings page.
This enables you to define an alternative WAF action for a subset of your domain for a specific threat type.
It can be useful if your domain hosts multiple applications and you want to define a different threat response for one
or more of the applications, such as Alert instead of Block.
How to override a WAF setting
Create a new rule, configured as follows.
For details on accessing the Rules page, see Create Rules.
Field Description
Define the rule filter to determine when to apply this

Rule Filter
rule.
Action Select Override WAF Setting.
WAF Setting to Override Select the threat type setting you want to override.
Select the alternative WAF action to use for requests

WAF Action
that match this rule.
Note: If there is at least one active override rule for a WAF setting, a warning is displayed on the WAF Settings page:

Example
Suppose your domain hosts three versions of your application, used for different geographical areas:
• example.com/NL
• example.com/HK
• example.com/SG
Your WAF setting for Illegal Resource Access is as follows:
If you want to receive alerts for the relevant requests for the SG application instead of blocking them, you can create a
custom rule as follows:

Syntax Guide
Rule filters are composed by combining predicates using AND/OR operators (&,|). Each predicate is comprised of:
• Parameter / matched object: The part of the request or the sessions to which the filter is applied. For example,
Client IP or Country.
• Operator: Defines how the parameter value is matched. For example, "greater than" or "equals". Each matched
object can have its own unique set of operators based on its characteristics.
• Value: The value to be matched.
Operators
The following operators are available. Most filter parameters support only a subset of the list of operators. For the full
list supported operators for each filter parameter, see Rule Filter Parameters.
Operator/UI option Filter syntax

== (equal to) == "<your string>"
!= (not equal to) != "<your string>"
Contains contains "<your string>"
Does not contain not-contains "<your string>"
contains "^<your string>"

Starts with
For example: contains "^login"
contains "<your string>$"

Ends with
For example: contains "login$"
Does not start with not-contains "^<your string>"

Does not end with not-contains "<your string>$"

Reserved Characters
Syntax Description Example
“ Used to enclose textual values URL == "/admin"
Used to combine two predicates

with an AND logic
Note: When using CURL:

URL == "/admin" & CountryCode
&
== GB
• Use %26 instead of &
• Each element joined by %26
must be enclosed in
parentheses
ClientIP == 192.168.1.1 & (URL ==

Used to combine two predicates
| "/admin" | QueryString !=
with an OR logic
"s=search")
Used to create a list of multiple
; URL == "/admin";"/home"
values to match
Used to escape reserved
\" QueryString != "s=\”search\”"
characters
Used to construct complex
() A & B & (C | D) & F *
predicate logic
Note: Mixed AND/OR operators cannot be enclosed by the same parenthesis
Read More
• Create Rules

Rule Filter Parameters

The following parameters are available for use when defining rules.
Note: You define rule filters in the Add Rule page. For details, see Create Rules.
To define the rule filter, you can select filter options available in the UI, or add filters directly using the native syntax.
For details on the correct syntax, see the Syntax Guide.
For examples of rules you can use to address some common use cases, see Security Rule Use Case Examples and
Delivery Rule Use Case Examples.
There are several categories of filter parameters:
Provide information about the connecting client. For

Client Parameters
example, Client IP or Client ID.
Provide information about the current
Request Parameters HTTP request. For example, Query String or Header
Value.
Provide information about the response coming
Response Parameters
from the origin. For example, response code.
Provide a running count of the number of actions

Counter Parameters performed. For example, Attack Count or Page Hits
Counter.
Client Parameters
ASN
The client IP Autonomous System Number (ASN).
Example: ASN == 71
Supported Operators
UI Predicates Description
== Is equal to
!= Is not
City
The name of the city where the client sending the request is located.
Example: City == "Amsterdam"

Supported Operators
== Is equal to
!= Is not
Client Certificate CN
The common name of the client certificate, if one exists.
Example: ClientCrtCN == "yoursite.com"
Supported Operators
== Is equal to
!= Is not
contains Value contains
not-contains Does not contain
Client ID
The Imperva ID for the client application. For example:
• Googlebot (Search bot) (6)
• cURL (Developer Tool) (47)
When adding or editing a rule in the Cloud Security Console, start entering text in the value field to display a list of
available values.
Example: ClientId == 15
Note: When used in a cache rule, this parameter may be used with the Enrich Cache Key rule action only.

Supported Operators
== Is equal to
!= Is not
Client IP
The client (source) IP of the current request.
Example:
ClientIP == 120.0.0.1
You can also enter an IP using CIDR notation, such as 120.0.0.1/24.
Supported Operators
== Is equal to
!= Is not
Client Type
The client application type, such as Browser or SpamBot. Select from the list of available values.
Example: ClientType == Browser
Supported Operators
== Is equal to
!= Is not
Continent Code
The client (source) IP origin continent.
Example: ContinentCode == "EU"
Supported Operators
== Is equal to
!= Is not

Country Code
The client (source) IP origin country.
Example: CountryCode == GB
Supported Operators
== Is equal to
!= Is not
Declared Client Id
The ID of the client application, according to the declaration in the UserAgent HTTP header.
When adding or editing a rule in the Cloud Security Console, start entering text in the value field to display a list of
available values.
Example: DecClientId == 77 (Java Developer Tool)
Supported Operators
== Is equal to
!= Is not
Declared Client Type
Client type based on the client declaration in the UserAgent HTTP header.
Example: DecClientType == "Browser"

Supported Operators
== Is equal to
!= Is not
Epoch
The UNIX timestamp of the request - the number of microseconds since midnight January 1, 1970.
Example: Epoch == 1502617252
Supported Operators
== Is equal to
!= Is not
> Value is larger than
< Value is smaller than
>= Value is greater than or equal to
<= Value is equal to or smaller than
IP Reputation Risk Level
The risk level posed by this IP, based on the assessment of the Imperva Reputation Intelligence service. For more
details, see Reputation Intelligence.
The risk assessment is based on activity of this IP across the Imperva customer base over the previous 2 weeks (clean
and malicious traffic). Risk is continually evaluated so the risk level for a given IP can change on a daily basis.
The calculation takes into account the number of attacks, the number of Imperva customer accounts that were
attacked, and the severity of attacks by this IP.
Possible values and their associated risk levels:
• Low: 0-24
• Medium: 25-74
• High: 75+
Example: IPReputationRiskLevel >= Medium
This will filter for requests from source IP addresses whose risk score is medium or high.

Supported Operators
== Is equal to
Is Mobile
Distinguishes between requests coming from mobile devices and requests coming from desktop clients based on the
user-agent used in the request.
Example:
This rule is triggered when a request made for URL path “welcome.html” is sent from a mobile device.
URL == "/welcome.html" & isMobile == Yes
Supported Operators
== Is equal to
!= Is not
Latitude
The approximate latitude coordinates of the client sending the request.
Example: Latitude == 4.863890
Supported Operators
== Is equal to
!= Is not
Longitude
The approximate longitude coordinates of the client sending the request.
Example: Longitude == 4.863890

Supported Operators
== Is equal to
!= Is not
Malicious IP List
The client (source) IP address of the request is identified as an anonymous proxy IP or a Tor exit node.
Example: MaliciousIPList == TorIPs | MaliciousIPList == AnonymousProxyIPs
Possible values
• AnonymousProxyIPs
• TorIPs
Supported Operators
== Is equal to
Postal Code
The postal/zip code of the client sending the request. May be available for requests from specific countries.
Example: PostalCode == 123456
Supported Operators
== Is equal to
!= Is not
Source Port
The client's outgoing port number. It can be used, for example, to distinguish users behind NAT.
Example: SrcPort == 6000

Supported Operators
== Is equal to
!= Is not
State
The state, province, or region where the client sending the request is located.
The State parameter supports any 2-character alphanumeric string, including:
• states within the United States, according to their ISO codes

• regions or subdivisions in countries outside of the United States. according to their 2-character ISO codes
The State parameter must be used together with the CountryCode parameter to identify requests from a specific
state, province, or region of a country.
Examples:
CountryCode == US & State == NY for New York in the United States
CountryCode == UA & State == 43 for the Crimea region of Ukraine
Supported Operators
== Is equal to
!= Is not
User Agent
Checks for the specified string pattern in the User-Agent header in the client request.
Example: User-Agent contains "googlebot"
Note: This parameter cannot be used with the Cache Resource rule action.
Supported Operators
== Is equal to
!= Is not

starts with Starts with
ends with Ends with
does not start with Does not start with
does not end with Does not end with
Counter Parameters
API Rate
Measures the rate of API requests in a client session during a one minute period.
Example: Rate >= {api-rate;4}
Supported Operators
== Is equal to
!= Is not
>= Value is equal to or larger than
API Rate IP
Measures the rate of API requests from a single IP during a one minute period.
Example: Rate >= {api-rate-ip;4}
Supported Operators
== Is equal to
!= Is not
Ajax Rate General
Measures the rate of AJAX requests (x-requested-with) per session over a period of 1 minute.
Example: Rate > {ajax-rate-general;4}

Supported Operators
== Is equal to
!= Is not
Ajax Rate GET
Measures the rate of GET AJAX requests (x-requested-with) per session over a period of 1 minute.
Example: Rate > {ajax-rate-get;4}
Supported Operators
== Is equal to
!= Is not
Ajax Rate POST
Measures the rate of POST AJAX requests (x-requested-with) per session over a period of 1 minute.
Example: Rate > {ajax-rate-post;4}
Supported Operators
== Is equal to
!= Is not
Attack
Checks whether the request generated an attack alert.

Example: Attack == Yes
Supported Operators
== Is equal to
!= Is not
Attack Count
The number of attack alerts in the current or previous requests in a session.
Example: AttacksCount >= 5
Supported Operators
== Is equal to
!= Is not
Attack IP
Measures the rate of malicious (blocked) requests per IP over a period of 1 minute.
Example: Rate > {attack-ip;4}
Supported Operators
== Is equal to
!= Is not
Custom Rate
Use a custom, user-defined rate to filter the traffic and trigger your rule when the rate passes a specified threshold.
For example:

Supported Operators
For details on creating custom rates, see Create Rate Rules.
Dynamic Page Rate
Measures the rate of requests per IP to known resource-intensive pages over a period of one minute.
Example: Rate >= {dynamic-content-rate-ip;4}
Supported Operators
== Is equal to
!= Is not
<= Value is less than or equal to
Get Page IP Rate
Measures the rate of GET requests per IP address over a period of one minute.
Example: Rate >= {get-page-ip;4}
Supported Operators
== Is equal to
!= Is not

Home Page Rate
Measures the rate of requests to the homepage (/) per session over a period of 1 minute.
Example: Rate > {homepage-rate;4}
Supported Operators
== Is equal to
!= Is not
Home Page Rate IP
Measures the rate of requests to the homepage (/) per IP address over a period of 1 minute.
Example: Rate > {homepage-rate-ip;4}
Supported Operators
== Is equal to
!= Is not
Login BF Admin Sugarcrm
Measures the rate of requests to a SugarCRM login page per IP over a period of 1 minute.
Example: Rate > {login-bf-sugarcrm;4}
Supported Operators
== Is equal to
!= Is not

Login BF Admin Zencart
Measures the rate of requests to a Zen Cart login page per IP over a period of 1 minute.
Example: Rate > {login-bf-admin-zencart;4}
Supported Operators
== Is equal to
!= Is not
Login BF Concrete 5
Measures the rate of requests to a concrete5 login page per IP over a period of 1 minute.
Example: Rate > {login-bf-concrete5;4}
Supported Operators
== Is equal to
!= Is not
Login BF Drupal
Measures the rate of requests to a Drupal login page per IP over a period of 1 minute.
Example: Rate > {login-bf-drupal;4}

Supported Operators
== Is equal to
!= Is not
Login BF Joomla
Measures the rate of requests to a Joomla login page per IP over a period of 1 minute.
Example: Rate > {login-bf-joomla;4}
Supported Operators
== Is equal to
!= Is not
Login BF osCommerce
Measures the rate of requests to a osCommerce login page per IP over a period of 1 minute.
Example: Rate > {login-bf-oscommerce;4}
Supported Operators
== Is equal to
!= Is not
Login BF Php My Admin
Measures the rate of requests to a PHPMyAdmin login page per IP over a period of 1 minute.

Example: Rate > {login-bf-phpmyadmin;4}
Supported Operators
== Is equal to
!= Is not
Login BF Wp
Measures the rate of requests to a WordPress login page per IP over a period of 1 minute.
Example: Rate > {login-bf-wp;4}
Supported Operators
== Is equal to
!= Is not
Login IP
Measures the rate of requests to a login page per IP over a period of 1 minute.
Example: Rate > {login-ip;4}
Supported Operators
== Is equal to
!= Is not

Login IP Common Admins
Measures the rate of requests done with common administrator credentials per IP over a period of 1 minute.
Example: Rate > {login-ip-common-admins;4}
Supported Operators
== Is equal to
!= Is not
Login IP Common Passwords
Measures the rate of requests to a login page with a list of common passwords per IP over a period of 1 minute.
Example: Rate > {login-ip-common-passwords;4}
Supported Operators
== Is equal to
!= Is not
Number of User Agents
The number of unique user agents header strings in one session.
Example: NumberOfUserAgents > 7
Supported Operators
== Is equal to
!= Is not

Page Hits Counter
The number of page views in the client session.
Example: PageHitsCounter >= 2
Supported Operators
== Is equal to
!= Is not
Page Rate
Measures the rate of HTML requests per session over a period of 1 minute.
Example: Rate > {page-rate;4}
Supported Operators
== Is equal to
!= Is not
Page Rate IP 1m
Measures the rate of HTML requests per IP address over a period of 1 minute.
Example: Rate > {page-rate-ip-1m;4}
Supported Operators
== Is equal to
!= Is not

Page Rate IP 5s
Measures the rate of HTML requests per IP address over a period of 5 seconds.
Example: Rate > {page-rate-ip-5s;4}
Supported Operators
== Is equal to
!= Is not
Post IP
Measures the rate of POST requests per IP address over a period of one minute.
Example: Rate >= {post-ip;5}
Supported Operators
== Is equal to
!= Is not
Post IP 5s
Measures the rate of POST requests per IP address over a period of 5 seconds.
Example: Rate > {post-ip-5s;4}

Supported Operators
== Is equal to
!= Is not
Post Rate
Measures the rate of POST requests per session over a period of one minute.
Example: Rate >= {post-rate;6}
Supported Operators
== Is equal to
!= Is not
Request Rate IP
Measures the rate of requests per IP over a period of one minute.
Example: Rate > {request-rate-ip;4}
Supported Operators
== Is equal to
!= Is not
Request Rate Session
Measures the rate of requests per session over a period of one minute.

Example: Rate >= {request-rate-session;4}
Supported Operators
== Is equal to
!= Is not
> Value is smaller than
< Value is larger than
Request Rate Wl IP
Whitelisted requests per IP over a period of one minute.
Example: Rate > {request-rate-wl-ip;4}
Supported Operators
== Is equal to
!= Is not
Request Rate Wl Sess
Whitelisted requests per session over a period of one minute.
Example: Rate > {request-rate-wl-sess;4}
Supported Operators
== Is equal to
!= Is not

Session Creation IP Rate
Sessions with more than 5 requests from a specific IP during a 5 minute period.
Example: Rate > {session-creation-ip;4}
Supported Operators
== Is equal to
!= Is not
Site Request Rate
Measures the RPS (requests per second) for the website over a period of 5 seconds.
Example: SiteRequestRate > 300
Supported Operators
== Is equal to
!= Is not
Site Average Request Rate 1m
Measures the average RPS (requests per second) for the website over a period of 1 minute.
Example: SiteAverageRequestRate1m > 3500
Supported Operators
== Is equal to
!= Is not

Static Rate IP 5s
Measures the rate of non-HTML requests per IP address over a period of 5 seconds.
Example: Rate > {static-rate-ip-5s;4}
Supported Operators
== Is equal to
!= Is not
XML RPC PingBack
Measures the rate of WordPress XML RPC requests (To xmlrpx.php) per IP over a period of 1 minute.
Example: Rate > {xmlrpc-pingback;4}
Supported Operators
== Is equal to
!= Is not
Request Parameters
Accept
Checks for the specified string pattern in the Accept HTTP header value.
Example:Accept == "text/html"
Supported Operators
== Is equal to

!= Is not
ends with Ends with
Accept Charset
Checks for the specified string pattern in the Accept-Charset HTTP header value.
Example:Accept-Charset == "utf-8"
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Accept Encoding
Checks for the specified string pattern in the Accept-Encoding HTTP header value.
Example:Accept-Encoding == "gzip"
Supported Operators
== Is equal to
!= Is not
ends with Ends with

Accept Language
Checks for the specified string pattern in the Accept-Language HTTP header value.
Example:Accept-Language == "en-us"
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Any Header Value
Checks for the specified string pattern in the values of all HTTP headers.
Example:AnyHeaderValue == "debug"
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Any Param Value
Checks for the specified string pattern in the values of all parameters in the query string and post body of the client
request.
Example:AnyParamValue == "debug"

Supported Operators
== Is equal to
!= Is not
ends with Ends with
Body Param Exists
Checks for the specified string pattern in the parameter names in the post data in the client request.
Example:BodyParamExists != "test"
Supported Operators
== Is equal to
!= Is not
See also Query String Param Exists and Param Exists.
Body Param Value
Checks for specified string patterns with a specific parameter value in the post body. In the example, the filter looks
for an exact match of PVAL in the value of the parameter PNAME.
Example:BodyParamValue == {"PNAME";"PVAL"}
Supported Operators
== Is equal to
!= Is not
ends with Ends with

See also Query String Param Value and Param Value.
Connection
Checks for the specified string pattern in the Connection HTTP header value.
Example:Connection == "keep-alive"
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Content Datacenter ID
Checks for the Imperva ID of the destination origin data center for the request.
This ID is relevant to your data centers that are defined to support only forward rules (data centers that you have
defined in Website Origin Server Settings with the Support only forward rules option enabled).
Tip: To retrieve the Imperva ID of the data center, run the /api/prov/v2/sites/{extSiteId}/settings/origin/datacenters
API. For details, see Load Balancing Settings API Definition.
Example: ContentDcId == 43
Supported Operators
== Is equal to
!= Is not
Content Type
The value of the Content-Type HTTP header in the request.
Example:Content-Type contains "json"

Supported Operators
== Is equal to
!= Is not

ends with Ends with
Cookie Exists
Checks for the specified string pattern in the cookie names in the client request.
Example:CookieExists == "SessionID"
Supported Operators
== Is equal to
!= Is not
Cookie Value
Checks for the specified string patterns in the cookie name and value in the client request.
Example:CookieValue == {"cookie_name";"cookie_value"}
Supported Operators
== Is equal to
!= Is not
ends with Ends with

Full-URL
Checks for the specified string pattern in the full path in the client request, including the query string. The protocol
(http/s) and host name are ignored.
Example:Full-URL contains "/uploads/upload.php?id=17"
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Has Cache Tag
Checks for the specified cache tag in the client request.
Note: This filter is applicable when adding a request header in a delivery rule (Rewrite Header rule).
In this example, the filter looks for the cache tag cache-tag-example.
Example:HasCacheTag == "cache-tag-example"
Supported Operators
== Is equal to
!= Is not
Header Exists
Checks whether a certain HTTP header exists.
Example:HeaderExists == "Content-Length"
Note:
• This parameter cannot be used with the Cache Resource rule action.

• This parameter considers the first value only. If additional values are entered, the filter does not work.
For example:
Supported: HeaderExists == "Cookie" & HeaderExists == "Host" & HeaderExists == "Accepts-Language"
Supported: HeaderExists == "Cookie"| HeaderExists == "Host" | HeaderExists == "Accepts-Language"
Not supported: HeaderExists == "Cookie;Host;Accepts-Language"
Supported Operators
== Is equal to
!= Is not
Header Value
Checks for string patterns with a specific field value in the request headers. In the example, the filter looks for an exact
match of HeaderValue in the value of the header HeaderName.
Example:HeaderValue == {"HeaderName";"HeaderValue"}
Note:
• This parameter is not case-sensitive.

• This parameter cannot be used with the Cache Resource rule action.
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Header Value Length
Checks the length of the specified HTTP header.
Example:HeaderValueLength > {"Cookie";1024}

Supported Operators
== Is equal to
!= Is not
HTTP Version
The HTTP version of the request.
Example:Ver == "1.1"
Supported Operators
== Is equal to
!= Is not
IP Version
The IP version of the request.
Example:IpVersion == 4
Supported Operators
== Is equal to
!= Is not
is HTTPS
Checks whether or not the request is HTTPS.
Example:is-HTTPS == No
Supported Operators
== Is equal to
!= Is not

Is Naked Domain
Checks if the domain name is a naked domain.
Example:IsNakedDomain == Yes
Supported Operators
== Is equal to
!= Is not
Max Header Size
The size of the largest HTTP header value.
Example:MaxHeaderSize >= 50
Supported Operators
== Is equal to
!= Is not
Method
The HTTP method in the client request.
Example:Method == POST
Supported Operators
== Is equal to
!= Is not
Num On Session
The index of the current request in the current session.
Example:NumOnSession > 7

Supported Operators
== Is equal to
!= Is not
Origin Destination IP
Checks for the IP address of the destination origin server for the request.
Example: OriginDstIp == 192.158. 1.38
Supported Operators
== Is equal to
!= Is not
Param Exists
Checks for the specified string pattern in the parameter names in the query string and post data in the client request.
Example:ParamExists != "test"
Supported Operators
== Is equal to
!= Is not
To check for the parameter in only the query string or in the post body, see Query String Param Exists and Body Param
Exists.
Param Value
Checks for specified string patterns with a specific parameter value in the request query string or post body. In the
example, the filter looks for an exact match of PVAL in the value of the parameter PNAME.
Example:ParamValue == {"PNAME";"PVAL"}

Supported Operators
== Is equal to
!= Is not
ends with Ends with
To check for the parameter value in only the query string or in the post body, see Query String Param Value and Body
Param Value.
Post Data
Checks for the specified string pattern in the raw post data in the client request.
Example:PostData contains "username=bob&password=alice"
Supported Operators
Post Data Exists
The request contains post data.
Example:PostDataExists == Yes
Supported Operators
== Is equal to
!= Is not
Post Size
The length of POST body in bytes. If the Content-Length header is present, its value is used.

If the data is chunked, the currently accumulated post size that was read is used.
Example:PostSize >= 500
Supported Operators
== Is equal to
!= Is not
Query String
Checks for the specified string pattern in the query string in the client request.
Example:QueryString == "type=gif"
Supported Operators
== Is equal to
!= Is not
Query String Param Exists
Checks for the specified string pattern in the parameter names in the query string in the client request.
Example:QueryStringParamExists != "test"
Supported Operators
== Is equal to
!= Is not
See also Body Param Exists and Param Exists.
Query String Param Value
Checks for specified string patterns with a specific parameter value in the request query string. In the example, the
filter looks for an exact match of PVAL in the value of the parameter PNAME.

Example:QueryStringParamValue == {"PNAME";"PVAL"}
Supported Operators
== Is equal to
!= Is not
ends with Ends with
See also Body Param Value and Param Value.
Referer
Checks for the specified string pattern in the Referer header in the client request.
Example:Referer contains "google.com"
Supported Operators
== Is equal to
!= Does not contain
ends with Ends with
Request Size
The size of request in bytes, not including the body.
Example:RequestSize >= 500
Supported Operators
== Is equal to
!= Is not

Resource Type
The type of the requested resource: HTML or non-HTML.
Example:ResourceType == non-html
Supported Operators
== Is equal to
!= Is not
Scheduler
The times and days for a custom rule to be active. The rule is triggered when requests arrive during the specified times
and match all other conditions of the rule filter.
Format: {minutes;hours;days_in_month;months;days_in_week}
Example:Scheduler == {30-59;12;*;*;1,4}
For details on syntax and additional examples, see Scheduler.
Supported Operators
== Is equal to
!= Is not
SSL Cipher
The cipher suite in the request.
Enter the cipher suite name according to OpenSSL supported ciphers.
For a full list of possible values, download and install OpenSSL and run the following command: openssl ciphers
-v ALL
Example:SslCipher == "ECDHE-RSA-AES128-GCM-SHA256";"can-add-another-type-here"

Supported Operators
== Is equal to
!= Is not
SSL Version
The SSL(TLS) Version.
Example:SslVersion == tls1_2
Supported Operators
== Is equal to
!= Is not
URL
Checks for the specified string pattern in the path in the client request (without the query string).
Example:URL contains "/uploads/upload.php"
Supported Operators
== Is equal to
!= Is not
ends with Ends with
Response Parameters
ABP Action
Checks for the action taken by Advanced Bot Protection (ABP).
Example: abp-action == "captcha_cleared"
Enables you to define an action to take based on the action taken by ABP.
For example, you can create a rule to rewrite responses or to set caching behavior when a specific action is taken by
ABP.

Availability: For use by Advanced Bot Protection customers only.
The ABP Action filter parameter is supported for the following rule actions:
• Rewrite Request Cookie/Header (except for the Host header)
• Remove Request Cookie/Header
• Rewrite Response Header/Response Code/ Error
• Remove Response Header
Note: The ABP Action filter parameter cannot be used in WAF security rules.
Supported Operators
== Is equal to
!= Is not
Response Code
Checks for the response code sent by the origin server.
Example: ResponseCode == 201
Enables you to define an action to take based on the response that Imperva receives from the origin server.
For example:
• Rule: For response code 201, rewrite the response code to 200.
Action: If the response sent by the origin server is 201, this rule rewrites the response to 200 before sending to
the end user.
• Rule: For response code 2xx, rewrite the response header.
Action: If the response is a 2xx code (200-299), this rule rewrites the response header that you specify.
Allowed values: An individual response code in the range of 200-599, or a set of response codes by using "xx", such as
2xx.
Allowed rule actions: You can use this filter parameter in a Rewrite/Remove Response rule or a custom cache rule.

Supported Operators
== Is equal to
!= Is not
Response Content-Type
Checks for the value of the HTTP Content-Type header sent by the origin server in the response.
Allowed rule actions: You can use this filter parameter in a Rewrite/Remove Response rule or a custom cache rule.
Example: ResponseContentType == javascript
Supported Operators
contains Contains

ends with Ends with
Read More
• Create Rules
• Syntax Guide

Scheduler
Use the Scheduler parameter in a rule filter to determine when the rule is active.
For example, you can use it to redirect requests to a backup site during scheduled maintenance to avoid downtime.
The rule is triggered when requests arrive during the specified times and match all other conditions of the rule filter.
Note: All times and dates are according to Coordinated Universal Time (UTC).
Syntax
Format: {minutes;hours;days_in_month;months;days_in_week}
• Asterisk * : Indicates every value of the type.

• Semi-colon: Separates between arguments.
• Comma: Separates between values of the same argument.
For example: {30-59;12;*;*;1,4}
The rule in this example will be active on Mondays and Thursdays, between 12:30 and 12:59.
Supported operators: = or !=
Arguments: Each argument can contain a number, numbers, or range of numbers.
Argument Accepted values

minutes 0-59
hours 0-23
days of the month 1-31
months 1-12
days of the week 1-7, where 1 represents Monday
Examples
When do you want the rule to be active? Syntax
The 31st of every month, between the hours of 14:15
Scheduler == {15-45;14;31;*;*}
and 14:45.
Every Friday the 13th. Scheduler == {*;*;13;*;5}
On the 5th, 7th, and 22nd of November from
Scheduler == {*;9-11,15-16;5,7,22;11;*}
9:00-11:59 and from 15:00-16:59.
Everyday, 20 minutes past every hour and again
Scheduler == {20,45-50;*;*;*;*}
when its 45-50 minutes past every hour.
All the time. (This filter has no meaning. It produces
Scheduler == {*;*;*;*;*}
the same behavior as not using the Scheduler.)
See also:
• Create Rules


Manage Rules
The Rules page displays all of the custom rules defined for a specific site. View, add, and edit rules, or set rule priority.
Where do I find it?
1. On the Cloud Security Console top menu bar, click Application.

3. On the sidebar, click Security > Rules.
In this topic:
• View and add rules

• Set rule priority

View and add rules
Main UI Elements Description
Rule tabs View rules by type.
Filter by Keyword or ID Search for rules by keyword or ID.
Export to CSV Download the rules in .csv format.
Add Rule Create a new rule. For full details, see Create Rules.
The rules in the table are grouped by action type: Redirect, Security, Rewrite, Forward.
Each row in the table represents a single rule and provides the following information and options:
Table Columns Description

The rule’s priority relative to other rules. For details,
Priority
see Set rule priority.
Name The name you give the rule when it is created.
A unique ID, which can be used to identify the rule in
ID
the Imperva logs.
The requests that the rule applies to or the changes
Description
applied to the request.
The number of matched requests for the rule in the
Hits (Last 7 days)
last 7 days.
Indicates if the rule is enabled or disabled, and if the
Status
rule is running in test mode.
Click the edit icon to modify the rule definition. For

more details on rule configuration, see Create Rules.
Edit
When you are done editing, save the rule and add a
comment. A new revision containing the edited rule
is created.
Disable or enable the rule.

Disable or Enable (under More)
Note: A custom rate rule that is used by another rule
cannot be disabled.

Permanently delete the rule.

Delete (under More)
Note: A custom rate rule that is used by another rule
cannot be deleted.
Set rule priority

You can control run order within an action type to define an explicit rule-based policy.
Drag and drop rules to change the order.
• Rules are applied per request.

• The run order for the action types is fixed: Simplified Redirect > Redirect > Rates > Security > Rewrite/Remove
Request > Forward > Rewrite/Remove Response.
• You can prioritize rules within an action type.
• For Redirect, Rewrite, and Forward actions, only the first rule of each type to match is executed.
Note: Priority is not listed for Security rules. All security rules are run for each request, as opposed to other rule types
where the rules are run according to priority order until the first match for that rule type is found.
Redirect The first rule to match is executed.

Rewrite
Forward The first rule to match is executed.

Read More
• Create Rules

View Rule Statistics

You can monitor rule activity and statistics. Statistics are available for up to 90 days.
Delivery Rules
Delivery rule statistics are available in the Websites > Dashboard > Traffic page, in the Delivery Rules table.
Security Rules
View incidents where the rules were triggered in the Websites > Dashboard > Security page, in the Security Rules
table.
See details of security events in the Application > Security Events page. For details, see View Security Events.
Read More
• Rules
• Manage Rules

Delivery Rule Use Case Examples

View examples of some common application delivery use cases, with screenshots illustrating how to implement the
scenarios using Imperva delivery rules.
In this topic:
• Permanently redirect users to a new site or URL

• Configure content switching for specific resources
• Beautify URLs for improved user experience and SEO
Permanently redirect users to a new site or URL
When old websites or pages are retired, all users should be redirected to the new site.


A request to www.oldsite.com/blog will be redirected to www.newsite.com/blog.
Read more on Redirect URL rule configuration in Create Rules.

Configure content switching for specific resources
When certain resources (such as images) are located on a dedicated (image) server, all requests for those resources
should be forwarded to that server.
The first step is to create a dedicated data center for Image server(s). On the sidebar, click Settings > Origin Servers.
Make sure to check the Support only forward rule option.
The second step is to configure a Forward rule. On the sidebar, click Settings > Delivery Rules.


Read more on Forward rule configuration in Create Rules.

Beautify URLs for improved user experience and SEO
To enhance SEO and user experience, display short and clear URLs to end users, while maintaining long and
complicated legacy URLs on your web server.
A request from an end user to access /products/shoes.html will fetch the /online/AAA/items-and-categories/
shoes.html resource from the origin.
Read more on Rewrite URL rule configuration in Create Rules.
Read More
• Create Rules


Security Rule Use Case Examples

View examples of some common use cases, with screenshots illustrating how to implement the scenarios using
Imperva security rules.
In this topic:
• Bot protection
• Account takeover
• Application hardening
• Rate limiting
• Advanced Access Control (ACL)
Bot protection
• Block malicious clients
• Anti-scraper engine - CAPTCHA for bots
• Facebot crawler
Block malicious clients
Similar to the default Block Bad Bots security setting but more aggressive.
ClientType == VulnerabilityScanner;DDoSBot;ClickBot;CommentSpamBot;HackingTool;SpamBot;Worm

Anti-scraper engine - CAPTCHA for bots
Require a CAPTCHA challenge to protect against site scraping bots.
NumOnSession > 40 & Rate > {get-page-ip;20} & ClientType != Browser;SearchBot;SiteHelper
Facebot crawler
Trigger an alert when a crawler is trying to logon to the site.
In this example, the rule is triggered when the client is Facebook (Crawler), and logon parameters are identified in the
request.

Account takeover
ClientId == 164 & (ParamExists == "Password";"userId";"CardNumber")
• Block suspected brute force attacks

• Credential stuffing attack
• CAPTCHA for a specific region
Block suspected brute force attacks
This rule is triggered when there are 5 or more POST requests to any URL for a single IP over a one minute time frame
and a request is sent for the /login page.

URL == "/login" & Rate >= {post-ip;5}
Credential stuffing attack
Some recent attacks involve bot clients attempting credential stuffing at a very slow rate. An alternative to blocking
such an attack is to challenge any non-human visitor to the /login page to avoid degrading the user experience of
legitimate users.
For more details on credential stuffing attacks and additional examples, see Blocking Credential Stuffing Attacks .

ClientType != Browser;SearchBot & URL == "/login.php"
CAPTCHA for a specific region
Require a CAPTCHA challenge for login requests originating from a specific geographical location, except for search
engines.

Tip: Add the NumOnSession parameter to prevent a misclassification in the first few requests. In this example,
NumOnSession >=3 means that the rule is triggered only after the third HTTP request, to ensure that the Imperva bot
classification process is completed and removing the risk of false positives.
Application hardening
CountryCode != GB & URL contains "LogonForm" & ClientType != Browser;SearchBot;FeedFetcher;
• Restrict HTTP methods
• Prevent a known CSRF in your site
• Malformed ID
Restrict HTTP methods
Block specific HTTP methods. You can also apply the rule to specific IPs or URLs.

Method != PUT;HEAD;OPTIONS;TRACE;POST
Prevent a known CSRF in your site
Prevent unauthorized connections that are not coming from the site itself, such as email links. This rule would in
effect prevent Cross-Site Request Forgery attempts.
URL contains “/transfer_money” and Referer not-contains “^https://www.mybankingsite.com”
Malformed ID
Block illegal connections to malformed IDs. The rule below gives an example of a URL where the query starts with %
or a space (url decoder). This type of rule can introduce another layer of security for GET methods, but are specific to
each website.

Rate limiting"CategoryDisplay"
URL contains & Full-URL contains "categoryId=%"
• Request rate limiting

• Dynamic rate limiting
• Alert on high rate of malicious requests
Request rate limiting
Limit requests per session, per minute.
In this example, the rule is triggered when the rate of requests per session is 500 or more per minute for a single client
session (between client and Imperva), and the client is not Googlebot (SearchBot). You can also replace the Client ID
with Client Type (SearchBot).

Rate >= {request-rate-session;500} & ClientId != 6
Dynamic rate limiting
In this example, the rule is triggered when the rate of requests per IP is 20 or more per minute, and the client is not
Googlebot (SearchBot).
It can be used to generate an alert for tracking purposes. Alternatively, you can add a header to the specified clients
using a Delivery Rules rewrite header.

Rate >= {dynamic-content-rate-ip;20} & ClientId != 6
Alert on high rate of malicious requests
By default, Imperva blocks specific requests, and not the entire user session or IP. The AttacksCount parameter
enables you to add another level of security by deciding to block or create an alert for a single session generating
more than <x> malicious requests.

AttacksCountAccess
Advanced >= 250Control (ACL)
• Alert on requests from a specific location

• Alert on admin panel request from outside of your office's IP
Alert on requests from a specific location
Using the security settings options in the Cloud Security Console (Websites > Settings > Security) you can block
requests from a specific country. This example shows a rule that is configured to alert, and provides a higher level of
granularity by filtering for specific client types.

CountryCode == GB & ClientType != Browser;SearchBot
Alert on admin panel request from outside of your office's IP
Set an alert action if someone from outside your office requests your admin panel.

URL contains "/admin" & ClientIP != 10.10.10.10
Read More
• Create Rules

Cloud WAF Log Integration

Retrieve your Imperva access and event logs from the Imperva cloud repository and archive or push these events into
your SIEM solution.
Note:
• The availability of this feature depends on your subscription. For more information or to upgrade your plan,
contact an Imperva Sales Representative.
• Logs will include events that occur after the log integration is activated.
• Near Real-Time SIEM log integration:
• Imperva recently introduced the new Near Real-Time SIEM solution. To learn more, see Near Real-Time
SIEM Log Integration.
• For Cloud WAF customers who would like to use the Near Real-Time SIEM log integration, you must first
setup the integration with the S3 push method according to the instructions below: Set up log
integration.
• The log integration is initially configured on the legacy mechanism described here and is then migrated
to the new Near Real-Time SIEM mechanism within one week.
In this topic:
• Overview
• The log integration process
• Set up log integration
• Enable log encryption
• Download the logs
• Switch integration modes
Overview
Imperva creates the following comprehensive and detailed logs:
• Security logs provide a detailed alert for each suspicious event detected by the Imperva proxy while protecting
your network throughout its globally distributed network. All logs include the account ID and site ID references,
which enables drill down into each individual customer/site.
• Access logs specify every request and response sent between your customers and the Imperva proxy. This is all
the traffic that would have been sent between end users and your origin server, including traffic that Imperva
served from its cache.
Imperva supports CEF, LEEF, and W3C log formats and provides event reporting of in-depth event information, such as
attacker geo-location and client application signature.
Logs are typically synchronized within 10 minutes, although it may take up to 30 minutes depending on system load.
Log integration modes
Imperva provides several modes of log integration:
• Retrieve (Pull mode): Log integration API. Your logs are saved in a dedicated Imperva cloud in a repository
created for you. Imperva enables you to upload a public key to encrypt your log files, activate Imperva log

collection, change the logging level, and download log files from the Imperva storage repository to your
network.
Log storage: Logs are aggregated at the Imperva log repository and are kept up to 48 hours or until the stored
logs reach 500MB. (Logs may be retained for up to 5 additional days for internal troubleshooting purposes
before they are permanently deleted.) When one of these limits is reached, the system uses a cyclic override
process in which the first written file is the first to be deleted in order to leave space for a new log file. Logs are
stored per account.
Log index file: Imperva provides a Log Index file that specifies the log files generated for you. This Index file lists
which log files are available to download. The index file is not modified based on which log files have already
been downloaded. It always contains the full list of available log files at any given moment.
• Receive (Push mode): Automatic log integration via SFTP or Amazon S3. Your logs are pushed upon creation
to your pre-defined repository - an AWS S3 bucket or an SFTP folder. Logs are automatically transferred from the
Imperva cloud repository to your repository. No log data is stored in Imperva at any time.
Encryption
You can choose to implement log encryption for Imperva logs. Logs are encrypted by a private-public key pair that
you generate, to help safeguard the privacy of your data when stored in the Imperva cloud repository. The encryption
is done automatically at the Imperva cloud repository. You need to decrypt the log files after download.
If you are using the receive (push) option for log integration, the best practice recommendation discourages using
encryption. As the logs are not written to the Imperva cloud repository, the risk of log exposure is minimal.
Predefined SIEM packages
Predefined SIEM application packages which automate the loading of events from the Imperva cloud into your SIEM
are available. These predefined packages come ready-made to manipulate and display each Imperva log event in your
SIEM dashboard in order to facilitate reporting automation, prioritized mitigation, and general event handling.
Note: These packages are developed and maintained independently of Imperva, and are therefore not supported by
Imperva.
The functionality differs per package. Any requests for additional functions or bug fixes should be submitted through
GitHub.
Packages are available for:
• Micro Focus ArcSight (Express/ESM)

• Splunk
• GrayLog
• Sumo Logic
• LogRhythm
Several additional platforms provide SIEM integrations with Imperva:
• IBM QRadar

• AlienVault USM Anywhere
Connector
If you choose the retrieve mode to access the logs, a sample Python script and configuration file are available for
download to assist you with the process. Imperva does not maintain this script. It is hosted in GitHub and managed by
the open source community.
The log integration process
This section provides an overview of the log integration process. To configure Imperva log integration, do the
following:
Task Instructions
Activate logging and configure the log integration

Set up log integration
settings in the Imperva Cloud Security Console.
(Optional) Enable log encryption. Enable log encryption
(Optional) Install and configure the relevant

Installing a SIEM Package
SIEM package.
When using the retrieve/pull mode for log

integration, retrieve the logs using the Imperva Download the logs
Cloud Application Security APIs.
Set up log integration
Enable and configure log integration in the Imperva Cloud Security Console.
Prerequisites: If you are implementing log integration using the push mode (automatic log integration via SFTP or
Amazon S3), make sure that Imperva IP addresses can access your site. For details, see Imperva IP addresses .
For accounts with sub accounts: Logs for sub accounts can be activated from both the parent account and the sub
accounts, as follows:

In the parent account: Activate logs for sub

accounts. Logs are collected for all sites in the
Accounts Log Levels page selected sub accounts and retrieved according to the
method configured in the Logs Setup page in the
parent account.
In a sub account: Activate logs for any sites in the

Sites Log Levels page
sub account. Logs are collected for all sites in the
sub account and retrieved according to the method


configured in the Logs Setup page in the sub
account.
To configure log integration:
1. Log into your my.imperva.com account and navigate to the Logs Setup page:
On the top menu bar, click Account > Account Management. On the sidebar, click SIEM Logs > WAF Log Setup.

2. Select a connection mode:
Mode Instructions
1. Select Imperva API.
2. Click the links to download the

API Connector and the Settings.Config Log
configuration file. The Connector is a
sample script you can use to download the
logs after they are generated.
3. Under Connection, copy the API Key

before exiting the window. You will need it
later. If you forget to copy the key, you can
Pull mode: Download logs using a script come back to this window later and click
Generate API Key to create a new

key.
4. The Log Server URL field specifies the URL

of your Imperva log repository in the
Imperva cloud. Use this location to
download the generated logs.
For more details, see Download the logs.
1. Select SFTP or Amazon S3.
2. Fill in your credentials:
SFTP: Host (machine IP), User name, and

Password.
Amazon S3: Your S3 Access key, Secret

key, and Path, where path is the location of
Push mode: Receive logs the folder where you want to store the logs.
Enter the path in the following format:
<Amazon S3 bucket name>/<log folder>.
For example: MyBucket/
MyIncapsulaLogFolder.
3. Click Test connection to perform a full

testing cycle in which a test file will be
transferred to your designated folder. The
test file does not contain real data, and will

Mode Instructions
be removed by Imperva when the transfer is
complete.
3. Configure the additional options:
Option Instructions
Select the format for the log files: CEF (default),

Format
W3C, or LEEF.
By default, log files are compressed. Clear this

option to keep the logs uncompressed.
Compress logs Note: If you are using the pull mode to download
your logs using the API Connector (Python script),
compressed files must be used. Uncompressed
files will result in an error (-3).
(Optional) Click Upload Key to upload a public

key (2048-bits long) to Imperva. Your log files will
Encryption be encrypted using this key.
For full details, see Enable log encryption.
1. Click a SIEM package to download.

SIEM Packages
2. Install the downloaded package. For
details, see Installing a SIEM Package.
4. Click Save to save all changes.
5. On the sidebar, click Log Levels. The following window displays:

6. Select a log level for each site to enable logging, or leave disabled. There are two levels of logs:
▪ Security Logs include the Imperva security events log.
▪ All Logs comprises a comprehensive log of every request and response (access logs), as well as the
security events log.
7. Verify that the relevant Imperva SIEM package (Splunk, HP ArcSight, McAfee, GrayLog or QRadar) is receiving
events.
Enable log encryption
Imperva uses two layers for encrypting the log events:
• Imperva encrypts events using a symmetric key (AES 128).

• The symmetric key itself is encrypted asymmetrically using a public key (2048) provided during the public key
configuration step.
To define Imperva log encryption:
1. Generate a private key by using the command line:
openssl genrsa -out Private.pem 2048
1. The private key is created with a .pem extension. Change it to the .key extension.
2. On the machine on which your SIEM application is installed, save the private key with the .key extension
under the config/keys/1 library.
2. Generate a public key by using the command line:
openssl rsa -in Private.pem -outform PEM -pubout -out Public.pem
3. Upload the public key to Imperva using one of the following options:

▪ Cloud Security Console: In Log Setup, use the Upload Key button. For details, see Set up log integration.
▪ API: Use the Upload Public Key API, as described in Traffic Statistics and Details API.
Note:
▪ Each time you upload a public key, it is numbered, starting from the single-digit 1. The next time you
upload a public key, it will be number two and so on. This number later appears in the Imperva log file
header, which indicates which key to use to decrypt the file. Always keep a copy of your old key versions,
in case you want to decrypt historical log files.
▪ Each time you upload a public key, store the new private key in the new library at the origin server, as
follows:
• config/keys/1
• config/keys/2
• config/keys/3
• etc.
4. Activate the log encryption feature using one of the following options:
▪ Cloud Security Console: In Log Setup, under Encryption, upload a public key (2048-bits long). For
details, see Set up log integration.
▪ API: Use the Change Log Collector Configuration Status API, as described in Traffic Statistics and
Details API.
To decrypt the logs, you will need to:
• Use the private key to decrypt the symmetric key.

• Use the symmetric key to decrypt the events in the log file sent by Imperva.
Download the logs
If you choose to manage your logs using the Imperva log integration API, you need to download the logs after they are
generated. A sample Python script for implementing the API, referred to as the Connector, as well as installation and
configuration instructions, are available in GitHub. The script is managed by the open source community.
Downloading Imperva Logs - Process overview
This section provides an overview of the process you need to follow to download Imperva logs.
1. Download the Imperva logs.index file:
1. In the Imperva Cloud Security Console, in the Logs > Log Setup page, under Connection, locate the Log
Server URL.
2. To access the index file, append logs.index to the end of the Log Server URL, in the format
<Log_Server_URL>/<Specific_Log_File>.
For example:
https://logs1.incapsula.com/1234_5678/logs.index

The index file lists the log entries that are currently available in the Imperva log repository.
Authentication for access to the logs is performed using the API ID and API Key.
2. Send an HTTPS call for each file listed in the index file that you want to download. As new log files are
generated, they are numbered sequentially, but may occasionally skip integers.
3. If using encryption, decrypt the files to read the contents, as follows:
1. Decrypt the key value with the appropriate private key, according to the publicKeyId value. For details,
see Log File Structure.
2. Use the decrypted symmetric key to decrypt the log content.
4. Decompress the files.
This example shows how to decompress a log file using Linux bash commands:
csplit -sz 123_345.log -f 123_345.log. /\|\=\=\|/

sed -i '/|==|/d' 123_345.log.01
cat 123_345.log.00 > 123_345.log.decompressed
zlib-flate -uncompress < 123_345.log.01 >> 123_345.log.decompressed
rm 123_345.log.0*
Switch integration modes
You can switch between the retrieve (pull) and receive (push) modes of log integration. If you switch from the
Incapsula API pull mode to SFTP or Amazon S3 push mode, Imperva continues upload attempts for 90 minutes, after
which log files will be lost without the option of retrieval. After 30 minutes, a warning email is sent to your account,
according to the e-mail settings defined in Account Settings. If Imperva fails to push the logs to SFTP or Amazon S3
within 90 minutes, another email notification is sent to indicate that action is required.
Read More
• Log Configuration File

• Installing a SIEM Package
• Log File Structure
• Example Logs

Log Configuration File

The Settings.Config log configuration file can be used as part of Imperva log integration. You can download it in the
Imperva Cloud Security Console, from the Log Setup page. For more details, see Cloud WAF Log Integration.
The configuration file can be opened using any standard text editor, and includes the following parameters:
Configuration File Parameters
[SETTINGS]
APIID=41986
APIKEY=25a21c10-ebf4-4c4c-8c1e-d588c4050d5d
PROCESS_DIR = /tmp/processed/
BASEURL=https://255.255.255.255/1234_5678/
USEPROXY=NO
PROXYSERVER=
SAVE_LOCALLY=YES
SYSLOG_ENABLE=NO
SYSLOG_ADDRESS=
SYSLOG_PORT=
USE_CUSTOM_CA_FILE=NO
CUSTOM_CA_FILE=
You can edit this file, as needed:
APIID Your API ID.

APIKEY Your API key.
Specifies the directory into which Imperva
PROCESS_DIR automatically saves the logs after unzipping and
decrypting them.
Specifies the URL of your logs repository in the
Imperva cloud. This URL is displayed in the Imperva
BASEURL
Cloud Security Console Log Setup page > Log
Server URL field.
USEPROXY Specify YES to use a proxy to download the files.
If you choose to use a proxy, supply the proxy URL in
PROXYSERVER
the following format: https://10.10.10.10:8080.

A Yes/No value that instructs Imperva whether to

SAVE_LOCALLY maintain the log files after they are processed. When
set to No, the files are deleted.
A Yes/No value that instructs Imperva about whether
SYSLOG_ENABLE
to send the files via Syslog.
If Syslog is enabled, provide the address to which to
SYSLOG_ADDRESS
send the logs.
SYSLOG_PORT If Syslog is enabled, provide the Syslog port.
Default "no" in case the service's certificate is not in
USE_CUSTOM_CA_FILE
the default bundle.
CUSTOM_CA_FILE Path for the custom certificate file.
Read More
• Cloud WAF Log Integration

Installing a SIEM Package

Install a predefined SIEM package and configure your SIEM to consume Imperva logs. For full details on log
integration, see Cloud WAF Log Integration.
In this topic:
• Download the SIEM Package

• Install the ArcSight Package
• Install the Splunk Package
• Install the McAfee Package
• Install the Graylog Packager
• Install the Imperva App for Sumo Logic
• Consuming Logs
• Log File Rotation and Maintenance
Download the SIEM Package
To work with Imperva Log Integration, download and install a SIEM package on the machine on which your
SIEM application is installed.
You can download a predefined package for one of the following SIEM applications. These packages include
predefined rules, custom dashboards, and reports for viewing the incoming data. For download instructions, see
Cloud WAF Log Integration.
• Micro Focus ArcSight (Express/ESM)

• Splunk
• Graylog
• Sumo Logic: Imperva App for Sumo Logic. Instructions for set up are available in the Sumo Logic
documentation: Imperva-Incapsula Web Application Firewall .
• LogRhythm
Several additional platforms provide SIEM integrations with Imperva:
• IBM QRadar: IBM provides a Security Qradar DSM for Imperva. The RPMs and configuration instructions are
available in the IBM documentation: IBM Security QRadar DSM for Imperva Incapsula .
• AlienVault USM Anywhere: You can configure Imperva to send log data to USM Anywhere. For configuration
instructions, search for Incapsula in the AlienVault USM Anywhere documentation .
Install the ArcSight Package
Note: Imperva supports ArcSight ESM version 5 or higher and ArcSight Express version 3 or higher.
1. Log in to your ArcSight console.

2. Select the Packages tab on the navigator.
3. Select Import

4. Browse to the Incapsula.arb file and click Open. This is the file you downloaded from Imperva.
5. After the package is imported, click Install.
6. When the installation completes, click OK. The ArcSight package is now installed and its content is visible as
various resources under the Navigator area: filters, rules, active channels and so on.
Install the Splunk Package
Note: Imperva supports Splunk version 6 or higher.
You can install the Splunk application package using one of the following methods:
• Using the Splunk UI

• Using the CLI
Install the Splunk Package Using the Splunk UI
1. Save the Incapsula.spl file in a folder accessible by Splunk. Incapsula.spl is located in the package that you
downloaded via the Imperva Cloud Security Console.
2. Login to Splunk. The following displays:
3. Click Apps at the top of the left pane, as shown below:

The following window displays:
4. Select the Install app from file option, as shown below:

5. Click the Choose File button and browse to select the Incapsula.spl file.
6. Click the Upload button. The following window displays:
7. Click the Restart Splunk button.
The Splunk application now contains the Incapsula Splunk connector. Login to it. For example, as shown below:
Install the Splunk Package Using the CLI
1. Log in to Splunk Management using Root credentials.

2. Copy the application to the Splunk machine.
3. Run the following command:
tar -xvf SplunkPack.spl /$SPLUNK_HOME/etc/apps/

Install the McAfee Package
Note: Imperva supports McAfee Enterprise Security Manager versions 9.4.x, 9.5.x, and 9.6.x.
The McAfee package contains the following three files:
• Parser
• Dashboards

• Rules
Each of these files should be installed separately in McAfee.
To install the predefined McAfee package, save the package that you downloaded locally in a folder that is accessible
to McAfee. Then, follow the instructions below.
Create a New McAfee Receiver
1. In McAfee Enterprise Security Manager, open the Add Data Source window to add a new data source.

2. Fill in the following fields:

▪ Data Source Vendor: Set the value to ArcSight.
▪ Data Source Model: Set the value to Common Event Format (ASP).
▪ Name: Assign any name. For example, Imperva.
▪ IP Address: Enter the IP address of the server on which the Incapsula API script is running. That server
should be located at the customer perimeter.
▪ Port: This is number defined by the API Server. SysLog data stream can flow through that port.
3. Click the OK button.
4. Open the Rollout window to roll out the Incapsula policy.
5. Click the OK button.
Install the Parser and Creating the Custom Fields
You must create the custom fields for first-time installation.
To create custom fields:
1. In McAfee Enterprise Security Manager, click the button.

The System Properties window displays:
2. In the left pane, select Custom Types and then add the following types:
▪ Incap_Captcha_Support:
• Data Type: Random String
• Event Field: Custom Field 1
▪ Incap_UID:
▪ Incap_JS_Support:
To install the McAfee Parser:
1. In McAfee Enterprise Security Manager, click the button to open the Receiver Policy Editor and then click the
receiver you created.

2. Disable the ArcSight CEF Parser, as shown below:
3. Select File > Import > Policy to import the Parser that you downloaded from Imperva.
4. Verify that the Parser you imported is enabled, as shown below:

Install the Graylog Packager

Imperva provides a predefined Graylog package. The packager is a JSON file with a predefined dashboard included.
The package includes the following:
• Syslog listener - UDP listener on port 514

• Extractor - Format data from the received text messages to Graylog message fields
• Dashboard - Visual view of Imperva logs data
To consume logs using Graylog :
1. Download the Graylog package from the Cloud Security Console Log Setup page. For details, see Cloud WAF Log
Integration.
2. In Graylog , go to System/Inputs (top left menu), and choose Content Packs.
Note: Graylog administrator access required.

3. Choose Import content pack > Choose file, and navigate to the content pack file that you downloaded to your
computer.
4. Click Upload.
5. In the content packs page, click the Incapsula content pack you have just added, and then click on Apply
content.

6. The Graylog server now contains the Incapsula Graylog Extractor and Dashboard, and it is ready for use.
Install the Imperva App for Sumo Logic
You can install the Imperva App for Sumo logic to use the preconfigured searches and dashboards.
Process overview:
1. Configure logging for your account in the Imperva Cloud Security Console.
2. Configure Sumo Logic:
1. Add a Sumo Logic Hosted Collector.
2. Configure an AWS S3 Source.
3. Install the Imperva App for Sumo Logic.
Instructions for set up are located in the Sumo Logic documentation: Imperva-Incapsula Web Application Firewall .
Consuming Logs
This section describes how to consume logs using one of the following packages: ArcSight, Splunk, McAfee.
The section includes:
• Consuming logs by ArchSight

• Consuming logs by Splunk
• Consuming logs by McAfee
Consuming the Imperva Logs in ArcSight
Note: The instructions presented in this section should only be used as a guideline, as there may be minor differences
should the ArcSight application change or when using a different operating system.
Consume Logs via Syslog

Logs can be pushed through Syslog using a script, such as the sample Python script for Imperva log integration. For
details, see the Connector section in Cloud WAF Log Integration.
In order to consume the logs via Syslog, the IP of a Syslog server and its port must be defined. This is done in the
configuration file downloaded together with the Python script.
The required fields are:
• SYSLOG_ENABLE
• SYSLOG_ADDRESS
• SYSLOG_PORT
Consume logs from files
To consume logs from files using an ArcSight file-based reader:
1. Start the ArcSight SmartConnector.
2. Click Next. The following window displays:

3. Select the folder in which to install the reader and click Next. For example, c:\arcsight\incapsula. The following
window displays:

4. Select the Typical radio button and click Next. The following window displays:

5. Select the Don’t create icons radio button and click Next.
6. Click Install. The installation process begins.


7. In the following window, select the Add a connector radio button and click Next.


8. In the Type field, select ArcSight FlexConnector Multiple Folder File and click Next. The following window
displays:

9. Insert the following values and click Next:
▪ Folder: Enter the Processed folder, as defined in your configuration file.

▪ Processing Mode: realtime
▪ Configuration File: cef_file
▪ Configuration Type: cef

10. Register the connector to the manager by selecting the ArcSight Manager (encrypted) radio button and click
Next.

11. Enter the required information and then click Next.

12. Enter any name for the connector. For example, Incapsula Folder Follower and click Next. The following
window displays:

13. Select the Import the certificate to connector from destination radio button and click Next. The following
window displays:
14. In the following window select the Install as a service radio button and click Next.

15. The following window displays:

16. Enter the following values and click Next.
▪ Service Internal Name: sdkmultifolderreader_incap

▪ Service Display Name: ArcSight FlexConnector Multiple Folder File – Incapsula


18. Select the Exit radio button and then click Next.
19. Start the Service:
▪ For Linux: Run the command - /etc/init.d/arcsight_servicename start.
Consuming the Imperva Logs in Splunk
Consume Logs via Syslog
Logs can be pushed through Syslog using a script, such as the sample Python script for Imperva log integration. For
details, see the Connector section in Cloud WAF Log Integration.
In order to consume the logs via Syslog, the IP and Port of the Syslog server must be defined.
Set Splunk to listen on the port defined in the Python script configuration file. By default, this port should be 443.
1. Login to Splunk using Root credentials.

2. Go to the Settings menu and click the Add Data button.
3. Select monitor.
4. Click the TCP/UDP option in the left pane.
5. Select UDP and provide the port.
6. Click Next and continue by selecting the Sourcetype, as described in step 7 below.

Consume Logs Via the Splunk Forwarder
1. Download the latest version of the Splunk Forwarder.
2. Double-click the downloaded Splunk Forwarder file. The following window displays:


5. If you have your own CA, change the fields in the window according to your Splunk certificate and click Next.

6. Select the Local System radio button and click Next. The following window displays:

7. In the Path to monitor field, specify the path where Imperva downloads the log files.



11. In the Hostname or IP field, specify the address of your deployment server and click Next. The following
window displays:

12. In the Hostname or IP field, specify the address of your Receiving Indexer and click Next. The following window
displays:

13. Click the Install button. The following window displays:

14. Wait until the following window displays:

15. Click the Finish button.
Consume Logs from Files When the Connector Is Installed on the Splunk Management Machine
Follow the instructions below to consume the security log files using a Splunk Forwarder that points to the folder in
which the processed log files reside.
1. Login to Splunk using administrative credentials.

2. Go to the Settings menu and click the Add Data button.
3. Select Monitor.
4. Select the Files & Directories option in the left pane.
5. Click Browse and select the directory where the script processes its downloaded log files.
6. Click Next.
7. Click the Select button for the Sourcetype and select Uncategorized > Incapsula.
8. Select an existing index or create a new index by following the instructions below:
1. In the index, click the Create a new index link. This opens a new browser tab.
2. Provide an index name. For example, Imperva.
3. Click Save.
4. Return to the Add Data browser tab and click the refresh link (located below the Create a new index link).
5. Select the index created earlier.
9. Click Review.
10. Review the settings and click Submit.

Consuming the Imperva Logs in McAfee – Importing the Dashboard and Rules
To import the Dashboard:
1. In McAfee Enterprise Security Manager, click the Manage Views button and then click the Import
button, as shown below:
2. Select the Dashboard file that you downloaded from Imperva.
To import the Rules:
1. In McAfee Enterprise Security Manager, click the Policy Editor button to open the Policy Editor.
2. Select File > Import > Rules and then select the file you downloaded from Imperva, as shown below:

The McAfee application displays the Incapsula Package and its content.
Log File Rotation and Maintenance
By default, the Incapsula SIEM connector does not maintain or purge any files exported by the API. All files exported
from the API should be maintained and purged by the applicable platform (Splunk, ArcSight, Graylog or Intel McAfee
ESM).
Read More

Log File Structure

This topic explains the Imperva log file structure and provides compatibility information.
In this topic:
• Overview
• Log file name
• Log file structure
• Log fields
Overview
Imperva log files aggregate the access events and security alerts detected by Imperva while protecting your network.
A new aggregated log file is saved in the Imperva Cloud Log Repository.
Log file content compatibility
Consider the following when integrating with other tools:
• We reserve the right to add fields at any time.

• We will not change a field's name, meaning, or content. If a change is required, we will add an additional field
with a similar name for the new content, while continuing to maintain the old field for a reasonable period of
time to enable you to update your implementations accordingly.
• We highly recommend accessing specific fields in the message according to the field name, as opposed to
accessing the field by its sequence number or position within the log message, as those may change over time.
Any changes made are communicated in the Cloud Application Security Release Notes.
Log file name
The format of each log file name is X_Y, where:
X: Specifies the API ID.
Y: Specifies a log sequence number starting from 1.

Log file structure
The log file is comprised of two parts – a header and log events:
Log File Header
The Log File Header contains metadata, as follows:
The start time of the current log file, in UNIX epoch

startTime
time format.
The end time of the current log file, in UNIX epoch
endTime
time format.
accountID Your Account ID.

The format of the events in the log file: CEF , LEEF or

Format
W3C (Example Logs).
An MD5 checksum that verifies that the entire file
Checksum
content has not been tampered with.
publicKeyId Public Key ID.
key The log content decryption key.
The configuration ID. Each account has a
configID
configuration ID.
For W3C format, it is required to present the list of
W3C fields
fields.
A string of equal signs |==| appears at the bottom of the log file header, which separates it from the log events
described below.
Log Events
Each log file contains multiple log events detected by Imperva while protecting your network throughout the world.
Each event is a paragraph.
The log content is compressed and encrypted with a symmetric key, using an AES algorithm and then encrypted with
the public key that you provide using an RSA algorithm.
Log fields
The following table describes the fields that are provided in each log entry for each access and security event. Each
entry in the log file provides information about a single request. Security events contain all the fields provided for
access events and more. The table indicates the name of the field in the CEF, LEEF, and W3C format.
Detailed
Description
The numeric
identifier of the
Account ID suid suid s-suid
account of the site
owner.
The account name
Account Name Customer Customer s-accountname
of the site owner.
Account level
reference ID.
Corresponds to the
Reference ID option
Account Reference
tag tag s-tag in the Cloud
ID
Security Console
Account Settings.
For details, see
Account Settings.
The city code of the
City cicode cicode cs-cicode
site visitor.

Detailed
Description
The client IP that
Client IP src src c-ip
made the request.
Content Length in in cs-bytes The content length.
The country code of
Country Code ccode calCountryOrRegion cs-countrycode
the site visitor.
The HTTP response
HTTP Status Code cn1 cn1 sc-status code returned to the
client.
The unique
ID fileId fileId cs-sessionid
identification.
The request
Method requestMethod requestMethod cs-method
method.
The Imperva PoP
PoP name deviceFacility popName sr-pop that handled the
request.
Protocol app proto cs-version The request protocol
The TLS version and
encryption
Protocol version ver protoVer cs-protver
algorithms used in
the request.
The URL of the
Referrer ref ref cs(Referrer) previous page that
the client visited
Request headers in
JSON format, with
cs-
Request Headers additionalReqHeaders
additionalReqHeaders each field
represented as a
name-value pair.
A unique identifier
of the request that
can be used to
correlate with
Request ID deviceExternalId deviceExternalId s-externalid
reports and data
from the Imperva
Cloud Security
Console
The method in
which Imperva
processed the
Request Result act cat sc-action request:
• REQ_PASSED:
If the request
was routed to

Detailed
Description
the site's web
server
•
REQ_CACHED_X:
If a response
was returned
from the data
center's cache
• REQ_BAD_X: If
a protocol or
network error
occurred
•
REQ_CHALLENGED_X:
If a challenge
was returned
to the client
•
REQ_BLOCKED_X:
If the request
was blocked
For more details, see

Cloud WAF Error
Pages and Codes.
The time in which

this visit started, in
Request Start Time start start cs-start
UTC. In UNIX epoch
time format.
The end time of the
response to the
Response End Time end end cs-end request, in UTC. In
UNIX epoch time
format.
Response headers in
JSON format, with
each field
cs- represented as a
Response Headers additionalResHeadersadditionalResHeaders
additionalResHeadersname-value pair.
Note: Use of these
fields for CEF and
LEEF formats

Detailed
Description
require enablement
by Imperva Support.
The numeric
Site ID siteid siteid s-siteid
identifier of the site.
The name of the
Site Name sourceServiceName sourceServiceName s-computername
site.
Site level reference
ID. Corresponds to
the Reference ID
option in the Cloud
Site Reference ID siteTag siteTag s-sitetag Security Console
Website Settings.
For details, see
Website General
Settings.
The client port used
Source Port cpt srcPort c-port to communicate the
request.
The URL of the
URL request url cs-uri
request.
The UserAgent
User Agent requestClientApplication
requestClientApplication
cs(User-Agent)
header value.
The X-Forwarded-
For request header.
This log field is

populated only if the
request received
X-Forwarded-For xff xff s-xff
from the client
contained the XFF
header, and/or the
request received
from the client was
passed to the origin.
For each request that has attack information the following is provided:
Detailed
Description
Additional
Additional Rule Info cs11 cs11 cs-ruleInfo
information on the
violation that

Detailed
Description
JSON format.
Used for API

Specification
Violation events.
JSON structure:
{“api_specification_violation_type”:”<typ
name>”}
The possible values

for
api_specification_violation_type
are:
• INVALID_URL
•
INVALID_METHOD
•
MISSING_PARAM
•
INVALID_PARAM_VALUE
•
INVALID_PARAM_NAME
The
“parameter_name”
is present only if the
violation occurs in
the context of a
parameter. Its value
is the relevant
parameter name.
Attack ID filePermission filePermission cs-attackid Imperva attack id.
The rule type that

was triggered, and
This information is the corresponding
presented in the Imperva internal
Attack Severity N/A cs-severity
header, not as a rule ID number.
separate field.
• ACL: -1
• SQL Injection:
0

Detailed
Description
• Cross Site
Scripting: 1
• Illegal
Resource
Access: 3
• Bot Access
Control: 4
• DDoS: 8
• Backdoor
Protect: 9
• Remote File
Inclusion: 10
• Manual rule
(IncapRule):
11
• API
Specification
Violation: 12
• Account
Takeover
Protection: 13
• Bad Bot
(Advanced Bot
Protection): 14
Attack Type fileType fileType cs-attacktype The type of attack.

Browser Type dproc dproc cs-browsertype The browser type.
Whether or not the
Captcha Support cs1 cs1 s-capsupport client application
supports Captcha.
The client
Client App cs6 cs6 cs-clapp application
software.
Whether or not the
Cookies Support cs3 cs3 cs-co-support client application
supports cookies.
Debug cs5 cs5 cs-clappsig For internal use.
Whether or not the
JS Support cs2 cs2 cs-js-support client application
supports JavaScript.
The latitude of the
Latitude cs7 cs7 cs-lat
event.
The longitude of the
Longitude cs8 cs8 cs-long
event.

Detailed
Description
The post body data
Post Body postbody postbody cs-postbody
of the request.
The query string of
Query String qstr qstr cs-uri-query
the request.
The threat rule
name that this
request triggered.
Rule Name cs9 cs9 s-ruleName
For example, SQL
Injection or Blocked
IP (ACL).
The IP address of
Server IP sip dst s-ip
the server.
The port of the
Server Port spt dstPort s-port
server.
Visitor ID cs4 cs4 cs-vid The ID of the visitor.
For each request that has delivery rules information the following is provided:
Detailed
Description
JSON describing all
actions that were
applied to a specific
Delivery Rule Details cs10 cs10 cs-rule
request (detailed
JSON structure
below)
JSON structure for delivery actions:
{ "rule_id": "<rule id>", "type": "AD_REDIRECT",

Redirect "int_value": "<redirect code>", "name": "", "orig":
"<original url>", "rewrite": "<redirect url>"}
{ "rule_id": "<rule id>", "type": "AD_URL_RW",
URL Rewrite "int_value": 0, "name": "", "orig": <original url>,
"rewrite": <new url> }
{ "rule_id": "<rule id>", "type": "AD_HEADER_RW",
Header Rewrite "int_value": 0, "name": <header name>", "orig":
<original value>", "rewrite": <new value>" }
Add Header "int_value": 0, "name": <header name>", "orig": "",
"rewrite": <new value>" }
Remove Header "int_value": 0, "name": <header name>", "orig": "",
"rewrite": "" }

{ "rule_id": "<rule id>", "type": "AD_COOKIE_RW",

Cookie Rewrite "int_value": 0, "name": <cookie name>", "orig":
<original value>", "rewrite": <new value>" }
Add Cookie "int_value": 0, "name": <cookie name>", "orig": "",
"rewrite": <cookie value>" }
Remove Cookie "int_value": 0, "name": <cookie name>", "orig": "",
"rewrite": "" }
{ "rule_id": "<rule id>", "type":
Forward to DC "AD_FORWARD_TO_DC", "int_value": <dc id>,
"name": "", "orig": "", "rewrite": "" }
Read More

Example Logs
View some examples of Imperva log files.
• CEF Example
• LEEF Example
• W3C Example
CEF Example
The following is an example of an Imperva log file in CEF format.

cs5Label=clappsig dproc=Browser cs6=Firefox cs6Label=clapp ccode=IL cicode=Rehovot cs7=31.8969
cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=CEFcustomer123 siteTag=my-site-tag
start=1453290121336 request=site123.abcd.info/ requestmethod=GET qstr=p\=%2fetc%2fpasswd app=HTTP
RSA-AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-
filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name cs11=,,
[{"api_specification_violation_type":"INVALID_PARAM_NAME","parameter_name":"somename"}] cs11Label=Rule
Additional Info

cs8Label=longitude Customer=CEFcustomer123 siteTag=my-site-tag start=1453290121336 request=site123.abcd.info/
main.css ref=www.incapsula.com/lama requestmethod=GET cn1=200 app=HTTP
AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-interaction-
id":"10.10.10.10"}] additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}]
LEEF Example
The following is an example of an Imperva log file in LEEF format.



cs4Label=VID
cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=siemtest siteTag=my-site-tag start=1460303291788
additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-interaction-id":"10.10.10.10"}]
additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}] fileType=12999,50999,50037,50044,
filePermission=37,20,1,1, cs9=,High Risk SQL Expressions,,SQL SELECT Expression, cs9Label=Rule name
cs11=[{"api_specification_violation_type":"INVALID_PARAM_NAME","parameter_name":"somename"}],,,,
cs11Label=Rule Additional Info
W3C Example
The following is an example of an Imperva log file in W3C format.
#Date: 20/Jan/2016 14:22:15
pop s-sitetag cs-uri cs-postbody cs-version sc-action s-externalid cs(Referrer) s-ip s-port cs-method cs-uri-query sc-
status s-xff cs-bytes cs-start c-port cs-rule c-ip cs-protver cs-end cs-additionalReqHeaders cs-additionalResHeaders
cs-severity cs-attacktype cs-attackid s-ruleName cs-ruleInfo

"3412341160002581277" "1594476" "US" "" "Dover" "fullLevelW3C.test.co" "mia" "my-site-tag" "39.1588" "39.1588"
"w3cFullName" "fullLevelW3c.test.co/" "" "HTTP" "REQ_BLOCKED_SECURITY" "43524464361744448" "" "" "" "GET"
SHA256" "1566300670892" "{\"Accept\":\"*/*\"},{\"x-v\":\"1\"},{\"x-fapi-interaction-id\":\"10.10.10.10\"}]"
"[{\"Content-Type\":\"text/html; charset\=UTF-8\"}]" "0" "50999" "16" "High Risk SQL Expressions"
“[{\"api_specification_violation_type\":\"INVALID_PARAM_NAME\",\"parameter_name\":\"somename\"}]"
"mia" "my-site-tag" "" "" "w3cACCESS" "accesslevelw3c.test.co/" "" "HTTP" "" "26210617967913034" "" "" "" "GET" ""
"200" "" "956" "443" "" "12.12.12.12" "TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256" "1566300670892" "{\"Accept\":\"*/
*\"},{\"x-v\":\"1\"},{\"x-fapi-interaction-id\":\"10.10.10.10\"}]" "[{\"Content-Type\":\"text/html; charset\=UTF-8\"}]" ""
"" "" ""

For more examples, go to https://www.w3.org/TR/WD-logfile.html.
Read More

Cloud WAF Error Pages and Codes

page with information to help you identify the error in your account in the Cloud Security Console. Details include:
• error code
• time stamp
• the source IP address of the request
• the IP address and internal ID of the Imperva proxy that handled the request
• the incident ID
For example:
You can use these details, such as the Incident ID, to filter for and investigate the incident on the Security Events page
in the Cloud Security Console. For details, see View Security Events.
Note: The page displayed for errors connecting to your origin server provides additional guidance to you and to your
visitors to help understand and troubleshoot the problem. It is displayed for error codes 8, 20, 30, and 32.

Error codes
Error code number Description displayed to visitors More information
The request was dropped due to a

malformed HTTP request that
cannot be processed by the
Imperva proxy.
There was an error in processing
3
the request What can I do? Clear cookies from
your browser and try again.
SIEM log entry:
REQ_BAD_PARSE_ERROR
The request was dropped due to

idle timeout, although the
4 The request could not be fully read
Imperva proxy was able to
establish a connection to the
origin server.

This error can result from a slow

server response, or termination of
the request by the client.
SIEM log entry:
REQ_BAD_TIMEOUT
The request did not receive a

complete response due to a
malformed HTTP response from
There was an error in processing
5 your origin server.
the server response
SIEM log entry:
REQ_BAD_RESP_PARSE_ERROR
The Imperva proxy could not

connect to your origin server, due
to rejection of the TCP connection
(TCP Reset).
What can I do? Make sure that

The proxy failed to connect to the
Imperva IPs are whitelisted in your
8 web server, due to TCP connection
web server firewall and in the
rejection (TCP Reset)
firewall deployed in front of your
web server. For details, see
Imperva IP addresses.
SIEM log entry:
REQ_BAD_CONNECTION_TO_SERVER
The response to the HTTP request

was incomplete. The client closed
the TCP connection before
9 Error code 9 receiving the full response.
SIEM log entry:
REQ_BAD_CLIENT_CLOSED_CONNECTION
This request was blocked by the

14 The request was blocked based on
security rules
your Block User or Block IP WAF

settings. For details, see Web

Once the user or IP is blocked, the

related session is blocked, and
subsequent requests trigger this
error.
What can I do? Investigate the

incident on the Security Events
page in the Cloud Security
Console. You can filter the events
for one of the details in the error
message, such as Incident ID or IP.
For details, see View Security
Events.
SIEM log entry:
REQ_BLOCKED_SESSION
The request was blocked based on

your WAF settings (Block Request,
Block User, or Block IP) in the
Cloud Security Console. For
details, see Web Protection - WAF
Settings.
What can I do? Investigate the

This request was blocked by the incident on the Security Events
15
security rules page in the Cloud Security
Events.
SIEM log entry:
REQ_BLOCKED_SECURITY

This request was blocked by the
16 your security settings (Bot Access
security rules
Control or Block Specific
Sources) in the Cloud Security

Console. For details, see Web

Protection - Security Settings.
SIEM log entry:
REQ_BLOCKED_ACL

your Block User WAF settings. For
details, see Web Protection - WAF
Settings.
This error is displayed when the

visitor was blocked and the
session was cookieless.
This request was blocked by the What can I do? Investigate the
17
security rules incident on the Security Events
page in the Cloud Security
Events.
SIEM log entry:
REQ_BLOCKED_VISITOR
The request was blocked because

Requests to the web site you are the site is under DDoS attack and
trying to access cannot be served your subscription plan does not
(The site was probably removed include DDoS mitigation.
from the service because it is in
18
violation of our terms of service or Contact your Imperva sales
if it is under a DDoS attack and site representative for more details.
service plan does not cover DDoS
mitigation) SIEM log entry:
REQ_BLOCKED_DDOS
The proxy failed to connect to the Imperva could not connect to your
20 web server, due to TCP connection origin server.
timeout
What can I do?

• Make sure that Imperva IPs

are whitelisted in your web
server firewall and in the
firewall deployed in front of
your web server. For details,
see Imperva IP addresses.
• Make sure that your origin
server is up and running
properly.
SIEM log entry:
REQ_BAD_TIMEOUT_CONNECTION_TO_SERVER
The site is not registered on the

Imperva service, but a user is
attempting to force a direct
connection to Imperva IP
addresses using the hosts file or
another method.
The proxy failed to resolve site What can I do?

from host name, if this site was
22
recently added please allow a few • Verify that the website is
minutes before trying again configured in the Cloud
Security Console.
• If the website was recently
added, wait a few minutes
and try again.
SIEM log entry:
REQ_UNRESOLVED_SITE_UNKNOWN
There is more than one site in your

account with the same host name.
The proxy failed to resolve site
What can I do? Make sure that
from host name - duplicate sites
there is only one site with a given
23 with same host name exist. To
host name configured in the Cloud
resolve this issue, complete the
Security Console.
DNS changes as instructed
SIEM log entry:
REQ_UNRESOLVED_SITE_DUPLICATE

The site cannot be resolved due to

restrictions on your account or
misconfiguration.
The proxy failed to resolve site
What can I do? Make sure that the
from host name - CNAME is invalid.
24 site was added and is configured
To resolve this issue, complete the
properly in the Cloud Security
DNS changes as instructed
Console.
SIEM log entry:
REQ_UNRESOLVED_SITE_INVALID_CNAME
The Imperva proxy is not able to

complete a valid SSL handshake
with your origin server. Imperva
may be connecting using a
protocol that is not supported by
your origin server.
What can I do?

The proxy failed to connect to the
26 • Verify that your origin server
web server, SSL connection failed
supports secure (SSL)
connections.
• Make sure that the SSL
certificate is properly
installed on your origin
server.
SIEM log entry:
REQ_BAD_CONNECTION_TO_SERVER_SSL_FAILURE
SSL is not enabled for the site in

the Cloud Security Console.
What can I do? Make sure that you

29 SSL is not supported have generated an Imperva
certificate or have uploaded your
own custom certificate to the
Cloud Security Console. For
details, see Web Protection -
General Settings.

SIEM log entry:
REQ_SSL_NOT_SUPPORTED
The origin server for the site is not

configured in the Cloud Security
Console.
The proxy failed to connect to the What can I do? Configure your
30 web server, no web server IP is origin server settings on the Origin
defined Servers page. For details, see Load
Balancing Settings.
SIEM log entry:
REQ_NO_IP_FOUND
The HTTP request specifies an

unsupported port number.
31 Port not supported
SIEM log entry:
REQ_ILLEGAL_PORT
Imperva cannot connect to the

origin server. All origin IP
addresses are inaccessible.

The proxy failed to connect to the origin server is up and running,
32
web server and that the origin server settings
are configured properly in the
Cloud Security Console.
SIEM log entry:
REQ_ALL_IPS_DOWN
There may be a temporary

network issue, or connectivity
Timeout reading request issues between Imperva and the
33
POST/PUT body origin server.

origin server is up and running.

SIEM log entry:
REQ_POST_TIMEOUT
The certificate on your origin

server may be missing, revoked,
expired, or there may be a
hostname mismatch between the
certificate and the requested
domain name.
What can I do? Make sure that a

valid certificate is installed on your
The certificate on the web server is origin server.
35
not valid.
Note: This error is only displayed if
the Validate Server Certificate
option is enabled for your site. By
default, the option is disabled. To
enable the option, contact
Support.
SIEM log entry:
REQ_BAD_SERVER_CERTIFICATE
IPv6 support is not enabled for this

site in Imperva. To enable IPv6 for
This site does not have an IPV6 a site, contact Imperva Support.
36
address, please use IPV4 instead
SIEM log entry:
REQ_IPV6_NOT_SUPPORTED
For details, see the Origin Lock

section of Account Settings.
The site is using an origin server What can I do? Make sure that the
37 which is reserved for another correct origin server is configured
account. in the Cloud Security Console.
SIEM log entry:
REQ_LOCKED_IP_VIOLATION

The domain was blacklisted as it

violates Imperva terms of use.
The domain was blacklisted as it
38 Contact Imperva Support.
violates Imperva terms of use.
SIEM log entry:
REQ_DOMAIN_BLACKLISTED
What can I do? Make sure to

perform the required DNS changes
according to instructions in the
Cloud Security Console Websites
The domain is pointing to the
39 page. For details, see Web
wrong DNS records.
Protection - Websites.
SIEM log entry:
REQ_ILLEGAL_IP_VIOLATION
What can I do? Make sure the

certificate on the origin server is
The SSL certificate on the origin
issued to the correct domain.
40 server was issued to a different
domain.
SIEM log entry:
REQ_SSL_CERT_HOST_MISMATCH
What can I do? To change the

current configuration, contact
The site is not currently configured Imperva Support.
41
to support non-SNI connections.
SIEM log entry:
REQ_NON_SNI_FORBIDDEN
The client did not provide a client

SIEM log entry:
42 certificate, and the site requires
REQ_CLIENT_CERT_REQUIRED
one in all connections.
Too many connections are open

What can I do? If you are running a
simultaneously between the
43 load test, make sure to distribute
Imperva proxy and the origin
testing machines between several
server.
different locations.

SIEM log entry:
REQ_TOO_MANY_CONNECTIONS_TO_ORIGIN

Troubleshoot Website Errors
Gain more visibility into connectivity issues that occur when Imperva data centers cannot reach your origin web
servers.
In this topic:
• Overview
• Open the Troubleshooting page
• Filter the displayed data
• View the test results
• Troubleshooting API
Overview
page with information to help you identify the error in your account in the Cloud Security Console.
The Troubleshooting page provides additional details to help you troubleshoot the following errors:
• Error code 20: The Imperva proxy was unable to connect to the origin web server, due to a TCP connection
timeout.
• Error code 8: The Imperva proxy was unable to connect to the origin web server, due to a TCP connection
rejection (TCP reset).
For more details on these errors, see Cloud WAF Error Pages and Codes.
Network connectivity tests
When one of these errors occurs, Imperva automatically runs standard network connectivity tests and displays the
results on the Troubleshooting page.
Ping: A basic test that indicates if a device or IP address is available and reachable.
MTR: MTR tests can assist with detecting network problems, such as routing issues or packet loss. MTR provides the
functionality of Ping and Traceroute tests. Traceroute provides the path between the sender and the receiver of the
test.
• MTR: Sends ICMP echo request packets from the sender to the receiver and if the receiver is available, it replies
with ICMP echo reply packets.
• MTR over TCP: Uses TCP instead of ICMP, bypassing restrictions on ICMP echo packets.
Aggregation
In the event of an ongoing connection error, Imperva displays one set of connectivity tests per origin server per
Imperva data center during each 10-minute interval, instead of providing repeated tests with the same results. (For
example, if there were multiple errors trying to access a specific origin server in a 10 minute interval, and all requests
were routed through the same Imperva data center.)

This prevents the display of redundant data on the Troubleshooting page, reducing noise and enabling you to access
the information you need about an error more quickly.
Open the Troubleshooting page
3. On the sidebar, click Troubleshooting.
Filter the displayed data
The page displays errors for the website and time range you select. You can also apply filters to further limit the errors
that are displayed.
Option Description

Websites
You can view errors for one website at a time.

Time range
In the filter pane on the right of the page, make your

selections and then click Apply All at the bottom.
If you make any changes to the filter options, you

Filters must click Apply All again to apply the filters.
Reset all: Removes all filters selected in the right

pane. It does not affect the options selected in the
top filter bar (Websites, time range, etc.).
View the test results

Expand a row in the table to view the test results. Each row displays results for up to 3 tests.
Column Description
The date and time of the error.

Timestamp
The timestamp is based on the time zone of the
client that made the request (browser/end-user).
The error code that occurred and was displayed on

Error code
the error page at the time of the request.

Column Description
The IP address and/or CNAME of your origin web

server to which the request was directed.
If a CNAME is defined for the origin server on the

Origin IP / CNAME
Website Settings > Origin Servers page, the CNAME
is displayed, as well as the IP address to which the
CNAME was resolved at the time the test was
performed.
The Imperva data center (PoP) that handled the

request.
Imperva data center
For the full list of Imperva data centers, see Imperva
A unique ID assigned by Imperva.
This ID is also displayed on the HTML error page

presented to your website visitors when a
Connectivity test ID connectivity error occurs. The ID can help you
investigate the issue end to end by then searching
the Troubleshooting page to find details of the
connectivity tests run at the time the error took
place.
Account ID The ID of your Imperva cloud account.

Troubleshooting API
Get connectivity test details for your websites using the Imperva API.
For instructions on using the Troubleshooting API, see Troubleshooting API Definition.

Custom Error Pages

You can configure custom error pages to display to your website visitors in the event of an error.
Custom error pages give your site a more professional look, and can provide useful information to your visitors.
Note: The custom error page template you provide is restricted to 600K characters.
In this topic:
• Overview
• Configure a custom error page for a website
• Error page guidelines
• Configure a custom error page for all websites in your account
• Conflicts between account settings and website settings
• Website error page API
Overview
You can provide custom HTML error pages for your website to replace the default error pages used by Imperva.
Imperva then displays your custom error pages to website visitors, populating placeholders with the appropriate text
for each type of error page.
You can define a single custom error page for Imperva to display for each of the following error types, or define
separate error pages for any or all of the error types.
Error type Displayed when...

Connection timeout
timed out.
the client.
the origin server.
the origin server.
challenge.
Security Console.
Configure a custom error page for a website
In the Cloud Security Console, open the Delivery Settings page.


3. On the sidebar, click CDN > Delivery and scroll to the Custom Error Page section.
Option Description
Select an error type.
Paste your custom HTML error page into the input

box, or copy the Imperva default template and
modify it to meet your needs. Make sure to follow
the Error page guidelines.
Default: The Default option enables you to define a

custom error page to use for all error types.
Edit Available Pages
You can define a custom error page for a specific
error type in addition to the Default option. The
Default template is then used for all other error
types.
To remove a custom error page for a specific type,

delete the template from the input box and save
your changes.
Copies Imperva's default error page template to the

clipboard. You can use it as a basis for customizing
the design.
Note that the template includes the place holders

($TITLE$) and ($BODY$). They indicate the location
of the dynamic title and body information that will
be inserted by Imperva and should not be modified.
Copy Default Template
• The ($TITLE$) placeholder holds only text, and
will be populated with the appropriate text for
each type of error page.
• The ($BODY$) placeholder holds both text and
design. We recommended that you verify that
there are no design conflicts before providing
us with the customized page.
To preview your custom error page, select an error

type and click Preview.
Preview
Note: If there is a custom error page defined in the
account settings that is overriding the website
settings, it is displayed here. For more details, see

Option Description
Conflicts between account settings and website
settings.
Error page guidelines

• Your page must include $TITLE$ and $BODY$ placeholders to indicate the location of the information that is
dynamically inserted by Imperva depending on the type of error that occurs.
• The custom error page template must include valid HTML syntax.
• Any reference to an external resource or link should be absolute.
• Any reference within the HTML to external resources should refer to resources on domains that are not on the
Imperva network and are publicly accessible. This is to ensure the proper display of error pages when the
website is unavailable to serve those resources.
• The custom error page template cannot contain:
• < iframe> tag
• <script> tag
• illegal HTML actions, such as these HTML event attributes: onload, onerror, onmessage, onoffline,
ononline, onchange, onfocus, oninput, onsearch, onsubmit, onselect
Configure a custom error page for all websites in your account
If you want to define custom error pages to use for all of the websites in your account, Imperva Support can configure
this for you. You can define a separate page for each error type.
The process is as follows:
1. Use the template available on the Website Delivery Settings page and follow the guidelines above to create
custom error pages.
2. When the pages are ready, send them to Support for deployment.
Conflicts between account settings and website settings
Which error pages are used when there are custom pages defined in both the website settings and account settings?
If a “more specific” custom error page is defined, it overrides more general pages. For example, if there is a custom
error page defined for an Access denied error at the website level, it overrides a custom error page defined for an
Access denied error at the account level, and is presented in the event of an error of that type.
Custom error pages are displayed according to the following priority order:
Custom default Custom default Custom error page Custom error page RESULT - Which
error page error page for a specific error for a specific error custom error page
(Account) (Website) type (Account) type (Website) is used?
Website custom
Exists Exists Exists Exists error page for a
specific error type

Custom default Custom default Custom error page Custom error page RESULT - Which
error page error page for a specific error for a specific error custom error page
(Account) (Website) type (Account) type (Website) is used?
Account custom
Exists Exists Exists error page for a
specific error type
Website custom
Exists Exists
default error page
Account custom
Exists
default error page
Website error page API
You can also manage custom error pages for your sites using the delivery settings APIs.
For details, see Delivery Settings API Definition.
See also
For a list of common errors and tips for troubleshooting, see Cloud WAF Error Pages and Codes.


Global CDN and Optimizer – Introduction

Imperva’s CDN is a globally distributed network of data centers that delivers full site acceleration through
intelligent caching and content optimization. Imperva’s application-aware CDN intelligently and dynamically profiles
website resources in order to identify all cacheable content (dynamic and static). This allows you to get better
performance out of your CDN, as compared to solutions that cannot identify cacheable dynamic content.
Click here for an up-to-date network map.

Benefits
• Full website acceleration
• A global network of caching proxies
• Automated profiling and caching of content
• Cloud-based Layer 7 server and data center load balancing
• Content and session optimization techniques
• Support for HTTP/2 performance enhancements
• Realtime dashboard for traffic monitoring and event analysis
How does the CDN work?
Getting Your Content Closer to Your Visitors
The main premise of a CDN is caching content close to your visitors in order to minimize the time it takes to download
the content to the visitor's browser. Imperva maintains a geographically distributed network of data centers to
minimize content delivery time for any visitor regardless of geographical origin.
In addition, the Imperva network is optimized to reduce latency through:
• Partnerships with Tier 1 transit providers

• Extensive peering with ISPs and cloud hosting providers

• Implementation of route optimization techniques

• Leveraging Internet Exchange services
Dynamic Content Caching
The Imperva CDN is uniquely able to identify and cache content that is considered dynamic by other CDNs, but is in
fact static. This is done by profiling the application and detecting resources that are generated by the application as
dynamic content, but in fact have only presentation content (without application content). Such resources can be
cached for short periods of time, optimizing performance, while always displaying fresh content.
Session and Content Optimization
Each resource that is served by Imperva is optimized for minimal delivery time. This is done using a variety of
methods (such as image compression and JavaScript minification), as well as session optimization techniques (such
as TCP connection pools and session reuse).
Custom Caching Rules
Imperva provides a comprehensive set of tools to customize and control its caching logic. Site administrators can
easily define caching attributes for specific resources, such as whether or not to cache them and their Time to Live
(TTL).
Load Balancing
For organizations with more than a single web server or multiple data centers, Imperva provides a fully customizable
Layer 7 load balancer. Unlike DNS-based load balancers, Imperva’s load balancer is capable of making routing
decisions for every request. This ensures optimal traffic distribution while making sure that every request is served by
the most responsive server.
HTTP/2 Support
Imperva supports HTTP/2, which enables supporting browsers to take advantage of the performance enhancements
provided by HTTP/2. Non-supporting browsers can connect via HTTP/1.0 or HTTP/1.1.
IPv6 Support
Imperva provides complete IPv6 support of both client-side (between your end users and Imperva’s PoP) and server-
side (between Imperva’s PoP and your origin servers) IPv6 traffic. In this way, Imperva acts as your IPv6 gateway, so
that you can retain your IPv4 setups and support clients who send both IPv4 and IPv6.
How To

• Onboarding and Keeping Your Own CDN
• Enabling HTTP/2 Support


Cache Settings
Define content caching policies and caching rules for your website.
Learn more: Caching Duration
Note: After making changes to cache settings, you may want to manually clear the cache. For details, see Purge the
cache below.
Where do I find it?

3. On the sidebar, click CDN > Cache.
In this topic:
• Purge the cache

• Debug caching
• Set cache mode
• Create custom cache rules
• Set advanced cache settings
• Cache Settings API
Purge the cache
The following options are available under Operations:
Purge the entire cache.
After a major change to your website, such as a

version update, you may want to clear all resources
Purge Cache in the cache immediately, without waiting for the
caching period to expire.
Note: You can automate the purge cache action

using the API. For details, see Site Management API.
Purge a subset of the site's cached resources.

Purge Specific Resource
You can purge resources that match a specified tag
or URL.

Tag: You can purge resources according to tag

names. Resources can be tagged in the following
ways:
• According to a response header value in the

origin resources. For details, see the Tag the
Response According to the Value of this
Header option under Response.
• Using a custom cache rule. For details, see
Create custom cache rules.
You can select custom tags from the drop-down list

or enter tags manually. The list includes tags that
were defined by the Create Tag and Enrich Cache
Key cache rules. The list does not contain tags set by
the origin.
To specify multiple tags, enter a comma-separated

list. Only resources that include all specified tags will
be purged.
URL: You can purge all resources that match a

specified string.
• Enter a complete URL, such as /intro/settings/

logo.png
• For one of the other rules, enter a specific URL
string that will be matched as a prefix, infix, or
suffix of the URL, depending on the rule.
Note: Imperva Audit Trail tracks and displays the Cache purged and Specific resources purged audit events. For
more details, see Audit Trail.
Debug caching
The XRAY Access URL, located under Operations, enables you to view specialized response headers for a single
browser session.
Gain visibility into Imperva CDN and caching behavior for your sites using Imperva XRAY debug headers. Troubleshoot
inconsistencies in displayed site content.
For details, see XRAY Debug Headers.

Set cache mode
Configure the overall caching policy for your website.
Note: We remove some non-essential HTTP response headers from your resources before storing them in our cache. If
there are specific response headers that you want sent to clients, you can specify that they should be cached along
with the resource using the Cache Response Headers option. For details, see Response.

The following options are available under Cache Mode:
Turns off all caching for the website.

No caching
Any existing custom cache rules are ignored.
Cache according to custom cache rules only. For

details, see Create custom cache rules.
Custom HTTPS caching: Enables caching of HTTPS

resources according to your custom cache rules.
Custom caching If there are no custom cache rules defined for the
site, no caching is performed and all requested
content is retrieved from your origin web server.
Note: If you switch from another cache mode to

Custom caching, some options will be reset to “off”
and will be unavailable while caching is disabled.
Cache according to standard HTTP headers.
Only content that was marked by the site's

developer / web server as static using standard
HTTP headers is cached.
Standard HTTPS caching: (Available for SSL sites)

Enables HTTPS caching of images, css files, JS files,
and resources defined with the Cache-Control:
Standard caching
public header, according to standard HTTP headers.
• Include HTML resources. When selecting this

option, you can introduce the risk of returning
HTML resources that contain personal
information, such as PII, ePHI, and PAN data.
• Include all resource types. Enables
HTTPS caching for all resource types,
including HTML resources.
Also profile dynamic pages to identify and cache

static content that was not marked as static.
Smart caching
In addition to content that was marked by the site's
developer / web server as static using standard
HTTP headers, Imperva also profiles other resources
to identify and cache static content that was not

marked as such. The time period (in minutes, hours,

days or weeks) that you set for this option
determines how often the cache is refreshed.
Smart HTTPS caching: (Available for SSL sites)

Enables HTTPS caching of images, css files, JS files,
and resources defined with the Cache-Control:
public header, according to standard HTTP headers
and Imperva’s smart profiling.
• Include HTML resources. When selecting this

option, you can introduce the risk of returning
HTML resources that contain personal
• Include all resource types. Enables
HTTPS caching for all resource types,
including HTML resources.
Cache every resource on the web server for the

All site content is cached. The time period (in

minutes, hours, days or weeks) that you set for this
option determines how often the cache is refreshed
(TTL).
Cache all
Cache all HTTPS resources (including HTML):
(Available for SSL sites) Enables caching of all HTTPS
resources, including HTML resources. When
selecting this option, you can introduce the risk of
returning HTML resources that contain personal
Note:
• In addition to caching according to the selected mode, content is also cached as specified by any custom cache
rules that are defined for your site. For details, see Create custom cache rules.
• Resources that include explicit caching directives against caching, as defined in the resources themselves using
the Cache-Control or Expires HTTP headers, are not cached.
Create custom cache rules
Custom cache rules let you define specific exceptions to the caching rules that are set by the overall Cache Mode rules
described above. You can define conditions for when and if specific resources should be cached.
In the Custom Cache Rules section, click Add Rule.

Rule Filter The filter defines the conditions that trigger the rule
action. If left empty, the rule is always run. For
details, see Define the rule filter.
Define the action you want Imperva to take for every

Rule Action request that matches the rule. For details, see Select
an action.
Give the rule a meaningful name.
Note: The Rule Name may not contain special

Rule Name
characters. Only alphanumeric, space, period,
comma, colon, hyphen, and underscore characters
are allowed.
Enable Rule Enable or disable the rule.
Define the rule filter
Define a filter for the rule using predefined parameters.
The following rule filter parameters are available for cache rules:
• Client ID
• Cookie Exists
• Cookie Value
• Header Exists
• Header Value
• Param Exists
• Param Value
• URL

• User-Agent
For details on the parameters, see Rule Filter Parameters.
Under Apply This Rule If, select the part of the

request or the sessions to which the filter is applied.
Matched object
For example, Client IP or Country. For full details on
the available parameters, see Rule Filter Parameters.
Defines how the filter value is matched.
Most filter parameters support only a subset of the

list of operators. For example, the QueryString filter
parameter supports only the ‘equal to’ and ‘not
equal to’ operators. When a filter parameter is
Operator selected (see Matched object above), only the
supported operators will be displayed in the
operator field.
For the full list of filter parameters and the

supported operators for each, see Rule Filter
Parameters.
Value The value to be matched.
When you define a filter and click +Add, the filter

syntax is added to the Editor. You can add as many
filters as required. The filters are added to the rule
syntax using the AND logic. For information about
combining filters using the OR logic, refer to the
Editor Syntax Guide.
Alternatively, you can add filters directly using the

native syntax. Every rule is checked for syntax
validity before it is saved. For details, see the Syntax
Guide.

Validate
automatically whenever you save a rule.
Select an action
Define the action you want to take for every request that matches the rule.

Action Description
Always cache the resource.

Cache Resource
Can be used with the following filter parameters
only: Param Exists, Param Value, URL
Cache Resource on Client Cache the resource on the client.

Don't Cache Resource Never cache the resource.
Tag the resources that match the rule conditions.

This enables you to subsequently purge those
resources according to the tag name.
Tag names can include the following characters

only: alphanumeric (a-z, A-Z, 0-9),
Create Tag &,’,^,-,$,!,`,#,%,.,+,~,_,| Spaces are not allowed.
Note: Tags are added when the resource is cached. If

you add or modify tags, purge the resource to
enable retagging.
For more details, see Purge the cache.
By default, we create the cache key according to the

requested URL. You can choose to create different
cache keys based on protocol (http/s), header,
cookie, or geolocation, so that the matching
resources are cached as different resources.
• HTTP/HTTPS Scheme: A resource is cached

separately depending on whether it is
accessed over HTTP or HTTPS.
Differentiate Cache Key by... • Header: Specify a header name.
• Cookie: Specify a cookie name.
• Geolocation: Resources are cached separately

based on geolocation of the request.
Add locations to country code groups using

standard 2-letter country codes. A resource is
cached separately for each country code
group, plus an additional entry for all other
country codes.

Action Description
To add multiple geolocations to a country
code group, enter a comma separated list,
such as CN,CO,US.
If the parameters do not affect which resource is

returned, you can choose to ignore them.
Ignore Parameters in Cache Key
Add the name of a specific parameter, or select
Ignore All Parameters.
Add text to enhance the cache key. A new, enriched

Enrich Cache Key cache key is then calculated using the additional
input.
The Authorization request header contains

credentials to authenticate user. By default, if this
header is present, we do not return cached content
Cache Authenticated Resources and the request is forwarded to the origin server.
Selecting this option returns cached content if

available without authenticating the client.
Validate with the origin server that the resource has

not changed before returning the cached resource to
the client.
This might be used for the purpose of client

Force Resource Validation
authentication. If the client sends the Authorization
header and this rule is triggered, Imperva forwards
the request to your origin server and you can then
verify client authorization and return the result as
expected.
Expired resources are returned from cache and

refreshed asynchronously in the background.
If the origin server cannot be reached to refresh the

cache, stale content continues to be displayed for
Serve Stale Content
the amount of time specified for TTL.
Note: When there is at least one enabled custom

rule using this action, the global Serve Stale
Content option is automatically enabled if it was
not already enabled, but it does not apply globally

Action Description
and cannot be modified. The custom rules override
the global setting.
For more details, see the Serve Stale Content option

below.
Precedence among caching rules
Because there may possibly be conflicts between the Cache Rules you define and the logic dictated by the Caching
Mode, the following order of precedence is applied to the various types of rules:
1. Don't Cache Resource Cache Rules

2. Cache Resource Cache Rules
3. Caching Mode
4. Cache directives sent by the web server (in HTTP headers)
Note: If there is a conflict between the caching durations defined in the Caching Mode and in the Advanced Caching
Rules, the longer period of the two is applied. The same goes for a conflict between the caching rule of a certain
resource and one of its sub-resources.
Set advanced cache settings
The following options let you control HTTP features that may interfere with Imperva's caching behavior, thereby
reducing performance. These are triggered by HTTP request and response headers that instruct the web server or
client not to cache certain content, or by the browser’s behavior.
These caching options are often enabled on web servers or browsers due to misconfiguration, so the default behavior
is to ignore them. You can change this behavior using the settings below, located under Advanced Settings.
Cache key
For example, use the same cached resource for

Use the Same Cache for Full and Naked Domains
www.example.com/a and example.com/a.
Cache resources in accordance with the Vary

response header. Only resources with the Vary value
‘Accept-Encoding’ are cached.
Vary is an HTTP response header that indicates how

Comply with Vary
to match future request headers to decide if a
cached response can be used.
When this option is disabled, the Vary header is

ignored.

Response
Cache All Headers: By default, response headers

are not cached. When the Cache Response Headers
option is selected, all headers in the responses are
cached.
Custom: Specify which response headers should

be cached along with the resource.
Cache Response Headers Examples of commonly used headers:
• Access-Control-Allow-Origin
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Request-Method
• Access-Control-Request-Headers
If the Custom option is selected and no headers are

specified, headers will not be cached.
Adds an intermediate cache between other Imperva

PoPs and your origin servers to protect your servers
Cache Shield from redundant requests.
For details, see Cache Shield.
Specify which origin response header contains the

cache tags in your resources.
This enables you to subsequently purge those

resources according to the tag name. For details, see
Purge the cache.
If the specified header includes multiple tags

separated by commas, the resources is tagged with
Tag the Response According to the Value of this
multiple tags.
Header
For example:
Header Name: Cache-Tag
Header Value: “tag1,tag2,tag3”
Tagging Result: The resource is tagged with 3

different tags - “tag1”, “tag2”, and “tag3”

Cache responses that don’t have a message body.
By default, files that don’t have a message body are

Cache Empty Responses
not cached (where content length = 0) . When the
Cache Empty Responses option is selected, these
resources are cached.
When this option is checked Imperva will cache 301,

302, 303, 307, and 308 redirect response headers
containing the target URI.
• 301 and 308 response headers are cached for 2

Cache 3xx Responses hours.
• The length of time that 302, 303, and 307
response headers are cached for is based on
Cache-Control headers, according to our
standard caching mechanism. For details, see
Caching Duration.
Cache responses of unavailable resources for a

Cache 404 Responses
Cache HTTP 1.0 type responses that don’t include

the Content-Length header or chunking.
By default, responses in HTTP 1.0 format are not

Cache HTTP 1.0 responses cached. HTTP 1.0 sends a response and then closes
the connection to indicate that it is finished.
Because the connection may have been closed for
other reasons, we cannot determine if the whole
response has been received.
Expired resources are returned from cache and

refreshed asynchronously in the background.
Stale content refers to cached resources whose TTL

has expired. The first request after the cache period
expires causes the resource to be retrieved from
Serve Stale Content
cache. The current cached version (stale) of the
resource is displayed without delaying the response,
while the cache is refreshed in the background.
This option can also be useful when the origin server

is temporarily unavailable and the cache cannot be
refreshed. Stale content is served instead of

displaying an error to end users, according to one of

the following options:
• Adaptive: Stale content is served for a

duration of 2 to 24 hours based on the time
passed since the resource was last updated.
Frequent updates result in a shorter stale
period. Infrequent updates result in a longer
stale period.
• Custom: Serve stale content for the specified
amount of time.
TTL
By default, the longest duration is used in case of

conflict between caching rules or modes. When this
Use Shortest Caching Duration in Case of Conflicts
option is selected, Imperva uses the shortest
duration in case of conflict.
When this option is selected, Imperva prefers using

Prefer 'Last Modified' over Etag Last Modified values (if available) over eTag values
(recommended on multi-server setups).
Client-side caching
Cache content on client browsers or applications.

Enable Client-Side Caching
When not enabled, content is cached only on the
Imperva proxies.
By default, these cache directives are ignored.

Resources are dynamically profiled and re-
configured to optimize performance.
no-cache is a directive in the HTTP Cache-Control

Comply with No-Cache and Max-Age Directives in request header that instructs web proxies not to
Client Requests return cached content without first checking with
the server to see if the content has changed.
max-age is a directive in the HTTP Cache-Control

request header that instructs web proxies not to
return content that is over a certain expiration age.
Send Age Header

Send Cache-Control: max-age and Age headers.

By default, in the Cache-control: max-age header,

we send the value of:
<max-age from origin> minus <age (time in cache)>
and do not send the Age header.
If you enable the Send Age Header option, we send

the full Cache-control: max-age value from origin
and also the Age header.
Cache Settings API

Define content caching policies and caching rules for your websites using the API.
For instructions on using the Cache Settings API, see Cache Settings API Definition.

Cache Settings API Definition

Caching Duration
This topic explains how Imperva determines which resources are cached, and for how long.
In this topic:
• Overview
• Caching directives
• Caching duration for static resources
• Caching additional resources
• Caching duration for additional resources
• Client-side caching
• Summary
• Troubleshoot caching
Overview
There are three mechanisms that Imperva uses to determine caching behavior:
Instructions sent by the origin web server contained

Caching directives in the resources themselves using the HTTP Cache-
Control header.
The caching policy that you define for a website in
Caching mode the Imperva Cloud Security Console. Overrides
caching directives.
Custom rules you set in the Imperva Cloud Security
Caching rules
Console to override the general caching mode.
For more details, and to define content caching mode and caching rules, see Cache Settings.
Caching directives
The HTTP Cache-Control header enables web servers to return cache directives per resource that control if, and for
how long, browsers and other intermediate caches can cache an individual resource.
Example:
Cache directives that indicate if resources are static or dynamic:
static: Cache-Control: public, max-age=3600
dynamic: Cache-Control: no-cache, private, max-age=0

Caching duration for static resources
Imperva caches static resources according to the Cache-Control header's max-age caching directive max-age defines
the maximum amount of time in seconds that a resource is considered fresh. After this amount of time has passed, the
resource is validated with the origin server on the next request. If the resource has changed, it is fetched from the
origin server.

You can choose to enable asynchronous validation to display the current cached version (unfresh) of the resource
without delaying the response, while the cache is refreshed asynchronously. For details, see the Serve Stale Content
option in the Cache Settings.
If max-age is not defined in the header, Imperva calculates max-age as follows:
Max-age= Expires - date
Example:
Response headers in a resource served from the Imperva cache.
Cache-Control: max-age=3600, public

Date: Tue, 08 Aug 2017 03:00:00 GMT
Etag: "f095bdda"
Expires: Tue, 08 2017 04:00:00 GMT
Max-age was calculated as follows:
max-age= Expires - date
Caching [Tue,
max-age= additional
08 2017resources
04:00:00] - [Tue, 08 Aug 2017 03:00:00] = 3600 seconds
When using the Smart caching caching mode, static resources are identified and cached as described above, under
Caching duration for static resources.

In addition, Imperva dynamically profiles website traffic in order to identify additional static resources that can be
cached. This increases cache ratio without the need to add cache directives at the origin.
Some resources are cached although they don't have headers that consider them as cacheable. A resource is
cacheable if:
• It is requested by five different IPs within a one-hour window.

• The same resource was identified in each case (based on a cache key). Smart caching learns how many times
the resource was changed due to request structure, rules, or header configuration.
The decision to cache addition resources is made independently by each Imperva proxy.
Resources configured as dynamic according to their HTTP headers are not analyzed by Imperva's algorithms. See the
example above, under Caching directives.
Caching duration for additional resources
After identifying additional static resources that can be cached, Imperva calculates max-age to determine the length
of time that the resources can be cached.
Imperva uses the Last-Modified response header in the resource to calculate max-age.
• The max-age value is set to one hour for each day since the Last Modified date, with a maximum of up to 24
hours.
• If the resource was modified within the last 24 hours, max-age is determined by the setting defined in the Cloud
Security Console Performance Settings page under Caching Mode.
Client-side caching
Imperva automatically optimizes client-side caching to store as much content as possible on the client browser or
application.
Resources are cached on the client-side as follows:
max-age=[max-age in caching directive] - [time since the resource was added to the Imperva cache]
Example:
At 12:00:00, a resource with a max-age of 100 seconds is requested, and is served from the origin server.
At 12:00:10, the same resource is requested and can be returned from Imperva.
100 (max-age) - 10 (length of time the resource was cached on Imperva) = 90 (max-age for caching on the client-side)
Note: You can disable client-side caching on the Performance Settings page.

Summary
Cache-Control header Dynamic Profiling Cache Rule
Imperva cache max-age = X
If [time since last
modified] < 24 hours,
max-age = caching mode
setting on the
Performance Settings
page.
max-age = X - [time since
max-age = TTL*
Client cache the resource was added If [time since last
to the Imperva cache] modified] > 24 hours,
max-age = one hour for
each day since Last
Modified date, up to a
maximum of 24 hours
* Time to live defined in a caching rule:
Troubleshoot caching
The following information in the X-Iinfo HTTP response header is used by Imperva to track and troubleshoot caching
of resources. You can use it as a quick way of checking if a specific resource was cached.
For example:
X-Iinfo: 3-430176-0 NNNN RT(1484836152368 39) q(0 -1 -1 -1) r(0 -1) B13 U2
Where NNNN indicates the following:
The first character indicates the status of the connection between Imperva and the origin server. Values include:
• N = New
• E = Existing
• F = From pool - fresh
• P/S = From pool - used
• 0 = No connection
• 2 = From PoP level cache

• X = Unknown
• s/p = (lower case) Through origin PoP
The second character indicates whether the resource was served from the cache. Values include:
• C = Cache hit without validation: The resource is fresh and was returned from the cache without validation by
the origin server.
• c = Stale content served from cache: TTL has expired. Stale content is served from the cache without waiting for
validation from the origin server, while validation is performed in the background. (Indicates that the Serve
Stale Content option or custom cache rule with the Serve Stale Content action is defined in Cache Settings.)
• V = Cache hit after validation: TTL has expired. The resource was returned from the cache after it was validated
with the origin server.
• N = Cache miss: The resource was not returned from the cache.
The third character indicates whether or not the resource (JavaScript, CSS, or HTML) is compressed on the proxy.
Values include:
• Y = Compressed
• N = Not compressed. Indicates that the Dynamically Compress JavaScript, CSS, and HTML Files option on the
Cloud Security Console Delivery page is disabled. For details, see Delivery Settings.
The fourth character indicates whether the connection was taken from pre-pooled TCP connections. Values include:
• Y = A pre-pooled connection was used. Indicates that the Pre-Pool TCP Connections option on the Cloud
Security Console Delivery page is enabled. For details, see Delivery Settings.
• N = A pre-pooled connection was not used.
Read More
• Cache Settings

Cache Shield
Cache Shield adds an intermediate cache between other Imperva PoPs and your origin servers to protect your servers
from redundant requests.
• Reduces spikes on the origin during high request periods, such as after a cache purge
• Increases likelihood of cache hits as all requests go through one PoP
• Reduces outgoing traffic from your public cloud origin and decreases your monthly bill
Cache Shield requires the appropriate FlexProtect licensing.
Note: To enable enhanced performance for dynamic content (resources that are not cached in the Imperva PoPs), see
Dynamic Content Acceleration.
In this topic:
• How it works
• Enable Cache Shield
• FAQ
How it works
Imperva's CDN dynamically profiles website resources in order to identify all cacheable content (dynamic and static).
When a client request is made for a cacheable resource, and that resource is not cached in our system, the request
must be sent on to your origin server.
By default, each of our PoPs can access the origin server directly, and as a result, can overwhelm it with requests. A
client request goes to one of our PoPs, and that PoP requests the resource from the origin. When requests are received
from different locations, they are each handled by a different PoP, and then each PoP passes the request on to origin.
Cache Shield designates a specific PoP to serve as an intermediate cache between our other PoPs and your origin
servers. When enabled, all requests to the origin go through the Cache Shield PoP. If another PoP does not have the
requested content in its cache, it must query the Cache Shield PoP to determine if the resource is already cached
there. This significantly reduces requests to the origin, and increases your cache hit ratio.

Without Cache Shield
With Cache Shield

Enable Cache Shield

You can enable Cache Shield per site in your account:
1. In the Cloud Security Console, open the Cache Settings page.

2. Expand the Advanced section.
3. In the Response section, enable the Cache Shield option.
FAQ
Can't the Cache Shield PoP get overloaded as well?
When you enable Cache Shield for your site, Imperva selects 3 PoPs to serve as Cache Shield PoPs, and then chooses
one based on best connectivity and availability at the time it is needed. Our performance algorithm chooses the PoP
for optimal performance and memory usage.
Can rate limiting on the origin servers be an issue?
Yes. When Cache Shield is enabled, all traffic reaches the origin from a single PoP. If you have implemented a rate
limiting policy per IP on your origin server, the traffic reaching the origin may exceed the threshold and result in
dropped traffic.
After enabling Cache Shield, how can I check if it is being used?
Run XRAY Debug Headers and check for the incap-cache-level header. L3 indicates that the Cache Shield PoP was
used.

XRAY Debug Headers
Gain visibility into Imperva CDN and caching behavior for your sites using Imperva XRAY debug headers. Troubleshoot
inconsistencies in displayed site content.
In this topic:
• Overview
• Enable debug headers
• Available headers
• Debug headers API
Overview
When you enable XRAY for a browser session, Imperva adds predefined HTTP response headers to your requests. The
headers provide you with additional information such as cache hits and misses, TTL values, and PoP details.
The debug headers can help you troubleshoot many common issues.
For example:
An old resource is returned from the Imperva cache:
• Is there an issue in the origin server?

• Is there a TTL issue?
• Did the cache purge as expected?
• How many times was the wrong resource returned?
• Which PoP returned the incorrect content?
A resource is not returned from the Imperva cache:
• Are cache settings correct? Is it a cacheable resource?

• Why wasn't the resource returned from the cache? What was the miss reason?
Resource download time is high:
• How long did it take to fetch the resource from the origin to Imperva?
• How much time was spent on the network?
• What is the server "think time"?
Enable debug headers
Copy the access token into your browser to enable debug headers. Once activated, the XRAY debug headers are
available for 10 minutes.

Note: To ensure that the debug headers work properly, it is recommended to enable cookies in your browser.
1. On the Cache Settings page, under Operations > XRAY Access URL, copy the URL.
2. Paste the URL into any browser. This activates the debug header functionality.
3. Navigate to any page on the site.
4. Open developer tools (for example, using F12 in Chrome or IE on Windows) and refresh the page.
5. Click a resource to view the response headers.
The access token expires after 10 minutes. To generate a new access token, click the refresh button .
Available headers
The following predefined response headers are provided:
Header Name Description Sample Value
The PoP that handled the request.
incap-pop For the list of PoP codes and LAX/FRA/IAD

locations, see Imperva Data
Centers (PoPs).
The origin PoP configured for your

origin server.
incap-origin-pop AMS/LON/CDG
For details on the Origin PoP
setting, see Dynamic Content
Acceleration.
The ID of the proxy that handled

incap-proxy-id 10253
the request.
Indicates if the connection is a new

incap-connection or existing connection between New, Existing
Imperva and the origin server.
The ID number assigned to a

request. It is written in the Imperva
logs, and can be used to connect
between an event in the log and a
specific request.
incap-req-id 123456789123456
The request ID is also available by
enabling the INCAP-REQ-ID
request header in the Cloud
Security Console in Website >
Settings > General > Request


Headers. When enabled, Imperva
will add new headers to each
request coming to the origin
server.
Indicates if the response to the

request was returned from the
Imperva cache or from the origin
server.
hit: content was returned from the

cache.
hit/miss
incap-cache-status miss: content was returned from
synchronous/asynchronous
the origin server.
validation
synchronous/asynchronous
validation: indicates the cache
refresh option that is defined for
the site. For more details, see the
Serve Stale Content option in
Cache Settings.
Hit reasons:
• Cached according to
response headers: The
origin server's response
headers.
• Cached by rule <111>:
Indicates the ID of the
The reason why there was a cache
advanced caching rule
hit (content returned from the
defined in the site's
cache) or miss (content returned
Performance Settings.
incap-cache-reason from the origin server).
• Cached heuristically: The
content was cached based
For more details on caching, see
on Imperva's caching
Caching Duration.
mechanism.
Miss reasons:
• Caching disabled by rule

<111>: Indicates the ID of
the advanced caching rule
defined in the site's
Performance settings.


• Content Changed: Content
in the body of the resource
was changed.
• Actively Non-Cacheable:
The resource contains
headers that state explicitly
that it should not be cached,
such as "No-Cache".
• Too Large: The resource
exceeded an existing per-file
size limit based on the
purchased plan and was not
cached.
• Vary Header: The Comply
with Vary option is enabled.
Resources with the Vary
header are not cached. For
more details, see Cache
Settings.
• Cache Off: Caching is
disabled in the site's
Imperva Performance
Settings.
• Not GET: The request was
not a GET request. Only
GET requests are cached.
• Rate Exceeded: The caching
rate was over the limit.
• Permanently Non
Cacheable: The resource
cannot and will not be
cached, such as a backdoor
URL.
• Thrashing: The resource
was removed from the cache
based on the internal
thrashing mechanism used
for monitoring.
• By response code: Only
resources with response
codes 200 and 304 are
cached.
• SSL Restrictions: HTTPS
resources are generally not
cached unless specific
settings or rules are defined
in the Cloud Security
Console.


• Unsupported Encoding:
The encoding used by the
origin server is not
supporting by Imperva
caching properties. Imperva
supports gzip only.
• Ranges: A resource with a
Range header is not
cached.This header is used
when a request is made to
only a part of a resource.
• Authorization: Any resource
that uses an HTTP
authentication mechanism
is not cached.
• Passively Non Cacheable:
The response had no cache-
related headers, no
matching caching rules, and
the caching mode is
standard (Static Only).
• First Visit: The resource was
requested for the first time
through Imperva proxies
and was therefore not
cached.
• Candidate: While Imperva is
still evaluating the resource
status, it is flagged as
"candidate" and is not
cached.
• Evicted: The resource was
previously cached, but was
deleted due to the site's
cache limits.
• Connectivity issue
The Imperva cache level that the

content was returned from.
L1 = Level 1. The proxy cache.

incap-cache-level L1/L2
L2 = Level 2. The PoP cache,
behind the proxy.
L3 = Level 3. The Cache Shield PoP.

The length of time the resource

incap-cache-duration 300 sec
has been in the cache.
The length of time the resource

will remain in the cache.
incap-cache-ttl A negative TTL value indicates that 200 sec

the resource has expired but
Imperva can still serve it from the
cache if async validation is used.
The cache key identifies the

specific cached resource.
It can be useful to compare the

incap-cache-key cache keys for a resource where e129d65275187708c4818d9d89b12345
different content was received by
different users, such as for users
from different geographical
locations.
The list of tags added to the

resource by cache rules.
The list includes tags that were

defined by the Create Tag and
Enrich Cache Key cache rules. It
incap-cache-tags tag1 tag2 tag3
does not contain tags defined by
the origin.
For details on creating cache rules

to tag resources, see Cache
Settings.
The list of IDs of cache rules

triggered by the request.
incap-cache-rules 123456 123457 123460
For details on cache rules, see
Cache Settings.
incap-rtt The round-trip travel time on the 100 msec

network between Imperva and the


origin server. It does not include
the server processing time (incap-
think-time).
The amount of time that the

incap-think-time request is being processed on the 50 msec
origin server.
• Blocked session: The

session was blocked based
on security rule options
defined in the WAF Settings
page to block a user or IP.
• Blocked visitor: The user
was blocked.
• Blocked by ACL: The
The block type or security rule request was blocked based
custom ID. on security rule options
defined in the Security
The resource may be blocked
Settings page.
based on site settings
incap-blocking • Blocked by security rules:
(security/WAF/DDoS), or based on
The session was blocked
security rules.
based on security rule
options defined in the WAF/

DDoS Settings page to block
a request, user, or IP.
• Captcha challenge: A
CAPTCHA challenge page
was displayed to the user.
• 2 Factor Authentication
challenge: The Imperva
Login Protect page was
displayed to the user.
The ID of the redirect rule.
The rule number is displayed next

incap-redirect rule 23369
to the rule name in the Cloud
Security Console's Delivery Rules
page.
Debug headers API

For details on the debug headers API, see Get XRay access link in Site Management API.

Read More
• Cache Settings
• Caching Duration


Delivery Settings
Delivery options help you optimize your content delivery and improve performance by providing faster loading of
your web pages.
Where do I find it?

3. On the sidebar, click CDN > Delivery.
In this topic:
• Compression
• Image Compression
• Network
• Redirection
• Custom Error Page
• Delivery Settings API
Compression
Compress files to shrink file size and reduce load time.
When this option is enabled, any textual resource,

such as Javascript, CSS and HTML, is compressed
Dynamically Compress JavaScript, CSS, and HTML
using Gzip as it is being transferred, and then
Files
unzipped within the browser. All modern browsers
support this feature.
Minification removes characters that are not

necessary for rendering the page, such as
whitespace and comments. This makes the files
Minify JavaScript smaller and therefore reduces their access time.
Minification has no impact on the functionality of
Minify CSS the Javascript, CSS, and HTML files.
Minify Static HTML
Content minification can be applied only to
cached Javascript, CSS, and HTML content. As such,
these options are disabled when caching is disabled.
Image Compression
Image compression can be applied only to cached JPEG and PNG images. As such, this option is disabled when
caching is disabled.

Compression reduces download time by reducing

Compress JPEG Images
the file size.
The image is rendered with progressively finer

resolution, potentially causing a pixelated effect
until the final image is rendered with no loss of
quality. This option reduces page load times and
Progressive Image Rendering
allows images to gradually load after the page is
rendered.
Applies to JPEG compression only.
A more aggressive method of compression is applied

with the goal of minimizing the image file size,
possibly impacting the final quality of the image
Aggressive Compression
displayed.
Applies to JPEG compression only.
Compression reduces download time by reducing

the file size.
Compress PNG Images
PNG compression removes only image meta-data
with no impact on quality.
Network
Maintain a set of idle TCP connections to the origin
server to eliminate the latency associated with
Pre-Pool TCP Connections
opening new connections for new requests
(TCP handshake).
TCP connections that are opened for a client request

remain open for a short time to handle additional
requests that may arrive.
Origin Connection Reuse
This setting must be enabled when using Dynamic
Content Acceleration. For details, see Dynamic
Content Acceleration.
By default, non-SNI clients are supported. Disable

Support Non-SNI Clients
this option to block non-SNI clients.

Take advantage of the performance and security

enhancements provided by HTTP/2 for your website.
Options:
• Do not support HTTP/2 (default)

• Support HTTP/2 from client to Imperva:
Enables HTTP/2 support for traffic between
supporting end-user (visitor) browsers and
Imperva.
• Non-supporting browsers can
connect via HTTP/1.0 or HTTP/1.1.
• Traffic from Imperva to the origin
server uses HTTP/1.1.
• Support HTTP/2 from client to Imperva and
from Imperva to origin server: Enables end-
to-end HTTP/2 support for traffic between end
user (visitor) browsers and Imperva, and
between Imperva and your origin server.
• Before enabling this option, make

sure that HTTP/2 is supported by
the origin server. Do not enable this
Enable HTTP/2 option if the origin server does not
support HTTP/2.
If your origin does not support

HTTP/2 and this option is enabled,
logs will show the error
REQ_ORIGIN_DOESNT_SUPPORT_H2.
• Imperva does not upgrade the

protocol to HTTP/2 when connecting
to the origin. For example, if the
client connection to Imperva uses
HTTP/1.1, the Imperva connection to
the origin server will also use HTTP/
1.1.
Note:
• You can only enable HTTP/2 support for sites

that have SSL support.
• Each time you upload a custom certificate to

Imperva for your website, this setting is reset
according to the account-level HTTP/2 default
settings, located in Account > Account

Management > Account Settings. For details,

see Account Settings.
• To enable/disable HTTP/2 support for all new

sites created in your account, see Account
Settings.
• For traffic between an end-user (visitor)

and Imperva: It is possible that a browser
requesting resources from multiple sites or
apps, all of which use a common root domain
and resolve to the same Imperva IP, will
automatically use the same connection
during the session. Depending on the client,
if any connection is opened to a website with
HTTP/2 support enabled, all additional
requests sent to sub-domains or the naked
domain will continue to use HTTP/2, even if
their HTTP/2 setting is disabled. Using HTTP/2
in most cases, even when disabled for the
specific site, is not problematic. If, however,
your website is experiencing any issues,
please contact Imperva Support for
assistance.
To redirect incoming requests, rewrite the port

number used to access the origin. Options include:
• Redirect the default port used for non-SSL

Port Forwarding traffic (80).
• Redirect the default port used for SSL traffic
(443). Available only when the website is
configured for SSL support in Website
Settings.
Redirection
Configure default redirection rules in order to improve the site’s performance and security level. Relevant HTTP
requests are then sent a 301 HTTP response code, which redirects them to the relevant URLs.
Option Description
Redirect from site's naked domain to site's full In most cases, we recommend enabling this option
domain in order to redirect all visitors to your site’s full
domain (which includes www).

Option Description
This option is displayed only for a naked domain.
Sites that require an HTTPS connection force all

HTTP requests to be redirected to HTTPS.
Redirect from HTTP to HTTPS
This option is displayed only for an SSL site.
Custom Error Page

You can provide a custom HTML error page for your website that will replace the default error page used by Imperva.
For configuration details, see Custom Error Pages.
Delivery Settings API
Configure delivery settings for your websites using the API.
For instructions on using the Delivery Settings API, see Delivery Settings API Definition.
Read More
• Cache Settings
• XRAY Debug Headers

Delivery Settings API Definition

Dynamic Content Acceleration

The Dynamic Content Acceleration service leverages the high-quality connectivity between Imperva network PoPs to
improve response time.
In this topic:
• How it works
• Configure Acceleration Settings
• No recommended Origin PoP
• Bypass the Origin PoP
• FAQ
How it works
When a client request is made for dynamic resources (resources that are not cached on the Imperva proxy), the
request must be sent on to your origin server. The Dynamic Content Acceleration service routes this traffic across our
network, between Imperva PoPs, resulting in improved performance.
Example:
Your site www.example.com is located in a data center in New York. Standard routing looks like this:
After you have enabled the Dynamic Content Acceleration Service, routing looks like this:

1. A request to www.example.com reaches the Imperva PoP located in Sydney ("Client PoP"). The proxy
determines that the content is dynamic and cannot be served from the cache. (A2 in the image)
2. The proxy routes the traffic to the Imperva PoP with best connectivity to the origin server for www.example.com
("Origin PoP"), located in New York. (B2)
3. The Origin PoP sends the request on to your origin server in New York (C2)
4. When your origin server sends a response, the Origin PoP receives it and sends it back to the Client PoP, which
then responds to the end user.
Round-trip time (RTT) improvements are based on:
• TCP optimization: Open PoP to PoP connections on our network are maintained and reused. This eliminates
TCP slow start, in which data transmission is increased gradually until the network's maximum capacity is
determined.
• Reduced latency: The latency resulting from the TLS handshake is reduced. By connecting to your origin server
from the PoP with the lowest RTT, time is saved on each of the four trips required to establish the connection.
Configure Acceleration Settings
To configure Dynamic Content Acceleration, configure the Origin PoP setting for each data center in each of your
protected websites. Select the PoP with the lowest RTT for your origin data center. The selected PoP is used by all
servers in the data center.
Note: Sites that don't use persistent connections (for example, using APIs or sending a Connection:close header) and
sites with connection pooling disabled cannot use the Origin PoP feature.
To activate the service:
1. Prerequisite: The Origin Connection Reuse setting on the Delivery Settings page must be enabled to support
Dynamic Content Acceleration. For details, see Delivery Settings.
2. On the Cloud Security Console sidebar, select Websites and navigate to Website Settings > Origin Servers.
3. For each data center, click Help me choose to view the recommended PoPs.

4. Select the Origin PoP with the lowest round-trip time.
To deactivate the service:
Select NONE for the Origin PoP setting.
For more details on origin server settings, see Load Balancing Settings.
No recommended Origin PoP
In some cases, the system does not provide a list of recommended PoPs. There are several possible reasons:
• There is no PoP that produces a round-trip time of less than 10 ms between the PoP and your origin server. In
this case, the Dynamic Content Acceleration service will not optimize your dynamic content.
• There are more than 4 PoPs with a round-trip time of less than 10 ms between the PoP and your origin server. In
this case, we suspect that your server is using anycast routing or is located behind another CDN. Selecting an
Origin PoP would not improve response time for your dynamic content.
• Your origin server cannot be reached. Check the configuration of your origin server and try again.

Bypass the Origin PoP

If Dynamic Content Acceleration is enabled for your site, you can use the origin_pop=disabled parameter to
bypass the functionality when sending a request to the site. You can use this to compare performance with and
without Dynamic Content Acceleration.
For example:
Via the Origin PoP: https://example.com/product/widget.html
Bypassing the Origin PoP: https://example.com/product/widget.html?origin_pop=disabled

FAQ
What is the expected impact on performance?
Performance improvements vary based on the geographic traffic distribution of a site, and on your origin server's
proximity to an Imperva PoP. Our tests have shown an average improvement of 30% in RTT latency.
Can opting-in have a negative impact on performance?
Yes. If the origin data center isn’t near an Imperva PoP (within <10ms RTT), activating the service may have a negative
impact on site performance.
Can rate limiting on the origin be an issue?
Yes. When Dynamic Content Acceleration is enabled, all traffic reaches the origin from a single PoP. If you have
implemented a rate limiting policy per IP on your origin server, the traffic reaching the origin may exceed the
threshold and result in dropped traffic.
Can I whitelist just the Origin PoP IPs instead of the Imperva ranges?
No. In the event of a connectivity issue between the origin PoP and your origin data center, Imperva automatically
reverts to the standard traffic flow and sends the traffic from the PoP closest to the client directly to your origin server.
The origin must be able to accept connections from any Imperva PoP, regardless of the Origin PoP setting.
Is there a change in the way that caching works?
No. Cacheable resources are returned from the PoP closest to the client. Only requests reaching the Origin PoP are
forwarded to the origin.
How can I check if Dynamic Content Acceleration is enabled?
Run XRAY Debug Headers and check for the incap-origin-pop header.


Load Balancing and Failover - Introduction

Imperva Load Balancer distributes user requests among origin data centers and/or servers in order to achieve
optimal performance and response time. In addition, it helps to ensure high availability in the case of a
malfunctioning server or data center by routing traffic to a healthy server.
• The availability of this feature depends on your subscription. For more information or to upgrade your plan,
contact an Imperva sales representative.
• If your site already has one or more load balancers installed, the load balancers’ IP addresses should be entered
as server IPs in the Imperva Load Balancing configuration. Imperva will treat each load balancer as if it were a
single server.
Benefits
• Server load balancing using layer 7 distribution algorithms
• Layer 7 (not DNS) based global server load balancing
• Site failover and disaster recovery scenarios
• Health monitoring and server failover
How Does Load Balancing Work?
Imperva’s Load Balancing is based on a network of secure reverse proxies deployed on our globally distributed CDN.
Web traffic that is routed through the Imperva network is terminated by those proxies. This allows Imperva to act as a
load balancer at the HTTP level by making sure requests are always routed to the origin server with the smallest load,
as well as executing geography-based routing decisions at the request level.
Load Balancing at the Request Level
Imperva uses Layer 7 based algorithms to make load balancing decisions at the HTTP request level. The Least Pending
HTTP Requests distribution method measures the number of pending HTTP requests for each origin server and sends
requests to the origin with the lowest number of pending requests. This method offers a very accurate assessment of
the origin servers’ loads and keeps the load evenly distributed among the origin servers.
Global Server Load Balancing (GSLB) at the Request Level
Imperva is quite unique in its use of Layer 7 based algorithms to make GSLB decisions at the HTTP request level (as
opposed to DNS-based GSLB). Layer 7 GSLB allows for quick (non TTL-reliant) responses to server and data center
malfunctions.
Site Failover and Disaster Recovery (DR) Scenarios
The Imperva Load Balancer can also play a major role in DR planning, acting as an automated solution for site failover
.
By using the health monitoring feature, Imperva immediately detects that the primary site is down and automatically
fails over to the standby site.

Health Monitoring and Server Failover
Imperva supports advanced health monitoring, constantly checking the origin servers to detect malfunctions and
allow immediate server/site failover.
Customers have complete control over the monitoring system. They can calibrate its sensitivity, configure specific
URLs to be monitored and define the exact responses that are expected to be received.
How To
• Configure Load Balancing
Read More
• Load Balancing Use Cases

Load Balancing Settings

View and configure your load balancing and failover settings.
Imperva Load Balancer distributes user requests among origin data centers and/or servers to achieve optimal
performance and response time. In addition, it helps to ensure high availability in the case of a malfunctioning server
or data center by routing traffic to a healthy server.
In this topic:
• Access the Origin Server settings

• Select an Origin Server configuration
• Single Origin Server
• Multiple Origin Servers (Single Data Center)
• Multiple Data Centers
• Resume traffic to active data centers
• Configure an Origin PoP for improved performance
• Load Balancing Settings API
Access the Origin Server settings
To open the Origin Server Settings, log in to your my.imperva.com account.

4. Click Origin Servers.
Select an Origin Server configuration
Define your site topology and configure the load balancing settings for the selected topology.
From the drop-down, select the option that reflects your site’s topology:
Note:
• You can only choose a topology that is supported by your current plan. You may want to upgrade your plan in
order to support a different topology or add more data centers/servers.
• You can configure servers to use external CNAMEs (such as Amazon Alias Names) instead of explicit IP addresses,
by entering the CNAME in any IP Address/CNAME field in the server settings.
• You can only enter one CNAME per data center.

Single Origin Server

The Single Origin Server topology is for a site with a single server. It is the default setting.
Add a server:
Imperva automatically detects your origin server’s IP address and populates the IP Address / CNAME field.
To change the origin server's IP address or CNAME, type the address, CNAME, or alias in the IP address / CNAME field.
Load Balancing and Failover features are not available when the site has only one server.
Multiple Origin Servers (Single Data Center)
To configure load balancing for this topology, add servers and set the load balancing attributes.
There are two modes you can use to determine how Imperva will access your origin servers.
Mode Description
(Default) – Each of the origin servers has a public IP

address.
Servers in Multiple Public IPs mode may be defined

as Active (primary server) or Standby (secondary
server).
Load balancing is implemented by first routing

requests to primary servers. If all primary servers are
Multiple Public IPs down or non-responsive, requests are routed to
secondary servers.
If the primary servers are down, requests are routed

to the secondary servers, without attempting to
connect to the primary servers.
Requests may be routed to secondary servers even

when monitoring identifies that a primary server is
up, but a TCP connection cannot be established.
Only the site’s router/firewall has a public IP

address. Each origin server is assigned to a different
port. Load balancing is implemented by updating
Single Public IP with Port Offsets the routing tables of the router/firewall with the
“port-internal IP” allocations. For details on
configuring some common firewalls to support this
option, see Port Forwarding Configuration.
In this section:

• Add a server in Multiple Public IPs mode

• Add a server in Single Public IP mode
• Set load balancing attributes
Add a server in Multiple Public IPs mode
Under Server IPs, click and configure the server options:
Option Description
IP Address / CNAME Enter the IP address, CNAME, or alias.
Select the server role for load balancing - Active
Server or Standby Server. Requests are routed to the
Mode Standby (secondary) server if routing to the Active
(primary) server fails or if the Active (primary) server
is down.
Enabled or disabled. The server is enabled by

Status
default.
Assign weights to determine the ratio of traffic

Weight (%) distribution between the servers. For details, see
Weighted Load Balancing.
After the server is created, you can click Edit to edit the server's options.
Add a server in Single Public IP mode
Under Server IPs, click Use single IP with port offsets.
Enter the following values:
Option Description
The single IP address through which the site will be
IP Address
accessed.
Standby IP Address (Optional) The IP address of an additional server.
Number of Active Servers The number of origin servers in the data center.
The port ranges assigned by Imperva to your origin
servers for HTTP or HTTPS traffic. Each origin server
HTTP or HTTPS Port Ranges
is assigned one of these ports. You must route these
port allocations to your origin servers in your router/

Option Description
firewall by configuring the IP tables. For details, see
Port Forwarding Configuration.
Set load balancing attributes
• Mode
• Persistence
Mode: Select a load balancing algorithm to determine the origin server to which the next request will be routed.
Customers that have not purchased the Load Balancing add-on and use the Single Data Center with Multiple Origin
Servers; All Active topology can use the Least Pending Requests load balancing algorithm only.
Option Description
(Default/Recommended option) The next request is
routed to the origin server with the smallest number
of pending HTTP requests. This algorithm is the
most accurate in terms of balancing the load
between the different destination IPs. The impact of
Least Pending Requests pending requests on load is much more direct than
that of open connections, hence it usually serves as
a better criterion for load balancing. This algorithm,
similarly to the previous two, does not support
“Session Stickiness” and therefore may refer clients
to different servers on each request.
The next request is routed to the origin server with
the smallest number of open TCP connections. This
algorithm is better in terms of balancing the load
between the different destination IPs. As opposed to
the previous two algorithms, this algorithm takes
Least Open Connections
into account the actual load (in terms of open
connections) of the different destination IPs when
performing routing decisions. On the downside,
clients may be referred to a different server on each
request.
This rudimentary, simple and effective method is
based on a hashing function that maps the IP
address of the request’s source to one of the origin
servers. Packets that arrive from a specific source IP
are sent to a specific origin server. Since many
Source IP Hash
servers implement session state independently,
clients will always be connected to the same server.
On large sites, load is distributed fairly well using
this method. Destination IP availability is, of course,
evaluated prior to packet allocation.
The next request is routed randomly to one of the
Random
origin servers. This is the most basic algorithm and

Option Description
the one most often used. On large sites load will be
distributed fairly well, though on smaller sites load
may not be balanced well. As opposed to Source IP
Hash, clients may be referred to a different server on
each request.
Load is distributed according to a user-defined ratio.
Weighted
For details, see Weighted Load Balancing.
Persistence: Each user session will be served by a single origin server. Use this option if the session must maintain
stateful information. The load balancing algorithm will only be applied to the first request of each user session and
Imperva will maintain user session continuity by setting a dedicated session cookie in the user’s browser.
Multiple Data Centers
Select this topology setting if you have multiple origin servers in multiple data centers.
You can configure up to 40 data centers per site.
To configure the multiple data center topology:
• Configure Global Settings

• Configure Failover Attributes
• Add a data center
• Add a server to a data center
Configure Global Settings
Configure the overall load balancing settings for the topology.
• Global Server Load Balancing Mode

• Persistence
Global Server Load Balancing Mode: This option determines how user requests are routed to data centers.
Global Server Load Balancing settings are relevant only if 2 or more active data centers are configured.
Option Description
The average connection times between each
Imperva PoP and each of the site’s data centers are
sampled and updated periodically. When this mode
Best Connection Time
is selected, the PoP will route requests to the data
center that currently provides the shortest
connection time.
Each geographical location is mapped to a data

Geo-Targeting Required
center. This mode is useful when local regulations
require that sites be served from a certain location.

Option Description
Note:
• You must map each region to at least one data

center.
• To you must assign each data center to a

specific geo-location or to the Rest of the
World option to cover all other locations.
• If one of the geo-targeted data centers is

down, requests directed to that data center
will not be re-routed and will fail.
• If a custom delivery rule with the Forward to

Data Center action is defined for the website,
only requests from the same geo-location that
is assigned to the target data center are
forwarded. Mismatched requests will fail. For
This is similar to Geo-Targeting Required, except in

the case where one of the geo-targeted data centers
is down. With this option, an attempt will be made
to re-route requests directed to the failed data
Geo-Targeting Preferred center to other active data centers. The alternative
data center is chosen by applying the Best
Connection Time algorithm. This mode is useful
when the site produces different content for
different locations.
Load is distributed according to a user-defined ratio.
Weighted
For details, see Weighted Load Balancing.
If one of the Geo-Targeting options is selected, you must map each region to a single data center. Each continent is a
region, and the United States is divided into U.S. East and U.S. West.

To map regions to data centers:
1. Click Add Geography. A new row is added for the new region.
2. In the Geographic Region drop-down, select the region.
3. In the Data Center drop-down, select the data center to which the region’s requests will be routed.
4. Repeat steps (1) to (3) for each region you want to specify. Note that each region can only be mapped to a single
data center, and once a region is mapped, it will not be available when adding another mapping.
5. If not all regions were mapped, select the data center that will handle the requests for the Rest of the World.
Persistence: Each user session will be served by a single origin server. Use this option if the session must maintain
stateful information. The load balancing algorithm will only be applied to the first request of each user session and
Imperva will maintain user session continuity by setting a dedicated session cookie in the user’s browser
Configure Failover Attributes
These attributes determine when a data center will be considered down, which standby data center to activate in such
a case, and optionally a URL to access in order to activate the standby data center.
Option Description
The name of the standby data center.
• If this attribute is set to None, failover is

disabled.
• If it is set to one of the defined data centers,
Standby DC Name requests will be routed to the standby DC if all
other DCs are down.
Note: The standby data center cannot be one of the

geo-targeted data centers, and vice versa. In
addition, the standby data center must be enabled.
If a disabled data center is chosen as the standby,

Option Description
the Standby DC Name will be changed back to None
when the settings are saved.
Each Imperva PoP monitors each data center’s

health, according to the rate of errors received from
the data center. Each PoP may produce a different
assessment, depending on the types of requests it
receives (some of which could be invalid). This
attribute determines the number of PoPs that must
produce a “failed” assessment for the data center to
be considered down. This can be one of the
Monitors required to decide on failover
following values:
• One – only one “failed” assessment is required

• More than one – more than one “failed”
assessment is required
• Most – the majority of assessments must be
“failed”
• All - all assessments must be “failed”
Optional. If this value is entered, the URL will be

accessed when Imperva performs a failover.
(Imperva decides automatically when to failover
based on our monitoring. For more details, see Load
Standby DC Kickstart URL Balancing Monitoring Settings.)
You must implement the URL as a “kickstart”

function that triggers a designated action on your
webserver when failover has occurred.
If a user name and password are required in order to

Credentials for Kickstart URL (if required)
access the Kickstart URL, enter them in this field.
A data center must have at least this number of
active servers for it to be considered “up”
Minimum number of servers for "DC UP" (operational). To learn more about how a server’s
status is determined, see Load Balancing Monitoring
Settings.
Add a data center
Add data centers and configure the load balancing mode for each.
1. Click to add a data center.

2. Select Multiple Public IPs mode or Single Public IP mode for accessing servers in the new data center. For
details on these options, see Multiple Origin Servers (Single Data Center).
3. Fill in the details:
Name Enter a name for the data center.
Verify that the Enabled option is checked.
You can temporarily disable a data center, by

clearing the Enabled option, without deleting its
configuration. This can be useful, for example,
Enabled
when you need to perform maintenance tasks in
the data center.
Note: There must be at least one enabled data

center per site.
When selected, the data center is only used for

requests according to a forwarding rule defined in
the Delivery Rules page. For more details, see
Support only forward rules Create Rules.
Note: There must be at least one data center that

is not configured for forward rules.
Assign weights to determine the ratio of traffic

Weight (%) distribution between the data centers. For details,
see Weighted Load Balancing.
Select a load balancing algorithm to determine
the origin server to which the next request will be
Mode
routed. For details, see Set load balancing
attributes.
Add a server to a data center
When working in Multiple Public IPs mode, click to add additional servers to the data center. For more
details on configuring the server, see Multiple Origin Servers (Single Data Center).
Resume traffic to active data centers
If you have a multi-data center topology configured for Imperva load balancing, and all of your active data centers go
down, traffic is rerouted to your standby data center.
When at least one active data center is back up, the Resume Traffic to Active DCs button is displayed, enabling you to
reroute your traffic back to the active data center. Traffic does not revert automatically to your active data centers.

Configure an Origin PoP for improved performance

The Dynamic Content Acceleration service leverages the high-quality connectivity between Imperva network PoPs to
improve response time. To configure the service, select the PoP with the lowest RTT for your origin data center.
For more details, see Dynamic Content Acceleration.

Load Balancing Settings API
Configure load balancing and failover settings for your websites. using the API.
For instructions on using the Load Balancing Settings API, see Load Balancing Settings API Definition.
Read More
• Load Balancing and Failover - Introduction
• Load Balancing Monitoring Settings
• Load Balancing Use Cases

Load Balancing Settings API Definition

Weighted Load Balancing

This topic describes how to assign weights to your data centers and origin servers to gain more precise control over
the distribution of load between them.
In this topic:
• Overview
• Guidelines
• How to configure weighted load balancing
• Example
• API
Overview
The weights you assign determine the ratio of traffic distribution.
If a data center or server goes down or is taken offline, the traffic is redistributed according to the initial ratio.
For example, suppose you have 3 data centers configured for a website: DC1, DC2, and DC3, and you define a
distribution of 50:30:20 for them, respectively. If DC1 is down, DC2 gets 60% of the load, and DC3 gets 40%.
The same principle applies to the ratio set for servers within a data center.
Guidelines
You can define a weight distribution for all the data centers configured for your site, and also for the servers within a
data center.
Assigning weights to data centers
For a site with multiple data centers:
• Weighting is supported only for sites configured with the Weighted global server load balancing mode.
• Define weights for active, enabled data centers only. Weights of enabled data centers must sum up to 100.
• Weighting is not supported on a standby data center
• Weighting is not supported on a data center that supports only forward rules.
Assigning weights to servers in a data center
• Weighting is supported only for data centers configured with the Weighted mode.

• Define weights for enabled servers only.

• Define weighting separately for active and standby servers:
• Weights of active servers must sum up to 100
• Weights of standby servers must sum up to 100
How to configure weighted load balancing
Weights are defined in the website's Origin Servers settings. For details, see Load Balancing Settings.
For multiple data centers:
1. Set the Global Server Load Balancing mode to Weighted.

2. Set a weight for each active, enabled data center, adding up to 100.
For multiple servers in a data center:
1. Set a weight for each active server in a DC, adding up to 100.

2. Set a weight for each standby server in a DC, adding up to 100.
Example
In this example, there are 3 data centers configured for the website: DC1, DC2, and DC3.
• The weight distribution for the data centers is 25:25:50 respectively.

• DC1 is configured with a single public IP with port offsets. Load is distributed evenly between its 5 servers.
• DC2 has one active server that handles 100% of the data center's load, and 2 standby servers that are weighted
80:20.
• DC3 has two active servers, weighted 60:40.


API
You can also configure weighted load balancing for a website via the API.
The default weight when you add a new data center or server is 0.
To configure weighting, use the POST methods for editing data centers or servers.
For details, see Load Balancing Settings API Definition.

Load Balancing Monitoring Settings

Configure settings to determine when origin servers should be considered “up” or “down” (active or inactive) by the
Imperva Load Balancer. Select which failure scenarios you want to produce alarm messages, and how to send them.
Monitoring works as follows:
• The monitoring for ‘down’ status is passive, using real user monitoring. It is based on actual requests from
clients to the server and not on active health check requests by the Imperva proxies.
• The monitoring for ‘up’ status is active. When a server is identified as 'down', our proxies start to actively send
requests to the server to verify its availability. When the server becomes available, the server status is
considered 'up'.
Note: The proxy always sends active monitoring requests to the origin server that is defined for the site, using
the site’s Host header. (Origin servers are defined for the site in the Cloud Security Console in Application >
Websites > <select a website> > Website Settings > Origin Servers.)
If there are custom delivery rules defined for the site, such as forward or rewrite rules, they are not run.
Therefore, the default origin server itself must be able to receive requests sent by our active monitoring
mechanism so that we can confirm server availability.
To define load balancing settings for your origin servers, see Load Balancing Settings.
In this topic:
• Access the Monitoring Settings

• Set monitoring parameters
• Set failed request criteria
• Verify “Down” / ”Up” status
• Define email alert settings
• Load Balancing Monitoring Settings API
Access the Monitoring Settings

3. On the sidebar, click Origin and Network > Monitoring.
Set monitoring parameters
The following parameters define when an origin server is considered down by the Load Balancing mechanism:
Parameters Description
If the percentage of failed requests is above this
Percentage of failed requests to mark server “Down” threshold for the defined period of time and for the
minimum defined number of sampled requests, the

origin server is considered “down”. The types of
errors that are considered failed requests are
defined in the Failed Request Criteria section. For
more details, see Set failed request criteria.
The configurable time period during which the

Mark server as “Down” if failed request percentage is percentage of failed requests is measured. The
above threshold for the last [X] smaller this period is, the more sensitive the system
is to short periods of failure.
Set failed request criteria

The following parameters define what is considered a failed request:
If a request times out within this configurable
HTTP request timeout
period, it is considered a failed request.
Specific HTTP response error codes or patterns that
are to be counted as request failures. The codes can
be specific errors such as “401”, or patterns with
wildcards such as “4xx”. The codes and patterns
HTTP response error codes to be treated as down
should be separated by commas, or dashes to define
ranges. For example: “401, 404, 407, 5xx” or
“501-599” (to define all values between 501 and
599).
Note:
• TCP timeouts cause the server to be considered "down". They are not counted as regular failed requests.
• All other TCP connection errors are considered failed requests by default.
Verify “Down” / ”Up” status
This section contains parameters for verifying that an origin server is down after failed user requests are identified,
and for determining when an origin server is back up after a failure.
The parameters include:
By default, only the regular site traffic (generated by
users) is monitored for failed requests. If this
parameter is enabled (the default setting) and
Imperva determines that an origin server is down
Use verification checks to mark server as “Down”
according to failed request criteria, it will initiate
another request and test its response to verify that
the origin server is down. The request is defined by
the “URL for Monitoring” parameter, and its

expected response is defined by the "Expected
receive string" parameter.
This is a URL suffix (without the http:// prefix) that

refers to your site. If this parameter is left with the
default value of “/”, the site’s root will be accessed.
Alternatively, you can configure this parameter to
refer to a specific URL to be called in order to test an
origin server’s health. In both cases, the response is
URL for monitoring tested for success according to the rule defined in
the “Expected receive string” parameter.
Note: Monitoring is performed on HTTP port 80 by

default. For websites that support SSL, monitoring is
performed on HTTPS port 443. To request
monitoring on a different port, contact Support.
If this parameter's value is an empty string, any

response, except for the codes defined in the HTTP
response error codes to be treated as Down
Expected receive string parameter, will be considered successful. If the value
is non-empty, then the defined value must appear
within the response string for the response to be
considered successful.
After an origin server is identified as down, Imperva
periodically tests it to determine whether it has
Interval for “Up” verification
recovered, according to the frequency defined in this
parameter.
Every time an origin server is tested to determine
whether it’s back up, the test is retried the number
Retries for “Up” verification
of times that appear in this field. If all tests are
successful, the origin server is considered “up”.
Define email alert settings
The email alert settings determine which failure scenarios will produce alarm messages, and how the alarm messages
will be sent.
The parameters include:
Select the scenarios that will produce alarm

messages:
Scenarios
• Failover to Standby DC: (selected by default)
An alarm is sent when Imperva fails over to the
standby data center.

• DC Down: (selected by default) An alarm is
sent when a data center is determined to be
down and fails over to another active data
center.
• Server Down: An alarm is sent when an origin
server is determined to be down.
Each Imperva PoP monitors each data center’s

health, according to the rate of errors received from
the data center. Each PoP may produce a different
assessment, depending on the types of requests it
receives (some of which could be invalid). This
attribute determines the number of PoPs that must
produce a “failed” assessment for the data center to
be considered “down”. This can be one of the
Monitors required to report server/DC as down:
following values:
• One: Only one “failed” assessment is required.

• More than one: More than one “failed”
assessment is required.
• Most: (Default) The majority of assessments
must be “failed”.
• All: All assessments must be “failed”.
Load Balancing Monitoring Settings API

Configure load balancing monitoring settings for your websites. using the API.
For instructions on using the Load Balancing Monitoring Settings API, see Load Balancing Monitoring Settings API
Definition.
Read More
• Load Balancing Settings

Load Balancing Monitoring Settings API Definition

Load Balancing Use Cases

This section describes some typical data center topology use cases, and how to configure Imperva Load Balancer
for each case.
These are the use cases described:
• Use Case 1: Single Origin Server

• Use Case 2: Single Data Center with Multiple Origin Servers – All Active
• Use Case 3: Single Data Center with Multiple Origin Servers – Two ISPs
• Use Case 4: Single Data Center with Multiple Origin Servers – Active & Standby
• Use Case 5: Multiple Data Centers with Standby Data Center
• Use Case 6: Multiple Data Centers for Performance Purposes
• Use Case 7: Multiple Data Centers for Localized Content
• Use Case 8: Multiple Data Centers due to Regulation
Use Case 1: Single Origin Server
Description: The Single Origin Server topology is the default configuration, and the simplest to configure. When you
add your site as an Imperva user, your server’s IP address is added automatically to the Server Settings. If necessary,
you can edit the server’s IP address or CNAME at any time.
Obviously, a single server topology cannot support load balancing or failover features.
Single Origin Server: Server is Active

Single Origin Server: No Service when Server is Down
Use Case 2: Single Data Center with Multiple Origin Servers – All Active
Description: If you have a single data center with multiple servers, select the Multiple Origin Servers (Single Data
Center) topology setting. If all servers should be active at all times, select the Active Server setting for each server that
you add.
You can configure each server to have a separate public IP address, or you can configure only one server with a public
IP address, and route traffic to the other servers using port forwarding.
If one or more servers are identified as down, traffic is routed to the remaining active servers
Multiple Active Servers: Load Balancing among All Servers

Multiple Active Servers: Some Servers Down - Load Balancing among Functioning Servers
Availability: Purchase of the Load Balancing add-on is required for setups of three or more servers.
Use Case 3: Single Data Center with Multiple Origin Servers – Two ISPs
Description: The Active and Standby server modes can be used when you have two Internet Service Providers (ISPs) -
one used for normal operations and the other (often a more expensive one) only used as a standby provider.
In this use case, if all servers have public IP addresses, add each server twice: once as Active Server (primary) with an
IP address from the primary ISP, and the second time as Standby Server (secondary) with an IP address from the
“standby” ISP.
If you are using port forwarding, enter the IP address from the primary ISP in the IP Address field, and enter the IP
address from the “standby” ISP in the Standby IP Address field.

Dual ISPs: Active Identities are Used when Primary ISP is Active
Dual ISPs: Standby Identities Used when Primary ISP is Down
Availability: Purchase of the Load Balancing add-on is required.

Use Case 4: Single Data Center with Multiple Origin Servers – Active & Standby
Description: You may have a single data center with multiple servers, and want some of the servers to act as standby
servers, only receiving traffic when active servers are down or non-responsive.
To support this use case, select the Multiple Origin Servers (Single Data Center) topology setting, and define some
servers as Active Server (primary) and some as Standby Server (secondary). Normally, traffic is load balanced only
among the primary servers. If routing to all primary servers fails, traffic is load balanced among the secondary servers.
Requests may be routed to the secondary server even when monitoring identifies that the primary server is up, but a
TCP connection cannot be established.
If all servers have public IP addresses, there are no constraints on the number of active and standby servers. In the
case of port forwarding, active/standby mode can only be supported if there are equal numbers of active and standby
servers.
Active (Primary) and Standby (Secondary) Servers: Standby Servers Not Used Unless Routing to All Active Servers Fails
Active (Primary) and Standby (Secondary) Servers: Standby Servers Used when Routing to All Active Servers Fails

Use Case 5: Multiple Data Centers with Standby Data Center
Description: You may maintain one or more active data centers and one standby data center, which should only serve
site traffic if all active data centers are down.
To support this use case, select the Multiple Data Centers topology setting. Define each data center in the Imperva
configuration, and enter the standby data center’s name in the Standby DC Name parameter of the Failover Attributes
section.

Standby Data Center: Standby Data Center Not Used Unless All Active Data Centers are Down

Standby Data Center: Standby Data Center Used When All Active Data Centers are Down
Use Case 6: Multiple Data Centers for Performance Purposes
Description: There can be different reasons for maintaining multiple data centers to serve a single website. One
reason is to provide better performance by serving users from data centers that are geographically close to their
location.
To support this use case, select the Multiple Data Centers topology setting, and select the Best Connection Time mode
(the default). This will cause the load balancing mechanism to serve each user from the data center that provides the
shortest response time to the specific user

Performance: Users are Served from Data Center Providing Best Connection Time

Performance: If Data Center Down, Users Served from Active Data Center with Best Connection Time
Use Case 7: Multiple Data Centers for Localized Content
Description: Some websites provide localized content, depending on the location from which the site is accessed. For
instance, users from the West Coast of the US might see different articles or advertisements than users from the East
Coast.
To support this use case, select the Multiple Data Centers topology setting, and select the Geo-Targeting Preferred
mode. This means that the load balancing mechanism will serve users from the data center that is geographically
closest to them, as long as that data center is active. However, if the closest data center is down, user requests will be
served from other active data centers, according to the Best Connection Time mode.
To work in Geo-Targeting Preferred mode, you must assign each geographical area to a specific data center. The last
area assigned to a data center will always be Rest of the World. This "catch all" data center will handle requests from
all areas not explicitly assigned to another data center

Geo-Targeting Preferred: Users Served from Targeted Data Center

Geo-Targeting Preferred: If Data Center Down, Users Served from Active Data Center with Best Connection Time
Use Case 8: Multiple Data Centers due to Regulation
Description: Some websites maintain multiple data centers to comply with local laws and regulations that stipulate
that users from certain areas must only be served locally.
To support this use case, select the Multiple Data Centers topology setting, and select the Geo-Targeting Required
mode. This means that the load balancing mechanism will serve users from the data center that is assigned to them. If
that data center is down, they will not receive service since a standby data center in another geographical region is not
a legal option. To work in Geo-Targeting Required mode, you must assign each geographical area to a specific data
center. The last area assigned to a data center will always be Rest of the World. This "catch all" data center will handle
requests from all areas not explicitly assigned to another data center.

Geo-Targeting Required: Users Served from Targeted Data Center

Geo-Targeting Required: If Data Center Down, No Service for Targeted Area
Read More


Port Forwarding Configuration

Using the Single Public IP with Port Offsets mode in Imperva Load Balancing enables your site to use a single public IP
address, while routing requests to several servers within your site according to the port specified in the request.
In order to work in Single Public IP with Port Offsets mode, you will need to configure your firewall to work with port
forwarding, and add the appropriate access and mapping rules to route requests coming through Imperva to the
correct server within your site. This appendix describes how to do this for several commonly used firewalls.
In this topic:
• Configuring Port Forwarding for the FortiGate Firewall

• Configuring Port Forwarding for the Cisco ASA Firewall
• Configuring Port Forwarding for the Juniper SRX Firewall
Configuring Port Forwarding for the FortiGate Firewall
To configure the FortiGate firewall to work in port forwarding mode with Imperva Load Balancing, perform the
following steps.
To configure virtual IP objects for your internal site servers:
1. Access the FortiGate firewall configuration application through a browser.

2. In the Firewall Objects tab, select Virtual IP under the Virtual IP group.
3. Click Create New. A window opens in which you can enter details for a virtual IP address for an internal site
server.

4. In the Name field, enter a name for the virtual IP object.

5. In the External Interface field, select the appropriate external interface.
6. In the External IP Address/Range field, enter the external public IP address.
7. In the Mapped IP Address/Range, enter the IP address of the internal web server.
8. Check the Port Forwarding checkbox.
9. In the Protocol field, select the appropriate protocol (should be TCP).
10. In the External Service Port field, enter the port to which Imperva will refer.
11. In the Map to Port field, enter the internal port to which requests to the specified external port will be routed.
12. Click OK.
13. Repeat steps (3)-(12) for each internal server.
Note: If you have not already done so, add an Address object for each internal server in the FortiGate Firewall
Objects\Address page.
To add a policy rule that allows Imperva to access your servers:
1. Open the FortiGate Policy page and click Create New. A window opens in which you can enter details for the new
policy rule.

2. In the Source Address field, click to add Imperva prefixes.

3. In the Destination Address field, click to add an IP address for an internal VIP. Repeat for each internal VIP.
4. In the Schedule field, select "always".
5. In the Service field, select the appropriate protocol (usually HTTP or HTTPS).
6. In the Action field, select "ACCEPT".
7. Click OK.
Configuring Port Forwarding for the Cisco ASA Firewall
You can configure port forwarding for the Cisco ASA firewall using either the ASA Command Line Interface (CLI) or the
Adaptive Security Device Manager UI application. In both cases you must perform the following actions:
• Allow Inside users to access the Internet.

• Enable the Inside web server to provide HTTP services to the Internet.
• Allow Outside users to access your web server.
Following are examples of how to configure port forwarding for the Cisco ASA firewall.
Note: Replace the IP addresses and subnets in the examples with values that are appropriate for your network.
To configure port forwarding for the Cisco ASA Firewall using the CLI:
1. Enter the ASA CLI.
2. Create objects for your Inside network.
LAB-ASA5505-01# conf t

LAB-ASA5505-01# object network INSIDE-SUBNET
LAB-ASA5505-01# subnet 172.20.10.0 255.255.255.0
LAB-ASA5505-01# exit
3. Create objects for your web server.
LAB-ASA5505-01# object network WWW-SERVER
LAB-ASA5505-01# host 172.20.10.100
LAB-ASA5505-01# exit
4. Configure Network Address Translation (NAT) so your Inside users can browse the web.
LAB-ASA5505-01# object network INSIDE-SUBNET
LAB-ASA5505-01# nat (inside,outside) dynamic interface
5. Create a static NAT entry for your web server to your (single) public IP address and configure static NAT with port
forwarding.
LAB-ASA5505-01# object network WWW-SERVER
LAB-ASA5505-01# nat (inside,outside) static interface service tcp 80 80
6. Configure an access list to allow Outside traffic to visit port 80 (HTTP) as your Outside interface.
LAB-ASA5505-01# access-list Outside_access_in extended permit tcp any object WWW-SERVER eq 80
LAB-ASA5505-01# access-group Outside_access_in in interface Outside
7. Verify your NAT configuration.
LAB-ASA5505-01# show nat
Auto NAT Policies (Section 2)
8. 1 (Inside) to (Outside) source static WWW-SERVER interface service tcp www www
translate_hits = 0, untranslate_hits = 2
9. (Inside) to (Outside) source dynamic INSIDE-SUBNET interface
translate_hits = 6, untranslate_hits = 0
10. Examine the hit count in the access list and verify that it is increasing.
LAB-ASA5505-01# sh access-list

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list Outside_access_in; 2 elements; name hash: 0xe796c137
access-list Outside_access_in line 1 extended permit icmp any any echo-reply (hitcnt=0) 0x24ee277f
access-list Outside_access_in line 2 extended permit tcp any object WWW-SERVER eq www (hitcnt=4)
0xb7fcf341
access-list Outside_access_in line 2 extended permit tcp any host 172.20.10.100 eq www (hitcnt=4) 0xb7fcf341
To configure port forwarding for the Cisco ASA Firewall Using the ASDM UI application:
1. Launch the ASDM application.
2. Click New object to create a new NAT object and click on the NAT drop-down.
3. Enable Add Automatic Address Translation Rules and select Static as the type. In theTranslated Addr drop-
down, select Outside.
4. Click the Advanced button.

5. Select the Source Interface and the Destination Interface.
6. In the Service section, in the Protocol drop-down, select "tcp".
7. Enter the Real Port and Mapped Port values (for example, set both values to www, http or 80).
8. Click OK.

Configuring Port Forwarding for the Juniper SRX Firewall

To configure port forwarding for the Juniper SRX firewall, you must perform a NAT redirect in the Juniper CLI. This
section describes an example of how to do this for addresses and ports of two origin servers (the addresses and ports
on the left are configured in Imperva and the addresses and ports on the right are the internal IPs and ports used
within your network):
172.16.1.2:22 --> 192.168.1.5:2222
172.16.1.2:3389 --> 192.168.1.6:3389
To configure port forwarding for the Juniper SRX firewall:
1. Configure the real addresses of the servers using address-book entries.
set security zones security-zone trust address-book address Server1 192.168.1.5/32
set security zones security-zone trust address-book address Server2 192.168.1.6/32
2. Define the pre-translated ports.
set applications aplication SSH-DNAT protocol tcp

set applications application SSH-DNAT destination-port 2222
set applications application RDP protocol tcp
set applications application RDP destination-port 3389
3. Define each server and port. (These settings relate to the real IP and port configured on the server.)
set security nat destination pool dnat-192_168_1_5m32 address 192.168.1.5/32
set security nat destination pool dnat-192_168_1_5m32 address port 22
set security nat destination pool dnat-192_168_1_6m32 address 192.168.1.6/32
set security nat destination pool dnat-192_168_1_6m32 address port 3389
4. Configure the NAT policy (specify the NAT pool to which traffic should be translated). This defines both the
destination IP and destination port address.
set security nat destination rule-set dst-nat from zone untrust
5. Configure the port forwarding rule for the first origin server.
set security nat destination rule-set dst-nat rule rule1 match destination-address 172.16.1.2/32
set security nat destination rule-set dst-nat rule rule1 match destination-port 2222
set security nat destination rule-set dst-nat rule rule1 then destination-nat pool dnat-192_168_1_5m32
6. Configure the port forwarding rule for the second origin server.
set security nat destination rule-set dst-nat rule rule2 match destination-address 172.16.1.2/32
set security nat destination rule-set dst-nat rule rule2 match destination-port 3389
set security nat destination rule-set dst-nat rule rule2 then destination-nat pool dnat-192_168_1_6m32
7. Configure the security policy. Note that the internal (real) IP address and port of the server are defined within
the policy.
set security policies from-zone untrust to-zone trust policy untrust-to-trust1 match source-address any
set security policies from-zone untrust to-zone trust policy untrust-to-trust1 match destination-address server1
set security policies from-zone untrust to-zone trust policy untrust-to-trust1 match application SSH
set security policies from-zone untrust to-zone trust policy untrust-to-trust1 then permit
set security policies from-zone untrust to-zone trust policy untrust-to-trust2 match source-address any
set security policies from-zone untrust to-zone trust policy untrust-to-trust2 match destination-address server2

set security policies from-zone untrust to-zone trust policy untrust-to-trust2 match application RDP
set security policies from-zone untrust to-zone trust policy untrust-to-trust2 then permit
Read More


Waiting Rooms
Control the traffic to your website during peak periods when the origin server is unable to handle the load. while
providing a seamless experience to your customers.
Route your website visitors to a virtual waiting room when their requests can't be handled immediately.
In this topic:
• Overview
• Open the waiting room page
• Add/edit a waiting room
• Set activation thresholds
• Customize the waiting room visitor page
• View your waiting rooms
• Track performance statistics
• Waiting Room API
Overview
During peak traffic times, or when there are unexpected spikes in traffic to your website, requests can exceed your
website's capacity and can overload your servers. To prevent loss of business due to server crashes, poor
performance, or the inability to handle the volume, you can configure a waiting room.
A waiting room places your customers in a virtual queue and create a positive user experience. Instead of being
greeted with a "server unavailable" message, customers can see their position in line, and when their turn arrives,
they are redirected to the requested page. While waiting in line, the customer's request are not transferred to the
origin server, preventing overload.

Note:
• All traffic is inspected by the Imperva security mechanism before being routed to the waiting room.
• You can configure up to 5 waiting rooms per website.
• One waiting room is included with your plan. Additional waiting room licenses are available as an add-on to the
Cloud WAF service. For details, contact your Imperva Sales Representative.
• When browsing from a mobile device, users must keep the waiting room page open to remain in line.
Audit Trail
The following events are logged in the audit trail for your account:
• Waiting room added
• Waiting room updated

• Waiting room deleted

Open the waiting room page
To open the Waiting Rooms page, log in to your my.imperva.com account.

3. On the sidebar, click CDN > Waiting Rooms.
Add/edit a waiting room
On the Waiting Rooms page:
• Click Add to create a new waiting room.
• Click a waiting room name to edit the waiting room.
Option Description
Name Add a descriptive name for your waiting room.
Optionally, add a description of your waiting room

Description
to help easily identify its purpose.
Set the triggering points to start routing visitors to

the waiting room.
For more details, see Set activation thresholds.

Activation Thresholds
Note: If there are conditions defined for the waiting
room, the threshold takes into account only sessions
that match the conditions. See below for more
details on conditions.
Create a rule to define with more granular control

when the waiting room is activated.
• Only requests matching the conditions are

counted toward the thresholds.
Conditions
• If no condition is defined, the waiting room
applies to the entire website.
For example, you can create a condition to apply the

waiting room to a subset of your website, instead of

Option Description
to the entire website, such as: URL contains "^/
ShoppingCart".
You can also use conditions to create waiting rooms

for different visitor groups, such as visitors from
different countries. For example, CountryCode ==
GB.
Fill in the following filter conditions and then click

Add.
• If: Select the part of the request or session to

which the filter applies. For descriptions of the
supported filter parameters, see Rule Filter
Parameters. (Only parameters listed in the If
drop-down on the Waiting Room page are
supported for waiting rooms.)
• Operator: Defines how the filter value is

matched.
• Value: The value to be matched.

Validate
automatically whenever you save a waiting room.
Choose what to do when good or unknown bots are

trying to access your website during peak time.
Any bot that is not blocked by the Cloud WAF is

considered legitimate.
This setting applies to bots classified only by the

Imperva Cloud WAF and not according to Imperva
Advanced Bot Protection. For more details, see
Legitimate Bot Handling
This setting applies only when the activation
threshold has been passed and visitors are being
sent to the queue.
Available options:
• Wait in line: Bots wait in line like other clients.

When the bot's turn arrives, if the bot resends
the request it is forwarded to the requested
page. It is not forwarded automatically like
browser requests.

Option Description
• Bypass: Bots bypass the waiting room. Use
this option if you are confident that legitimate
bot activity will not affect your origin server
performance.
• Block: Bots are blocked from your website.
Use this option if you want to prioritize human
visitors over bots during peak time.
Display the default waiting room page to your

website visitors, or customize the page to maintain
your brand consistency.
HTML Customization
For details, see Customize the waiting room visitor
page.
The waiting room must be enabled in order to start

sending visitors to the queue when the activation
threshold is passed.
Status
When the waiting room is disabled, the functionality
is suspended. Visitors are not sent to the queue,
even if the threshold is passed.
Set activation thresholds

Set the triggering points to start routing visitors to the waiting room.
There are two threshold options.
• The total number of active users on the site
• The rate of new incoming users per minute
When a threshold is passed, all new incoming users are placed in a queue. Visitors in the queue are then allowed entry
to the website on a FIFO basis, at the rate defined by the threshold values.
New users/sessions
A new incoming user is defined as a user/session that is trying to access the website for the first time (within the
scope of any conditions set for the waiting room) , before it is assigned a place in the waiting room queue. There are
two types of sessions:
• Cookie-based (human visitor): When the requesting client supports cookies, all requests with the same session
cookie are considered a single user.
• Cookieless: When the requesting client does not support cookies, we identify a user according to IP address.

Set the threshold options
You must configure at least one of the options, or you can configure both.
If one threshold option is set, the other option is ignored.
When both thresholds are configured, visitors are routed to the waiting room as soon as either one of the thresholds is
passed.
Visitors are then sent on to their requested page according to the defined thresholds - at a rate of x new users/minute
if that option is defined, and/or up to the maximum number of active users, if that option is defined.
Note: If there are conditions defined for the waiting room, only user sessions that match all conditions are counted as
new or active users. For details, see Conditions above, under Add/edit a waiting room.
Option Description
The maximum number of active user sessions

simultaneously allowed access to the website before
Imperva starts routing visitors to the waiting room.
• Maximum number of active users: The

maximum number of concurrent users
allowed. Minimum value = 1.
Defining a very low threshold can be useful for

testing purposes. However, the recommended
minimum value for production purposes is
200.
Note: When a threshold value of 1-199 is

defined, the New incoming users per minute
option is not available.
Total active users
• User inactivity timeout (in minutes):
Inactivity timeout, from 1 to 30 minutes.
Default value = 5 minutes.
A user is considered active only when visiting

the pages within the waiting room scope, and
not other pages on the website.
A user who is inactive for a longer period of

time is considered as having left. On returning
to the site, the user needs to wait in line again
if the waiting room is active.
Tip: When enabling the Total active users

threshold, the inactivity timeout is very
important. Once the site is at full capacity (the

Option Description
threshold has been passed), no new user can
access the site until another user leaves and
frees up space.
To optimize the user experience, we

recommend setting a balanced inactivity
timeout value — long enough so that the
user's session is still open if they return
quickly, but not so long that it unnecessarily
prevents access to other waiting visitors. The
default timeout of 5 minutes is the
recommended minimum value.
The maximum number of new users per minute that

are allowed access to the website before Imperva
starts routing visitors to the waiting room. Minimum
value = 60.
New incoming users per minute
If the Total active users option is also selected, the
New incoming users per minute value must be less
than the Maximum number of active users value.
Examples
Example 1 - The "new incoming users" threshold is defined
Suppose you set New incoming users per minute to 1000 per minute, and incoming traffic reaches a rate of 1010 new
users per minute.
Result: All new users are sent to the queue. Based on the threshold value you defined, 1000 users are then allowed
entry to the website each minute (redirected to their requested page). Any users above this threshold are routed to
the waiting room.
Example 2 - Both threshold values are defined
Suppose you select both options and define the values as follow:
• Maximum number of active users = 3000
• New incoming users per minute = 120
Suppose there are currently 2800 active users, and the rate of incoming traffic is now 200 users per minute. The New
incoming users per minute threshold of 120 has been passed, so new incoming users are routed to the waiting room.
In the first minute, only 120 users will be able to enter the site. So active users at the end of the first minute totals
2920.

In the next minute, let's assume that traffic is still 200 incoming users per minute. Because the total number of active
users is now 2920, only 80 additional users can enter the site.
At this point, the Maximum number of active users (3000) has been reached, so no new users are allowed in to the
site before other users leave.
Customize the waiting room visitor page
You can customize the waiting room page that is displayed to your website visitors when they are placed in the queue.
Under HTML Customization, there are two options:
Option Description
This is the default setting. Imperva provides a white-

label, out-of-the-box template.
Use Imperva template
Customize the page to meet your needs by adding

your company logo, banner, colors and so on. This
enables you to keep your brand recognition, as well
as add images and videos to promote your content
during wait time. Make sure to review the guidelines
below.
Customize waiting room page via HTML
Note that the template includes several place holder
variables. They indicate dynamic information that is
inserted by Imperva.
• $WAITING_ROOM_CONFIG$ - Calls a script

that periodically updates the status of the

Option Description
user, and reloads the page when the user is
allowed to enter the website from the waiting
room. This parameter is mandatory and
should not be modified or deleted.
• $WAITING_ROOM_LOADER$ - Used to validate

the loading of the page. This parameter is
mandatory and should not be modified or
deleted.
• $WAITING_ROOM_WRAPPER$ - Used to
validate the content of the template. This
parameter is mandatory and should not be
modified or deleted.
• $WAITING_ROOM_POSITION_IN_LINE$ - Used
to display the user's position in the waiting
room queue.
• $WAITING_ROOM_LAST_STATUS_UPDATE$ -
Used to display the time of the last status
update.
Click Preview to view the page as your website visitors will see it.
Custom template guidelines
• The custom template is restricted to 100K characters.
• The custom template must include valid HTML syntax.
• The custom template cannot contain:
• <iframe> tag
• <script> tag
• <form> tag
• illegal HTML actions, such as these HTML event attributes: onload, onerror, onmessage, onoffline,
ononline, onchange, onfocus, oninput, onsearch, onsubmit, onselect
• Any reference to an external resource or link must be absolute.

View your waiting rooms
View and manage all of the waiting rooms configured for your site.

Note: If there are multiple waiting rooms defined with the same conditions, the first one listed in the table is used and
the others are ignored.
The Waiting Rooms page displays the following fields for each waiting room. For more details on these fields, see
Add/edit a waiting room.
Column Description
Click the name to view or edit the waiting room
Name
settings.
Description The user-defined description of the waiting room.
The maximum number of new users per minute that
Rate threshold/min are allowed access to the website before Imperva
starts routing visitors to the waiting room.
The maximum number of active users

Max active users simultaneously allowed to access the website before
Imperva starts routing visitors to the waiting room.
Inactivity timeout, from 1 to 30 minutes. For more

Inactivity timeout
details, see Set activation thresholds.
The rules applied to the waiting room that define

with more granular control when the waiting room is
Conditions
activated. For example, for a specific path or page on
your website.
The date that the waiting room was created or last

Last Modified
edited.
View or change the waiting room's status.
• Enabled: When the threshold is passed,

Status visitors are sent to the queue.
• Disabled: The waiting room is suspended.
Visitors are not sent to the queue, even when
the threshold is passed.
Indicates if there are users waiting in line, or if the

Currently in queue
queue is empty.
More options
Click the ellipsis to view options to edit or delete
the waiting room.

Track performance statistics

View statistics on actual usage of your waiting rooms on the Website Performance Dashboard.
Waiting Room API
You can also manage waiting rooms for your websites using the API.
For instructions on using the API, see Waiting Room API Definition.

Waiting Room API Definition


DDoS Protection for Websites

Websites using Imperva DDoS Protection are protected from any type of DDoS attack, including both network (Layer 3
and 4) and application (Layer 7) attacks.
Learn more:

• Web Protection - DDoS Settings


Introduction: DDoS Protection for Networks

Imperva’s DDoS Protection for Networks allows organizations to protect entire networks and subnets from network
(Layer 3 and 4) DDoS attacks.
DDoS Protection for Networks can be used to protect any online asset such as websites, DNS servers, SMTP servers
and any other IP based application. This service leverages Imperva’s multi-terabit network capacity and packet
processing capabilities to absorb and mitigate the largest and most sophisticated DDoS attacks.
DDoS Protection for Networks can be deployed as an always-on, on-demand or contingency solution, and can be
combined with all Imperva Cloud Application Security services for extending protection and monitoring capabilities.
• Always-on: Your ingress traffic is constantly tunneled through the Imperva network.
• On-demand: Your ingress traffic is tunneled through the Imperva network only during attack time.
• Contingency: Similar to on-demand, but with a limited number of network range diversions to redirect your
traffic through the Imperva network. The Contingency solution is intended as a backup service in the event of
an outage in your primary protection service.
Benefits
• Layer 3 and 4 DDoS protection for IP ranges and subnets hosting any IP based application
• Terabit DDoS scrubbing capabilities
• Attack monitoring and mitigation backed up by 24x7 NOC and SOC teams
• SLA for DDoS mitigation performance
How Does DDoS Protection for Networks Work?
Imperva DDoS Protection for Networks allows organizations to tunnel all ingress traffic (traffic from the Internet to the
origin network) through the Imperva network. The organization's edge routers use the Border Gateway Protocol (BGP)
to announce subnets and IP ranges to be advertised by Imperva, forcing all Internet routes pointing at their data
center to point at Imperva instead. DDoS Protection for Networks uses Generic Routing Encapsulation (GRE) tunneling
to forward traffic to the origin network after the traffic has been scrubbed from any DDoS attack.

The Behemoth
At the core of Imperva’s DDoS Protection for Networks service is its proprietary DDoS scrubbing appliance named
Behemoth. The Behemoth performs all Layer 3 and Layer 4 DDoS scrubbing and then tunnels clean traffic over a GRE
tunnel to the origin network. Each of Imperva’s data centers is equipped with one or more Behemoth appliances. In
addition to scrubbing any DDoS attack, Behemoth provides packet level visibility and packet flow control to our 24x7
Operations Center teams.
Traffic Flow
The Border Gateway Protocol (BGP) is used to control the traffic flow and route traffic through the Imperva network.
In order to route traffic sent to the origin network through Imperva, organizations configure their routers to announce
that their IP ranges are to be advertised by the Imperva routers. This is done by establishing BGP peering between the
Imperva router and the organization’s routers.
Once Imperva starts advertising the customer’s IP ranges, all Internet routes for the origin network point at the
Imperva network. Ingress traffic sent to the protected IP ranges is automatically routed to Imperva where DDoS
scrubbing takes place. After the traffic has been scrubbed, Imperva forwards clean traffic to the origin network over a
pre-established GRE tunnel.
DDoS Protection for Networks uses an asymmetric channel in which ingress traffic is routed through Imperva, while
egress traffic (traffic from the origin network to the Internet) is routed through the organization’s ISP.
Software-defined network range advertisement
Imperva’s software-defined network range advertisement announces customer IP ranges from the following
locations:
• the Imperva PoPs to which the customer data center is connected

• all Imperva PoPs in the region where the customer data center is located

• Imperva high-capacity regional PoPs outside of the region
This method provides the following benefits:
• When a DDoS attack traverses transatlantic cables, ISPs may null route the attacked IP in order to avoid
congestion of those cables. By advertising the IP ranges from PoPs in each region, Imperva mitigates the DDoS
attack in the continent in which it started.
• More PoPs participate in the mitigation, enabling Imperva to handle larger DDoS attacks without human
intervention.
• Imperva PoPs are connected through high-quality internet connections, resulting in better user-experience.
During an Attack
DDoS Protection for Networks can be deployed as an always-on or an on-demand solution. Organizations choosing to
deploy DDoS Protection for Networks as an always-on solution route their traffic through Imperva at all times.
Organizations choosing to deploy DDoS Protection for Networks as an on-demand solution route their traffic through
Imperva only when they are under a DDoS attack.
DDoS Protection for Networks reacts to DDoS attacks at a micro-second scale by utilizing multiple mechanisms, such
as detecting anomalies in traffic patterns and identifying known attack patterns. Attack mitigation engines are
dynamically adjusted according to the attack severity as well as the state of the origin network. After traffic has been
scrubbed, clean traffic is forwarded to the origin network over a GRE tunnel.
DDoS Protection for Networks is backed up by 24x7 NOC and SOC teams that monitor attacks, adjust detection and
mitigation configuration, and respond to customer requests and enquiries.
Why Does Imperva Use a GRE Tunnel?
Imperva uses a GRE tunnel to route clean traffic to the origin (and also to establish BGP peering for on-demand DDoS
Protection for Networks deployments).
When Imperva advertises the customer’s IPs or IP ranges, all packets targeted to these IPs/ranges are directed to the
Imperva network. The Imperva Behemoth appliances scrub the traffic, filtering incoming packets and dropping any
DDoS attack packets. The remaining “legitimate” packets are passed on to the customer according to their destination
IP through the GRE tunnel.
The GRE tunnel is the only way that the packets can reach the customer at this point, because Imperva is the only
entity advertising the customer’s IPs/ranges. This means that even if Imperva were to send the packets back to the
Internet, they would return to Imperva again.
How To
• Onboarding: DDoS Protection for Networks
Read More
• Recommended Topology: DDoS Protection for Networks

• Notifications


On-Demand Flow
This topic describes the flow of events when mitigating a DDoS attack for Infrastructure Protection customers in
on-demand mode.
Before an attack
The following describes the flow of events before an attack occurs:
1. Imperva establishes a Generic Routing Encapsulation (GRE) tunnel between the Imperva Data Center and your
AS edge router.
2. Imperva establishes a BGP peer relationship between your AS edge router and the Imperva edge router via the
GRE tunnel. Imperva does not advertise your IPs to the Internet at this stage. This will only be done during an
attack, as described below.
3. You notify your Internet ISP that Imperva now has permission to advertise your IP range. The Internet ISP then
adds your IP range to Imperva’s ASN, meaning that Imperva now has permission to start advertising this IP
range at any time.
During an attack
The following describes the flow of events when your network is being targeted by a DDoS attack:

1. After Imperva has established a Generic Routing Encapsulation (GRE) tunnel and a BGP peer relationship
between the Imperva Data Center and your AS edge router (as described above), the Imperva Data Center and
your AS edge router keep the GRE tunnel open and continually transmit keep-alive messages between them.
2. The Imperva Behemoth stands vigilant at the edge of this GRE tunnel, waiting for a BGP announcement (call for
help) from your edge router, indicating that your network is under attack.
3. Once an attack on your network is detected (either by your team or by using Imperva’s Infrastructure Monitoring
service), your edge router starts sending BGP announcements to Imperva over the GRE tunnel.
4. Immediately after receiving the BGP announcement, Imperva’s routers start advertising your prefixes and
Internet routes to your network are updated globally.
5. Traffic starts flowing through Imperva instead of directly to your edge router, and typically all traffic is rerouted
within two or three minutes.
6. In parallel, you stop sending BGP announcements to your ISP and stop advertising your prefixes.
7. Traffic reaching the Imperva network is filtered. DDoS traffic is dropped and clean traffic is forwarded to the
origin network via the GRE tunnel.
8. Imperva will continue to advertise your IP range until your router sends a new BGP announcement to stop
advertising its IP range.

Flow Monitoring: DDoS Protection for Networks

Imperva’s Flow Monitoring service helps organizations subscribed to the DDoS Protection for Networks service in on-
demand deployment mode to automatically detect DDoS attacks and activate the service. This service monitors
the origin network edge routers and firewalls and provides packet level visibility for both customers and Imperva’s
Network Operations Center (NOC) team.
Any attack that targets the origin network will be identified by Imperva and customers will be immediately informed
via their preferred channel.
Benefits
• 24x7 network monitoring for detecting DDoS attacks
• DDoS notifications via email, text messaging and phone
• SLA for DDoS detection performance
• Multi-terabit DDoS scrubbing capabilities
• Backed up by 24x7 NOC and SOC teams
How Does Flow Monitoring Work?
Collecting Traffic Data for Monitoring
The Flow Monitoring service requires organizations to send NetFlow, sFlow, or jFlow feeds from their edge networking
devices. These feeds contain information, such as packet types, rates and size, which is used by Imperva to detect
DDoS attacks.
• NetFlow: a network protocol developed by Cisco. NetFlow versions: 5, 9 and 10 (IPFix) are supported.
• sFlow: a protocol similar to NetFlow. It is generally supported on Layer 2 networking equipment, such as
switches and firewalls.

• jFlow: a data flow sampling technology employed by Juniper switches and routers for network monitoring.
Traffic Profiling
When the Flow Monitoring service is enabled, Imperva creates a traffic profile for the origin network that is used as a
baseline for detecting DDoS attacks. From that point on, Imperva compares real-time traffic information with the
established baseline to detect attacks, as well as updating the baseline based on new traffic profiles that are
identified.
Detecting Attacks
Any suspicious traffic will trigger an alert to Imperva's 24x7 NOC, which will immediately analyze the traffic pattern
and determine whether it constitutes a DDoS attack. In the case of a real attack, the NOC will notify the protected
organization according to a pre-defined escalation path and using the preferred method of communication. The
whole process usually takes less than a minute and is backed up by Imperva’s Service Level Agreement (SLA).
Read More
• Flow Monitoring Settings

• Introduction: DDoS Protection for Networks

Onboarding: DDoS Protection for Networks

The Imperva Infrastructure Protection service provides DDoS protection at the network infrastructure level.
In this topic:
• Overview
• Prerequisites for onboarding
• How to onboard Infrastructure Protection
Overview
The Imperva Infrastructure Protection service can be deployed as either always-on or on-demand and is asymmetric
(ingress traffic flows through the Imperva network; egress traffic goes directly to the Internet). In order to protect the
entire network infrastructure against L3/4 DDoS attacks, Imperva needs to be able to advertise all of the publicly
available IP ranges connected to the protected AS. In addition, a GRE tunnel has to be established between the origin
network and Imperva. On-demand setups also require the establishment of BGP peering between the edge devices on
both ends. The BGP peering is established via the GRE tunnel and is used for announcing ranges to Imperva during an
attack.
Imperva Infrastructure Protection onboarding is not a fully self-service process. It usually takes some time until the
setup is ready and requires effort on both the Imperva and customer sides to see it through (process duration and
Imperva commitments during the process are covered under the Imperva SLA).
Imperva assigns a solution manager to take responsibility for the onboarding process. The solution manager works
with the customer’s networking/operations team to set up Imperva DDoS Protection for the entire network
infrastructure.
Prerequisites for onboarding
• Ownership of at least one /24 network prefix or larger
• Route object configuration for each of the IP ranges in at least one of the IRR databases (for example, RADB)
• TCP MSS adjustment capabilities (if using GRE)
• Experience with utilizing BGP on the network edge (preferred)
How to onboard Infrastructure Protection
The Imperva solution manager will guide you through the following process phases to onboard your network
infrastructure:
1. Feasibility: The Imperva solution manager sends you a Scoping document to be filled in with your basic
network information. This Scoping document enables Imperva to prepare a quotation and verify the feasibility
of providing protection for your infrastructure.
2. Provisioning: Imperva assigns an onboarding team to assist you during the onboarding process.
1. Imperva’s onboarding team provides you with a Provisioning form detailing how you should configure
your network equipment.
2. Configure your network equipment precisely as specified, while filling out the fields of this form.
3. Submit this form to Imperva so that the Imperva team can configure its equipment and define an initial
security profile for you accordingly.
4. The Imperva onboarding team then completes the setup on the Imperva side according to the
information provided by you in the Provisioning form.

3. Provisioning Call: Imperva's onboarding team will initiate a conference call with you and your engineers in
order to verify that the setup is properly configured, both on your equipment and on the Imperva network.
The Imperva team then prepares and sends you a DDoS Playbook, specifying the exact steps you should take
during a DDoS attack. The playbook is specific to your setup. This playbook will also be used to test the setup.
4. Testing: During this phase, the Imperva onboarding team tests the setup with you according to the steps
detailed in the DDoS Playbook. This test simulates a DDoS scenario in which you switch over incoming traffic to
Imperva. Prior to the testing, if not already completed, route objects should be configured for all IP prefixes on
one of the IRR databases. These configuration changes must happen at least 24 hours before testing to allow for
full worldwide propagation. Prefixes configured without route objects may not work properly.
Note: After onboarding to the DDoS Protection for Networks service, you may want to edit or add new connections.
For example, if you change ISP or want to create new GRE tunnels. You can do this via the Cloud Security Console or
API, for GRE-Tunnel type only. Other connection types must be configured by the Imperva team.
For details, see Add a GRE tunnel connection.
Read More

• On-Demand Flow
• BGP Community Support Option
• Direct Connection

Recommended Topology: DDoS Protection for

Networks
This topic describes Imperva’s guidelines and recommendations for customer setup that provides maximum service
availability, performance, and functionality.
This topology is recommended for both always-on and on-demand DDoS Protection for Networks customers.
In this topic:
• Service Availability
• Service Performance
• Service Functionality
Service Availability
Imperva has a global network of data centers to which you can connect (For the full list, see Imperva Data Centers
(PoPs)).
Each of your data centers should be connected to at least 2 Imperva data centers (also referred to as Imperva PoPs) to
make sure service is available during failure or planned PoP maintenance. At least one of these connections should be
to a high capacity PoP (listed in the onboarding instructions here: Add a GRE tunnel connection).
To ensure 100% availability, each customer data center should be connected to 3 Imperva PoPs.
If you have multiple data centers, you can connect to the same or different Imperva PoPs.
Connecting to multiple Imperva PoPs ensures service availability by Imperva. Failures which would impact service
availability can also occur at the customer end or even at the customer’s ISP. Therefore, it is recommended that you
use redundant endpoint routers and redundant ISP connections when connecting your data centers to Imperva PoPs.

Service Performance
For best performance, consider the following when setting up connections between your data centers and the
Imperva PoPs:
• Choose Imperva PoPs that minimize latency, as well as other performance KPIs such as packet loss and jitter. In
most cases, this is achieved by connecting to Imperva PoPs that are geographically closest to your data centers.
Note: It is also worthwhile considering the ISP, as in some cases, a connection through one ISP has lower latency
than through another, due to peering agreements between transit providers.
• Link performance to different Imperva PoPs can vary between connections. If there are significant performance
differences between the connections, it is recommended to configure more than one connection to the highest-
performing PoPs.
For details on Imperva's link performance monitoring capability, see Configure Performance Monitoring: DDoS
Service Functionality
In most cases minimal connectivity is sufficient to gain the functionality benefits offered by Imperva’s DDoS
Protection for Networks service. However there might be some scenarios where the optimal configuration — multiple
connections between your data centers and Imperva as described above — can have functional impact.
Imperva's link performance monitoring collects performance KPIs of the connections between your data center and
Imperva. This is achieved by continuous polling of your endpoints (using ICMP echo messages) from the Imperva PoP.

Proper performance collection mandates that the ICMP echo replies travel the same path as the ICMP echo requests.
(The Performance Monitoring documentation includes equipment configuration guidelines on how this can be
achieved using static routes or BGP). If multiple connections between the same endpoint in your data center and the
same Imperva PoP are used, proper link performance monitoring cannot be guaranteed. This can lead to inaccurate
KPIs displayed in the performance dashboard. Such topology should be avoided if possible by using multiple
endpoints in your data center.

Security Policy and Mitigation

This topic describes how Imperva defines a custom security policy for each DDoS Protection for Networks customer
network range, and how the policy impacts our mitigation process.
In this topic:
• Overview: Traffic flow

• DDoS security policy
• Mitigation process
• Recommendations
• Example
Overview: Traffic flow
When Imperva advertises your network ranges, all packets targeted to those ranges are first directed to the Imperva
network. Imperva's Behemoth DDoS scrubbing technology scrubs the traffic, filtering incoming packets to drop any
DDoS attack packets. We then forward the remaining clean or "legitimate" packets to your origin network through the
connection type you defined (tunnel or direct connection).
DDoS security policy
The traffic scrubbing that Imperva performs is based on a unique security policy that we define for each network
range. The goal, of course, is to achieve the best granularity possible in order to minimize false positives and maximize
mitigation.
Imperva defines the security policy based on your traffic rates and patterns. When you first onboard your range to the
DDoS for Networks service, we define an initial security policy according to our internal logic and the network
information you provide in the scoping document. This information enables us to create an initial policy that allows
a reasonable rate of traffic while blocking suspicious rates of traffic, until we have enough information to develop a
more customized profile.
After 7 days of traffic flow, the Imperva SD-SOC analyzes the data and automatically adjusts the security policy based
on your network range's actual traffic patterns. Our Security Operations Center (SOC) reviews the policies as needed.
Mitigation process
The mitigation process built in to the Behemoth technology applies deep packet inspection combined with the
application of advanced security rules and security challenges in order to identify malicious sources and/or content.
Multiple mitigation steps are defined and evaluated independently for each traffic type, such as TCP, UDP, SYN, DNS,
NTP, and so on.
Each step is combined with thresholds in Kpps, Mbps, or both, in order to appropriately flag the traffic as malicious or
legitimate. When the specified threshold is reached, the relevant mitigation step is activated. Mitigation steps are
activated one at a time, as needed. Only the first and last steps are described here:
• Mitigation start: The lowest threshold is designed to let the Behemoth know it should start inspection. This
does not necessarily indicate that traffic will be blocked, rather that we have started taking a closer look.
• Rate limiting: As a final step, and only after all other thresholds are passed, we activate this mitigation level.
Rate limiting involves packet drop, designed to prevent network circuits from becoming too congested and

crashing completely. The rate limiting threshold is generally set up based on your capacity. Our Behemoth
reaches this step extremely rarely, if ever, as traffic is usually blocked at an earlier stage.
Recommendations
Keep us informed
Imperva defines security policies based on the data displayed in the DDoS for Networks (Infrastructure) Dashboard.
This can be based on either actual traffic or on the NetFlow/sflow/jflow feed we receive from you.
In addition, keeping us informed of your preferences, significant changes in traffic volume or patterns, or your
network and connectivity capacity can help us adjust your security policy accordingly and give you the best results.
For example:
• If the traffic flowing through Imperva is lower than the maximum rates you expect or can handle, we would like
to adjust the mitigation start threshold to a higher rate.
• We set rate limiting thresholds based on both your actual traffic, and the onboarding scoping document. If the
traffic pipe size or capacity has changed, or if you would prefer that a higher threshold is set before rate limiting
is triggered, we can adjust these thresholds accordingly.
Onboard your ranges as /24 prefixes
DDoS attacks typically target specific hosts. Therefore, applying mitigation to a broad range is not the best practice. To
enable us to apply mitigation to the smallest possible portion of your network, it is best to define /24 ranges when
onboarding DDoS Protection for Networks so that we define a separate, custom security profile for each prefix.
Example
DNS response rates were adjusted according to peacetime traffic.
During peacetime:
We see total traffic at 4:02 and see that DNS Response traffic is 2.38 Mbps.
During attack - total traffic:

At 4:06, we see that total DNS Response traffic is 7.29 Gbps.
During attack - legitimate, passed traffic:
At 4:06, while total DNS Response traffic was 7.29 Gbps, we see here that DNS Response traffic that was passed on to
the origin was about 3 Mbps. This demonstrates that the volume of legitimate traffic that is forwarded to your origin
during the attack is comparable to the volume during peacetime.
Read More

• Notifications

Direct Connection
Imperva supports direct connections for the DDoS Protection for Networks service. Connect directly to the Imperva
network over a private, high-quality connection.
In this topic:
• Benefits of Direct Connection

• Cross Connect
• Virtual Cross Connect
Benefits of Direct Connection
• No Latency, No Packet Loss: Because traffic is routed through a LAN rather than over the public internet,
latency and packet loss are eliminated.
• Very High Bandwidth: Cross connect/ECX can easily support tens of Gbps of clean traffic.
• Better Performance and Compatibility: No MTU limitations, no overhead. Performance comparable to any
LAN.
• Better Stability: While GRE tunnels run over ISPs and have many moving parts, making them susceptible to
occasional instability that can result in service degradation, a direct connection is stable.
• Multi-Cloud Access: Using ECX grants AWS, Azure, and Google Cloud users direct access to Imperva
DDoS Protection for Networks.
Cross Connect
• Available in all Imperva PoPs.
• Customers who are co-located with us can use the data center’s services to set up a cross connect.
• Customers who are not co-located with us can set-up any type of leased-line, MPLS, or other WAN connectivity
method to be able to cross connect.
Virtual Cross Connect
Imperva offers the option for you to connect your infrastructure located in internet exchange facilities to the Imperva
DDoS Protection for Network service by forming a Layer 2 connection to Imperva.
• Equinix Cloud Exchange (ECX): Connect your infrastructure that is located in Equinix facilities and using the ECX
Fabric platform. For details, see Equinix Cloud Exchange (ECX) Direct Connect.
• Megaport: Connect your infrastructure that is located in Megaport-enabled locations.
To check which Imperva data centers support these connections, see Imperva Data Centers (PoPs).


Equinix Cloud Exchange (ECX) Direct Connect

Establish a direct connection between your infrastructure and the Imperva DDoS Protection for Networks service.
In this topic:
• What is Equinix Cloud Exchange?

• Prerequisites
• Imperva PoPs in Equinix facilities
• The Process
What is Equinix Cloud Exchange?
Equinix Cloud Exchange (ECX) is one of the available connection methods for the Imperva DDoS Protection
for Networks service. ECX enables you to form a connection between data centers in remote locations.
As a cloud service provider, Imperva offers the option for you to connect your infrastructure located in an Equinix
facilities and utilizing ECX Fabric to the Imperva DDoS Protection for Networks service by forming a Layer 2
connection using the ECX platform.
Prerequisites
Your infrastructure must be located in Equinix IBX, which offers connectivity over ECX Fabric.
Unlike traditional cross-connect, your infrastructure does not have to be co-located with Imperva in the same Equinix
IBX in order to form a connection. Because ECX can be used to connect two data centers located in different Equinix
facilities, you can connect between your infrastructure located in Equinix in one location and an Imperva PoP (data
center) located in Equinix in a different location.
Imperva PoPs in Equinix facilities
For the list of Imperva PoPs located in Equinix IBX facilities, see Imperva Data Centers (PoPs).
The Process
1. Setting up the Imperva-side endpoint (Z-side).
1. The Imperva team starts by setting up the service in the relevant Equinix IBX.
2. Once ready, the Imperva onboarding team configures the connection for your account.
2. Setting up the customer-side endpoint (A-side).
1. When Imperva informs you that the Imperva-side of the ECX connection is ready, you need to order a
virtual connection from Equinix to Imperva. You submit the connection request using the ECX Fabric
portal. For instructions on creating a connection, see the Equinix ECX Fabric documentation.
2. The Imperva team will then receive, review, and approve the connection request.
3. When the connection is established, the Imperva onboarding team contacts you to continue the
onboarding process.
For more details on the onboarding process, see Onboarding: DDoS Protection for Networks.
When onboarding is complete, you can view your connection in the Cloud Security Console. Navigate to Network >
Network Protection > Connectivity Settings. The connection will be listed under Origin Connectivity.


BGP Community Support Option

Imperva supports the use of BGP communities, which enable enhanced flexibility with BGP announcements between
an edge router and the Imperva network. Configuring BGP communities is done during the onboarding process.
In this topic:
• Overview
• Supported BGP Communities
Overview
The common use case of BGP communities is the Prepend community. Prepend enables on-demand customers to
minimize exposure time when onboarding Imperva during a DDoS attack. This is done by maintaining a low priority
second route via Imperva at all times. The Imperva route to your network is stored in each edge router in the world,
just as all other routes to your network are stored. Once an attack starts and routes via your ISP are no longer active,
traffic will be routed through Imperva.
Example
The following is an example of the above use case. The BGP Prepend community is used to add the same ASN number
multiple times.
If your ASN is 1, then your ISP will likely advertise the following prefix:
1.2.3.0/24 ASN:1
In order to be considered a secondary route, Imperva will advertise the same address with multiple repetitions. For
example, Imperva might advertise the following to the world using the Prepend option (two ASN hop repetitions are
shown):
1.2.3.0/24 ASN:1 ASN:1
This route (advertised by Imperva) appears to have multiple hops between two Autonomous Systems (even though
both of them have the same ASN). This will trigger edge routers to prefer the route announced by your ISP.
When an attack commences, your ISP will stop announcing a route to your network and traffic is then immediately
routed through the Imperva network.
Supported BGP Communities
You can mark routes with the following communities when advertising IP ranges through Imperva:
AS Prepending Communities (Preferred method)
Use the following communities to inform Imperva that it should prepend your AS:
Community Description
19551:511 Prepend customer’s AS 1x

No Advertise Communities
Use the following communities to inform Imperva that it should not advertise your IP range:
no-export Imperva will not advertise the IP range
19551:XXXX Your customer-specific community
Local Preference Communities
Use the following communities to inform Imperva that it should use local preference with your AS:
19551:170 Set local preference to 170

Add a GRE tunnel connection

This topic describes how to add a GRE tunnel connection to your Imperva DDoS Protection for Networks
configuration.
Note: This process is currently available for the GRE-Tunnel connection type only. Other connection types must be
configured by the Imperva team.
For an overview of the DDoS Protection for Networks onboarding process, see Onboarding: DDoS Protection for
Networks.
In this topic:
• Overview
• Open the Connectivity Settings
• Add your ASN
• Define origin connectivity
• Configure routing options
• Network Settings API
Overview
After you are onboarded to the DDoS Protection for Networks service, you may want to edit or add new connections.
For example, if you change ISP or want to create new GRE tunnels.
To configure a new connection:
1. Add your ASN
2. Define connection settings
3. Configure routing options

Open the Connectivity Settings
1. On the top menu bar, click Nework.
2. On the sidebar, click Network Protection > Connectivity Settings.

Add your ASN
Your autonomous system number is required for communication between the Imperva network and your origin
network.
Note: If your ASN is already registered in Imperva, you can skip this step and continue to Define origin connectivity.
A unique autonomous system number (ASN) is allocated to each autonomous system by the Internet Assigned
Numbers Authority (IANA), for use in BGP routing.

We register the AS-SET object, which enables us to group AS numbers in a single object. It indicates to our upstream
providers that we are now eligible to announce the ASNs that are listed within the AS-SET object.
When you start the onboarding process, your ASN is added to our AS-SET object, and our system registers your ASN
on each registrar.
Leased IP ranges: If you are leasing an IP range from a 3rd party vendor such as an ISP, you will need to provide a
letter of agreement (LOA) from the owner of the IP range. The range will be announced to Imperva using a private ASN,
and Imperva will announce the route with its own ASN.
To add your ASN
Under ASNs, click Add, enter your ASN number, and save.
Note: It can take up to 48 hours for the ASN to be fully registered in our system.
In the ASN table, you can expand the ASN row and view the registries and their registration status. The following
indicators reflect the registration status of the ASN in the specified registry:
Registered
Pending registration
Not registered
Example:
For status details, click the check box next to a registry row and click Check Status.
Define origin connectivity
Configure the tunnel connection between Imperva's network and your origin network. This connection is used for
clean traffic and BGP announcements.

Prerequisite: Make sure that your network range has already been defined by the Imperva team and is listed on the
Protection Settings page.
Guidelines:
• For redundancy purposes, configure a minimum of two connections for each GRE tunnel (each tunnel public IP).
• For each connection, select a different Imperva data center.
For example:
• Connection 1, Data Center 1

• Connection 2, Data Center 2
Add a connection:
Under Origin Connectivity, click Add, and fill in the following fields:
Field Description
The connection type.

Type
Self-service onboarding is currently supported for
the GRE-Tunnel type only.
It is recommended to give the connection a

meaningful name to help you easily identify it. This
can include the ISP or data center vendor, the
Connection Name
connection type, and the location of the Imperva
data center that you select for this connection. For
example, Equinix-GRE-TOR.
Enter the public IP address of your network device
Tunnel Public IP
(router/firewall).
Select an Imperva data center to use for this

connection.
Set up a minimum of two connections between your

origin data center and Imperva's global network to
ensure resiliency and failover.
Imperva Data Center
For the first connection, select one of the following
Imperva data centers, according to your origin data
center's region:
• US: LAX, MIA, IAD
• EU: FRA, LON, AMS

Field Description
• APAC: HKG, SIN, TKO
For other connections, it is recommended to select

the Imperva data center closest to your origin data
center.
Note: You can also select several data centers from

the list above for your connections if they are the
closest to your origin data center.
Select one of the private address ranges provided by

Source Range
Imperva to use for this GRE connection.
Enables Imperva to monitor the connection and

report on the connection status.
Connection status is displayed on the Network

Settings page for each connection. In addition,
BGP Peer Monitoring
notifications on connection up/down status are sent
to your account notification list. For details, see
Notifications.
This option is enabled by default.
Gain visibility into the performance of the

connections between Imperva data centers and your
origin network.
Performance Monitoring
For details, see Performance Dashboard: DDoS
Configure routing options

In this step, you set up the BGP peering sessions for routing traffic between Imperva and your origin.
Configure one policy for each connection you defined in the Origin Connectivity section.
Under Routing Options, click Add, and fill in the following fields:
Field Description
Select one of the connections that you defined
Connection Name
under Origin Connectivity.
Select the ASN associated with the connection you
ASN
selected.

Field Description
Specifies how long a router waits for incoming BGP

messages before it assumes the neighbor is not
available.
Hold Time
Default: 30 seconds
Permitted values: 0-300
(Recommended) Enter any string to use for

authentication of this BGP peer connection.
Authentication Key
If you define an authentication key here, it must also
be configured on your edge router.
Network Settings API

You can also configure the GRE connection using the API.
For instructions on using the Network Settings API, see Connectivity Settings API Definition.
The definition file presents a full, formatted, and interactive version of the Network Settings APIs that you can use to
learn about the APIs, or test them using your API ID and key.
See also:
• To view or edit your settings after onboarding: Connectivity Settings: DDoS Protection for Networks.
• To configure monitoring settings, see Flow Monitoring Settings.

Configure Performance Monitoring: DDoS Protection

for Networks
Gain visibility into the performance of the connections between Imperva data centers and your origin network. Once
configured, you can view the metrics on the DDoS Protection for Networks Performance dashboard.
Visible spikes, or high values seen over time may indicate an area that requires further examination.
In this topic:
• How it works
• Enable and configure performance monitoring
How it works
Each Imperva data center (PoP) includes a pair of Performance Monitoring (PM) servers. When performance
monitoring is enabled for a specific GRE tunnel connection, the PM servers located in the PoP on one side of the
connection constantly send ICMP echo request packets (ping) to the remote GRE tunnel endpoint. The PM servers
then collect the echo reply messages, analyze them, and expose their KPIs.
To make sure that the KPIs represent the real traffic traversing through the GRE tunnel, it is imperative that the echo
requests and their replies are also sent via the GRE tunnel.
For the request, this is achieved by using your GRE tunnel endpoint as the destination. This is the private IP address of
your network device. It is listed as Customer Peer for each GRE tunnel connection on the Connectivity Settings page
> Origin Connectivity table.
For the reply, custom routing is required. Configuration instructions are provided below.
Enable and configure performance monitoring
Performance monitoring is disabled by default. You can configure it per GRE tunnel connection by following these
steps:
• Enable Performance Monitoring in the Cloud Security Console
• Configure your router for ICMP
Enable Performance Monitoring in the Cloud Security Console
You can enable monitoring for any GRE tunnel connection defined for your account on the Network Protection >
Connectivity Settings page, under Origin Connectivity.
Note: By default, the account admin can enable performance monitoring.
To enable additional users to configure performance monitoring, the account admin can grant users the Edit Single
IP permission.

The Performance Monitoring setting is available when you add or edit a GRE tunnel connection.
Configure your router for ICMP
To enable Imperva Performance Monitoring for a GRE tunnel connection, configure your GRE tunnel endpoint router
to accept ICMP echo requests and to route ICMP replies through the GRE tunnel.
By default, DDoS Protection for Networks is asymmetric, in which incoming traffic to the origin network passes
through the Imperva network, and outgoing traffic is sent from the origin directly to the ISP. For the connectivity
performance monitoring to work properly, the PM servers need to receive the ICMP echo reply through the GRE
tunnel. In most cases, this requires custom configuration on your remote endpoint/router.
Configure the router to do the following:
• Accept ICMP requests from the PM servers in the Imperva data center to which it is connected. Make sure that
the ICMP echo requests are not blocked from reaching your GRE tunnel endpoint by an access control list (ACL).
Note: The PM server IP addresses are listed for each GRE tunnel connection on the Connectivity Settings page,
in the Origin Connectivity table. They are listed in the Details column as PM Server 1 and PM Server 2.
• Route the ICMP echo replies through the GRE interface that the echo request is coming from. You can do this
using static routes or by accepting BGP advertisements sent from Imperva.
For static routes: Configure your device to route traffic to the PM servers through the GRE interface.
Example (on Cisco devices):
- Ip route [PM Server 1] 255.255.255.255 [Imperva Peer]

- Ip route [PM Server 2] 255.255.255.255 [Imperva Peer]
For BGP: Imperva sends route advertisements of the PM servers, sending the ICMP echo messages through the
respective GRE tunnel (both /32 and /29 routes are sent).
By accepting these advertisements, an appropriate route to your router’s routing table would be added.
Example (on Cisco devices):
- neighbor [Imperva Peer] route-map RM_NAME in

- route-map RM_NAME permit 10
match ip address prefix-list PL_NAME
- ip prefix-list PL_NAME seq 5 permit [PM SERVER 1]/32
- ip prefix-list PL_NAME seq 6 permit [PM SERVER 2]/32
Note: If there are multiple GRE connections between your Autonomous System (AS) and the same Imperva data
center, the routes may be learned from multiple connections.

Make sure to accept only the routes from the interfaces that are directly connected and block inner AS route
propagation.
Multiple connections from the same router to the same Imperva data center may lead to incorrect metrics
displayed in the Performance Dashboard.
See also:
• Performance Dashboard: DDoS Protection for Networks
• Add a GRE tunnel connection

Flow Monitoring Settings

Configure exporter settings for Imperva's flow-based monitoring and define recipients for notifications.
These settings apply to customer using the DDoS Protection for Networks service in on-demand mode. Using flows
that you provide, Imperva monitors your origin network to detect and notify you about DDoS attacks.
Note: Imperva supports NetFlow, sFlow, jFlow, and IPFIX feeds for monitoring. To learn more about Imperva
monitoring, see Flow Monitoring: DDoS Protection for Networks.
In this topic:
• Overview
• Open the Flow Monitoring Settings
• Define exporter details
• Configure attack notifications
• Flow Exporter API
Overview
To configure Imperva flow monitoring, define the details of your exporters. Flow exporters are network devices that
send flow data to Imperva monitoring collectors.
You can also define the list of recipients to receive notifications when a DDoS attack is detected or the status of an
exporter changes.
The Flow Monitoring Settings page includes:
Section Description
The exporters configured for your account.

Flow Exporters
For more details, see Define exporter details.
The recipients of DDoS attack alerts and flow status

notifications.
Attack Notifications
For more details, see Configure attack notifications.
Permissions
To edit the Flow Monitoring Settings, you need the Edit Single IP permission. It is granted to the account admin user
by default. The account admin user can then assign this permission to other account users as needed.
For details on assigning permissions, see Manage Roles and Permissions.

Open the Flow Monitoring Settings

1. On the top menu bar, click Network.
2. On the sidebar, click Network Protection > Flow Monitoring Settings.

Define exporter details
In the Flow Exporters section:
• Click Add to add a new exporter.
• Click the Exporter IP in the table to edit an existing exporter.
On the Add/Edit Flow Exporters page, enter or edit the following details:
Field Description
You can define the exporter as Primary or

Secondary to indicate its intended use. For
example, your main exporter or a backup.
Exporter type
Note: If you change the type of an existing exporter,
the flow status notification settings are restored to
their default values. For more details, see the Flow
status notifications description below.
The IP address of the network device sending flow

Exporter (router) IP
data to Imperva.
Enter a meaningful description to help you identify
Description
the exporter.
The IP address of the Imperva device that receives

your flow data.
Collector IP (Imperva)
Select a region based on your origin network’s
location.
The number of packets of actual traffic represented

by each sample packet sent to Imperva, in a ratio of
Sampling ratio (1:X) 1:X.
Enter a value for X.
Flow status notifications Define when you want attack notification recipients
to be notified about a change in the flow’s status.

Field Description
Leave the default values or enter a value between 4
minutes and 7 days. The value entered must be an
integer.
You can receive define notification settings for the

following:
• Start flow: The amount of time after Imperva

starts receiving a flow from this exporter that a
notification is sent.
• Stop flow: The amount of time after Imperva

stops receiving a flow from this exporter that a
notification is sent.
• Incompatible flow: The amount of time after

Imperva receives an incompatible flow from
this exporter that a notification is sent.
Note: If you change the Exporter type of an existing

exporter, the flow status notification settings are
restored to their default values.
• Default value for Stop notifications for a

Secondary exporter: 24 hours.
• Default value for all other notifications: 5

minutes.
Configure attack notifications

Add or edit recipients and their contact details.
You can choose to be notified by phone call, text message, or both.
These recipients will be notified in addition to email notification as defined in Notification Settings (Network Security
> Network Monitoring Notifications). For details, see Notification Settings.
In the Attack Notifications table:
• Click Add to add a new recipient.
• Click a Name in the table to edit the recipient's settings.
Enter or edit the following details for a notification recipient:
Field Description
First/Last Name The name of the notification recipient.

Field Description
Enter a meaningful description to help you identify
Description
this recipient.
The phone number of the recipient.
Primary Phone In the 2 fields provided, enter the country code in

the first field and the phone number in the second
field.
You can add an additional phone number which is

Secondary Phone
used if the Primary Phone is unavailable.
Select this option to receive text message

Notifications
notifications.
The order in which Imperva attempts to contact

recipients by phone.
By default, the Do not call option is selected. You

can edit this field to change the order.
When adding a new recipient, the next available

Phone Call Escalation Path
number is listed by default. For example, if there is
already a recipient defined as #1, a new recipient is
assigned #2.
Select Do not call to opt out of phone call

notifications. When Do not call is selected, this field
displays N/A in the Attack Notifications table.
Flow Exporter API

You can also manage flow exporters using the API.
For instructions on using the Flow Exporter API, see Flow Exporter API Definition.

Flow Exporter API Definition

Connectivity Settings: DDoS Protection for Networks

View connection and configuration details on the communication between Imperva’s network and your origin
network.
For instructions on adding a GRE tunnel connection, see Add a GRE tunnel connection.
In this topic:
• Open the Connectivity Settings

• Origin Connectivity
• Routing Options
• ASNs
• Network Settings API
Open the Connectivity Settings
2. On the sidebar, click Network Protection > Connectivity Settings.

Origin Connectivity
Connections between Imperva's network and the customer's origin network (used for clean traffic and BGP
announcements).
Column Description
Click the connection name to view additional

Name
details, or edit a GRE tunnel connection.
The connection type configured for this connection.
• GRE-Tunnel
• Cross Connect
• Virtual Cross Connect (ECX or Megaport)
Connection Type
Note: You can configure the GRE-Tunnel connection
type via the Cloud Security Console or API. Other
connection types must be configured by the Imperva
team.
PoP Name The Imperva data center used for this connection.
Details The IP addresses configured for this connection.
Status Connection status (up/down).

View/Edit connection
The following additional fields are displayed in the View/Edit Connection page when you click the name of an
existing connection:
Field Description
The public IP address of your network device
(router/firewall).
Tunnel Public IP
Applies to: GRE-Tunnel connection type only.
The VLAN ID in the Imperva switch assigned to the

connection.
VLAN
Applies to: ECX and Cross-Connect connection
types only.
The network range, as defined on the Protected

Source Range
Networks page, to associate with this connection.
Enables Imperva to monitor the connection and

report on the connection status.
Connection status is displayed on the Network

Settings page for each connection. In addition,
BGP Peer Monitoring
notifications on connection up/down status are sent
to your account notification list. For details, see
Notifications.
This option is enabled by default.
Routing Options
The routing policy configured for the connections between Imperva's network and your origin network.
Column Description
The name of the connection as configured under

Origin Connectivity above.
Connection Name
Click the connection name to view the routing
policy.

Column Description
The method by which we receive the customer IP

range announcement to be advertised on the
internet. It can by dynamic or static:
Type
BGP: (Dynamic) Ranges are announced to Imperva
by the customer via BGP protocol.
Static: Ranges are statically announced by Imperva.
ASN The ASN number associated with the connection.

Your peer IP address. Listed as Customer Peer in
Next-Hop
origin connectivity table above.
The following additional fields are displayed in the View/Edit Routing Policy page when you click the name of an
existing connection:
Field Description
Specifies how long a router waits for incoming BGP

messages before it assumes the neighbor is not
available.
Hold Time
Default: 30 seconds
Permitted values: 0-300
(Optional) Enter any string to use for authentication

of this BGP peer connection.
Authentication Key
If you define an authentication key here, it must also
be configured on your edge router.
ASNs
The autonomous systems that Imperva uses for communication between Imperva’s network and the customer’s
origin network.
For each ASN, you can see the registry in which it is registered, registration status, and the last status update.
Registration status:
Registered

Pending registration
Not registered
Click the expand arrow to see more registration details for each registry. For more details, click the check box next to a
registry row and click Check Status.
Network Settings API

You can also configure the settings using the API.
For instructions on using the Network Settings API, see Connectivity Settings API Definition.

Connectivity Settings API Definition

DDoS Protection for Networks: Connections API

Definition

Maintenance Readiness: DDoS Protection for Networks

As a DDoS Protection for Networks customer, you may receive email notifications from the Support team, or other
automated updates about maintenance activities. When notified of upcoming maintenance on the Imperva service,
we recommend that you review and verify the maintenance readiness steps below.
During maintenance, no impact to the service is expected, provided all BGP announcements are configured correctly.
To verify this, perform the following steps before maintenance begins:
For always-on customers
1. Make sure that all of your tunnels and BGP sessions are up and running. Verify the status of each tunnel in the
Imperva Cloud Security Console (my.imperva.com) on the Network > Network Protection > Connectivity
Settings page.
2. Make sure you are announcing your prefixes to all peers.
To check that you are advertising your prefix/es to a specific connection, you can use the following commands:
Cisco: show ip bgp neighbors <BGP peer address> advertised-routes
Juniper: show route advertising-protocol bgp <BGP peer address>
For example:
3. Prior to the maintenance, we will change the priority for your prefixes and traffic will be rerouted to the
redundant peer (PoP). If you prefer to reroute the traffic yourself, perform one of the following:
▪ Add the local preference using our community policy.

▪ Add prepends, using either our community policy or your own prepends.
For the list of supported BGP communities, see BGP Community Support Option.
4. If you require further assistance, open a ticket with Imperva Support: https://support.imperva.com.

For on-demand customers
Follow step 3 above.
Status notifications
To receive automated notifications about upcoming maintenance, subscribe via our status page: Imperva status page
.
For more details on status page notifications, see Notifications.

Control Network Range Diversions

Divert your protected network ranges to Imperva's DDoS Protection for Networks service on demand.
In this topic:
• How it works
• Divert or revert a range
• Control range diversions with the API
How it works
In the Cloud Security Console, you can independently divert and revert your ranges as needed.
Note:
• This feature is available for accounts working in on-demand or contingency modes only. For more details, see
Introduction: DDoS Protection for Networks or contact your Imperva Sales Representative.
• Only ranges whose diversion is controlled by Imperva are available for manual divert/revert.
Once the service is enabled in your account, you can divert and revert your ranges as needed.
• If you manually diverted a range, it automatically reverts after 72 hours, provided there was no malicious
activity in the last 48 hours.
• If there have not been 48 "clean" hours at the end of the 72-hour period, the range remains diverted. After the
48-hour waiting period ends, the range is automatically reverted.
Note: You can manually revert the range before the end of the waiting period.
• You can also divert multiple ranges.
Contingency mode: If your account has a limited number of diversions, all ranges diverted within a 72-hour
period are counted as a single diversion. In this case, the ranges all revert automatically 72 hours after the first
range was diverted (or longer, if there has not been a 48-hour waiting period without malicious activity, as
described above).
• If needed, you can extend the diversion for another 72 hours.
Contingency mode: If your account has a limited number of diversions, the extension is counted as an
additional diversion.
Note: For on-demand customers configured for automatic diversion:
If you revert a range during an attack, we mark the attack as a false positive.
In order to avoid diverting this range again during the current attack, we change your switchover setting for this range
from Automatic diversion mode to Require confirmation mode until our Security Operations Center (SOC)
evaluates your current policy.

In the event of a DDoS attack during the investigation, you are notified via the notification channels configured for
your account and can then choose to manually divert the range if needed.
After investigation is complete, SOC will change the setting back to Automatic diversion.
Events and notifications
When you divert or revert a range, an event is logged and displayed in the Event Log table in the Security Dashboard.
In addition, email notifications are sent to users subscribed to Network Security > Network Protection
Notifications. For more details, see Notification Settings.
Subscription status
You can view the number of diversions remaining in your account plan on the Security Dashboard as described
below, and on the Subscription page under DDoS Diversions.
Divert or revert a range
To manage your ranges:
1. Navigate to the Network Protection Security Dashboard (Network > Network Protection > Dashboard >
Security > Protected Networks tab).
2. The On-Demand Diverted Ranges widget displays the number of currently diverted ranges, and time
remaining until the range is automatically reverted. (This value does not include any post-attack waiting
period.)
Note:
▪ If a range has been diverted for longer than 72 hours, Upcoming revert pending is displayed.
▪ For accounts working in on-demand mode with unlimited diversions: If you have multiple ranges
diverted, the revert time of the first range due to be reverted is displayed. You can view revert times for all
diverted ranges inside the configuration screen.
3. Click Configure to select a range to divert or revert. You can also see the number of remaining diversions
Monitored tab: Your onboarded ranges that you can choose to divert.
Diverted tab: View the ranges that are currently diverted and routed through Imperva, or revert a range back to
your network.

Control range diversions with the API

Divert and revert your ranges as needed using the API
For instructions on using the API, see Network Range Diversion API Definition.
The definition file (Swagger) presents a full, formatted, and interactive version of the APIs that you can use to learn
See also:

Network Range Diversion API Definition


Introduction: DDoS Protection for Individual IPs

Imperva’s IP Protection service allows organizations to protect specific IPs from network layer 3 and 4 DDoS attacks.
IP Protection can be used to protect any online asset such as websites, DNS servers, SMTP servers and any other IP
based application. This service leverages Imperva’s multi-Terabit network capacity and packet processing capabilities
to absorb and mitigate the largest and most sophisticated DDoS attacks .
Imperva IP Protection is an always-on solution and can be combined with all Imperva services for extending
protection and monitoring capabilities.
In this topic:
• When to use IP Protection

• Benefits
• How does IP Protection work?
• IP Protection over TCP/IP
• IP Protection over GRE/IP-in-IP
When to use IP Protection
IP Protection should be used to protect non-HTTP assets. The service is suited for organizations that do not own a C-
Class range or the networking equipment with BGP capabilities required for using the Infrastructure Protection
service.
IP Protection is supported for IPv4 only.

Benefits
• Out-of-the-box Layer 3/4 volumetric DDoS protection for any IP-based application
• Terabit DDoS scrubbing capabilities
• SLA for DDoS mitigation performance
How does IP Protection work?
Imperva IP Protection allows organizations to direct all ingress traffic (traffic from the Internet to the origin network)
and egress traffic (traffic from the origin network to the Internet) for a specific IP to the Imperva network. An IP from
the Imperva IP ranges is provided as an alternative destination for the protected server, ensuring that all traffic to that
server is routed through Imperva.
The Behemoth
At the core of Imperva’s IP Protection service is its proprietary DDoS scrubbing appliance named Behemoth. The
Behemoth performs all Layer 3 and Layer 4 DDoS scrubbing and then tunnels clean traffic to the origin server. Each of
Imperva’s data centers is equipped with one or more Behemoth appliances. In addition to scrubbing any DDoS attack,
Behemoth provides packet level visibility and packet flow control for our 24x7 NOC team.

Traffic Flow
In order to route traffic sent to the origin server through Imperva, organizations update their clients and DNS with a
new IP provided by Imperva. Once all clients are updated with the new IP, all traffic to the protected server will be
routed through Imperva where DDoS scrubbing takes place. After the traffic has been scrubbed, Imperva forwards
clean traffic to the origin network.
IP Protection is deployed with a symmetric channel, in which both ingress and egress traffic are routed through
Imperva.
IP Protection over TCP/IP
To provide IP level protection, Imperva “leases" a global anycast edge IP address out of its own range to you and acts
as your internet-facing IP.
IP Protection over TCP/IP provides easy, self-service onboarding with minimal configuration.
Considerations when choosing this solution:
• Supported for TCP traffic only.
• During Imperva's weekly deployment and periodic maintenance operations, the TCP connections are
reestablished.
For onboarding instructions, see Onboarding IP Protection over TCP/IP.

IP Protection over GRE/IP-in-IP
IP Protection over GRE/IP-in-IP uses Generic Routing Encapsulation (GRE) or IP-in-IP tunneling to forward traffic to the
origin network after the traffic has been scrubbed from any DDoS attack.
IP Protection over GRE/IP-in-IP provides seamless integration without terminating sessions (not a proxy).

Supported for IPv4 only.
For onboarding instructions, see Onboarding IP Protection over GRE or IP-in-IP.
Preventing Direct-to-Origin Attacks on Origins Serving Websites along with other non-
HTTP Services
IP Protection over GRE/IP-in-IP can be combined with Website DDoS Protection for preventing direct-to-origin
attacks targeting servers that serve HTTP/S websites along with non-HTTP traffic, such as SMTP or FTP. Organizations
that would like to make their IPs accessible only through Imperva can use Website Protection to protect the website
(HTTP) traffic, together with IP Protection to protect the non-HTTP traffic. The unique and secure IP that is provided
by IP Protection is configured for the non-HTTP service as the origin IP. Doing so ensures that no external entity can
access the origin without being inspected first by Imperva.
Read More
• Onboarding: DDoS Protection for Individual IPs

• Settings: DDoS Protection for Individual IPs

Onboarding: DDoS Protection for Individual IPs

The Imperva IP Protection service provides the following options for DDoS protection at the IP level:
IP Protection over TCP/IP
For details, see Onboarding IP Protection over TCP/IP.
IP Protection over GRE or IP-in-IP
For details, see Onboarding IP Protection over GRE or IP-in-IP.
Read More
• Introduction: DDoS Protection for Individual IPs

Onboarding IP Protection over TCP/IP

The IP Protection over TCP/IP service provides complete DDoS protection at the IP level.
Use our self-service onboarding process to start your free trial or contact Imperva Sales to get started with the IP
Protection over TCP/IP service.
In this topic:
• Overview
• Start the free trial
• Open the IP Protection Settings
• Onboard IP Protection over TCP/IP
• API
Overview
IP Protection over TCP/IP is deployed as an always-on service. Traffic flow is symmetric, where both ingress and egress
traffic flow through the Imperva network. To provide IP level protection, Imperva “leases" a global anycast edge IP
address out of its own range to you and acts as your internet-facing IP. IP Protection over TCP/IP supports onboarding
using your origin IP address or by allowing Imperva to dynamically resolve the domain name or CNAME.
Permissions
When IP Protection over TCP/IP has been enabled for your account, the account admin can onboard IPs to the service.
To enable additional users to onboard IPs, the account admin can grant users the Edit Single IP permission.
Start the free trial
The free 14-day trial of IP Protection over TCP/IP includes up to two Protected IPs.
To start the trial, go the IP Protection page, as described below.

Open the IP Protection Settings
2. On the sidebar, click IP Protection > Settings.

Onboard IP Protection over TCP/IP
To onboard an IP, you can enter the IP address or the domain name.
1. On the Settings page, click Add Protected IP, and then select TCP Proxy (the default option).
2. Configure the details:

Enter a description, and the IP address or domain

name that you want to protect.
Origin Settings If you enter your domain name, Imperva resolves

the domain name to its associated IPs and
CNAME. Select the CNAME or IP that you want to
use.
You can select Enable Proxy protocol in order to

retrieve the IP addresses of visiting clients. The
proxy protocol enables Imperva to pass the client
IP address on to your destination application or
service by adding the proxy protocol header to
Advanced Settings
the request.
Note: Requires support of the Proxy Protocol on

the origin side. Do not activate this option if your
server does not support it.
Select the method for monitoring the connection

to your origin server:
▪ ICMP: Regularly sends ICMP echo requests

(ping) to the origin server. This is the
Monitoring Settings
default method.
▪ TCP: Attempts to establish a TCP
connection with the origin server on the
specified port. Triggered only when a
connection failure is suspected.
▪ None: Monitoring is turned off.
3. Click Create Protected IP.
Your new Imperva Edge anycast IP is generated and displayed on screen. This is the IP that you should now use for any
internet-facing access to your service.
If you onboarded using an IP address, you need to update your site's A record. The IP and instructions are also sent to
you by email.
To avoid direct access to your origin IP, we recommend whitelisting the Imperva IP Ranges in your firewall and
restricting access from any other source IP. The list of ranges is available here.
API
You can also onboard IP Protection over TCP/IP using the Imperva API. For details, see DDoS Protection for Networks
API.

Read More

• Settings: DDoS Protection for Individual IPs: View settings for your IP addresses that are configured for the
IP Protection over TCP/IP service.
• Security Dashboard: DDoS Protection for Networks and IPs: Explore metrics, examine emerging attacks in real-
time, or analyze past attacks.
• Analytics: DDoS Protection for Networks and IPs: View analytics data for traffic flowing to your IP or blocked by
Imperva.

Onboarding IP Protection over GRE or IP-in-IP

The IP Protection over GRE/IP-in-IP service provides DDoS protection at the IP level.
In this topic:
• Overview
• Onboard IP Protection over GRE or IP-in-IP
• Configure the tunnel
Overview
IP Protection over GRE or IP-in-IP is deployed as an always-on service and traffic flow is symmetric, where both ingress
and egress traffic flow through the Imperva network. To provide IP level protection, Imperva “leases” an IP address
out of its own range to the customer and acts as the customer's ISP (although the customer is still required to get
additional IP addresses from an ISP to which clean traffic is routed). In addition, a GRE or IP-in-IP tunnel has to be
established between the origin network and Imperva. The tunnel can be connected to different types of equipment on
the customer’s side, depending on the specific topology of the customer’s network. Such devices may include routers,
firewalls, load balancers and Linux servers (physical, virtual, and cloud instances).
Onboarding IP Protection involves the following steps:
1. Configuring your account in the Imperva Cloud Security Console.

2. Setting up a tunnel
3. Advertising the new IP address provided by Imperva to the end clients (usually through DNS).
4. Configuring a loopback interface on the device on which the tunnel is established.
Configuring a loopback interface
In order to process packets received through the tunnel connected to Imperva (and not drop the packets), the
operating system must recognize the destination IP of the packets as an IP address that is associated with one of the
interfaces. For that to happen, this address must be configured on the element in the system on which the tunnel is
established. A loopback can be defined on a physical or logical interface.
Note: Defining a loopback is common practice for networking equipment. It is typically used when a networking asset
must handle IP addresses that are not configured on any of its interfaces.

Onboard IP Protection over GRE or IP-in-IP
To onboard an IP, enter the IP address and configure the following details:
1. On the Settings page, click Add Protected IP, and then select GRE Tunnel or IPinIP Tunnel.

2. Configure the details:
Settings Description
Enter a description, and the IPv4 address that you

Origin Settings
want to protect.
The settings in this section enable Imperva to

select an appropriate security policy (stricter,
more lenient) during initial onboarding of the
specified IP.
Subsequently, Imperva will dynamically select

the appropriate security policy based on the
previous week's traffic to your origin.
Traffic bandwidth for origin IP: Enter the

Traffic Profile estimated traffic bandwidth that you expect for
your origin service.
Traffic distribution: Enter the estimated

distribution percentage per protocol type that
you expect for your origin service. The value for
all fields should total 100%.
IPsec protocol: Enable this option if the IP

Security protocol is used by your origin and you
want Imperva to support it.
Choose monitoring method: Select the method

for monitoring the connection to your origin
server:
▪ Tunnel Monitoring (ICMP): Periodically

sends ICMP echo requests (ping) to the
tunnel endpoint. This is the default
Monitoring Settings method.
▪ Origin Monitoring (ICMP): Periodically

sends ICMP echo requests (ping) to the
origin through the edge IP.
Email notifications: You can opt to receive email

notifications when the connectivity status of your
origin IP changes. Email notifications are sent to

Settings Description
the addresses defined in your account settings.
For details, see Account Settings.
3. Click Save.
Your new Imperva Edge anycast IP is generated and displayed on screen. This is the IP that you should now use for any
internet-facing access to your service.
To avoid direct access to your origin IP, we recommend whitelisting the Imperva IP Ranges in your firewall and
restricting access from any other source IP. The list of ranges is available here.
Configure the tunnel
At the end of the onboarding process, configuration details are displayed, and also emailed to you. Use the details
provided to configure the tunnel between Imperva and your origin.
See the following topics for assistance with configuring these commonly used routers:
• Set up a GRE tunnel on a Cisco router

• Set up a GRE tunnel on a Juniper router
• Set up a GRE tunnel on an Ubuntu AWS client
Read More

• Settings: DDoS Protection for Individual IPs: View settings for your IP addresses that are configured for the
IP Protection service over GRE or IP-in-IP.
Imperva.

Set up a GRE tunnel on a Cisco router

This topic describes how to set up a GRE tunnel on a Cisco router as part of onboarding Imperva DDoS Protection for
Single IPs.
In this topic:
• Prerequisite
• Step 1: Establish the GRE tunnel interfaces on the router
• Step 2: Deploy IP Protection
• Step 3: Configure policy-based routing
Prerequisite
Onboard your IP to Imperva in the Cloud Security Console according to the instructions here: Onboarding IP
Protection over GRE or IP-in-IP.
After you onboard your IP in the Imperva Cloud Security Console, Imperva provides you with three IP addresses,
labeled as follows:
• Imperva Public IP
• Imperva Private IP
• Origin Private IP
These IPs will be used together with your Origin Public IP to configure the GRE tunnel.
In addition, the Imperva Anycast IP is the new protected IP from Imperva that is allocated to your origin server and
used to send and receive filtered traffic.
Note: During configuration, make sure to replace the bold text shown in the examples with the actual IP values.
Step 1: Establish the GRE tunnel interfaces on the router
The first step is to configure your firewall device with the appropriate tunnel interfaces.
1. Make sure that no ACL is blocking GRE protocol (47) from the Imperva Public IP to the Origin Public IP.
2. Use the Cisco IOS command line interface (CLI) to access your router’s global configuration command mode.
3. At your router’s (config) prompt, define a new tunnel interface, as shown in this example. Make sure to
replace the values in bold,
Command syntax:
myRouter(config)# interface Tunnel 1

myRouter(config-if)# description GRE tunnel to Incapsula
myRouter(config-if)# ip address Origin Private IP
myRouter(config-if)# ip mtu 1476
myRouter(config-if)# ip tcp adjust-mss 1436
myRouter(config-if)# tunnel source Origin Public IP
myRouter(config-if)# tunnel destination Imperva Public IP

Note:
▪ Tunnel 1: You can specify any number, but Tunnel is a required component of the interface name. For
example, you can specify Tunnel 98.
▪ description: Enter any free text to make sure you can easily identify the interface.
▪ Origin Private IP, Origin Public IP, and Imperva Public IP: Replace these with the IP addresses.
▪ ip tcp adjust-mss 1436: Include this command to enable TCP maximum segment size adjustments. The
Imperva IP Protection service requires that the operating system of all of your network devices support
TCP MSS adjustments. Do not omit this command.
For more information, see MTU and MSS: What You Need to Know.
After configuring the router, the GRE tunnel should be up. You can verify it by pinging the Imperva Private IP.
Step 2: Deploy IP Protection
The next step is to configure the new, protected IP provided by Imperva on your server, or use network address
translation (NAT). Choose one of the methods below:
• Configure a static IP address

• Set up a GRE tunnel on a Cisco router
Configure a static IP address
Configure the Imperva Anycast IP on your server itself and ensure that traffic is directed toward it.
Static routing sends traffic from the Imperva Anycast IP to a fixed address for your server.
1. Configure the Imperva Anycast IP on your server, using the IP address provided by Imperva.
2. Configure a static route on your router device. This will direct traffic toward the Imperva Anycast IP.
The route’s next hop needs to point to an IP configured on your server. This IP is the one that belongs to your
local area network.
Command syntax:
myRouter(config)# ip route Imperva Anycast IP 255.255.255.255 next-hop-IP
next-hop-IP is the address used to reach the server, which is usually among the IPs configured on your server NIC
interface.
Configure NAT
Use network address translation (NAT) to translate the Imperva Anycast IP to the current IP address of your server.
With this method, you don’t need to configure the Imperva Anycast IP on the server itself.
There are two ways to configure NAT translation: Full network address translation of the entire address, and port
address translation (PAT) of specific ports. Choose one of the methods below:

NAT configuration:
1. On your router, configure network address translation from the Imperva Anycast IP to your current server IP.
myRouter(config)# ip nat inside source static current server IP Imperva Anycast IP exten
2. Then, make sure to specify which interfaces on the router are “internal” and which are “external”.
Command syntax:

myRouter(config-if)# ip nat outside
myRouter(config)# interface x/x(your WAN interface)

myRouter(config)# interface y/y(your LAN interface – toward the server)

myRouter(config-if)# ip nat inside
PAT configuration:
1. At your router’s (config-if)# prompt, configure port address translation that translates specific ports from the
Incapsula Protected IP to your current server IP.
myRouter(config)# ip nat inside source static tcp current server IP port_number _ Incapsula Protected IP
port_number extendable
2. Then, make sure to specify which interfaces on the router are internal and which are external.
Command syntax:

myRouter(config)# interface x/x(your WAN interface)


Step 3: Configure policy-based
myRouter(config-if)# ip nat insiderouting
If you want to use symmetric routing, you must, as a final step, configure policy-based routing to ensure a symmetric
flow. With symmetric routing, traffic directed to your network through the GRE interface must return through the
same interface.
Enter the following commands on your Cisco router to establish policy-based routing. Make sure to replace bold text
with actual values.
1. Enter the following commands to create an access list that will match traffic from the Imperva Anycast IP to
any destination:

myRouter(config)# ip access-list extended ACL name

myRouter(config-ext-acl)# permit ip host Imperva Anycast IP any
Note: If you configured NAT, use the current server IP address in the above configuration, instead of the
Imperva Anycast IP.
2. myRouter(config)# route-map route-map name permit 10

myRouter(config-route-map)# match ip address ACL name
myRouter(config-route-map)# set ip next-hop Imperva Private IP
myRouter(config)# route-map route-map name permit 20
3. Enter the following commands to apply the policy route to the LAN interface, where the server is connected.

myRouter(config-if)# ip policy route-map route-map name
Note:
• ACL name: The name of an access list to use for matching traffic sourced by the server and forwarded via the
tunnel. It must be the same in all instances.
• route-map name: The name of the route-map. It can be any value, but must be the same in all instances.
After completing this configuration, you can ping the server to start seeing traffic routed through Imperva.

Set up a GRE tunnel on a Juniper router

This topic describes how to set up a GRE tunnel on a Juniper MX router as part of onboarding Imperva DDoS
Protection for Single IPs.
In this topic:
• Prerequisite
• Step 1: Establish the GRE tunnel interfaces on the router
• Step 3 (Optional): Configure policy-based routing
Prerequisite
labeled as follows:
Step 1: Establish the GRE tunnel interfaces on the router
The first step is to configure your firewall device with the appropriate tunnel interfaces.
1. Make sure that no ACL is blocking GRE protocol (47) from the Imperva Public IP to the Origin Public IP.
2. Use the Juniper Junos command line interface (CLI) to access your router’s global configuration command
mode.
3. Enable the GRE service on the router.
Note: To configure a GRE tunnel on a Juniper network router, the router must be equipped with layer 2 service
capabilities. These capabilities are native in MX, SRX, and J-series routers, and are available through a physical
interface card (PIC) in M-series routers. When the required services are available on the router, you can create a
pseudo-interface called gr-.
To enable the service, issue the following command:
root@mx# set chassis fpc x pic x tunnel-services

In this command, fpc x pic x points to the interface module (line card) whose resources we want to share
for the purpose of tunneling.
4. At your router’s (configuration) prompt, define a new tunnel interface. Make sure to replace the values in
bold, as instructed below the example:
Command syntax:
root@mx# set interfaces gr-0/0/0 unit 0 description GRE tunnel to Imperva

root@mx# set interfaces gr-0/0/0 unit 0 tunnel source Origin Public IP
root@mx# set interfaces gr-0/0/0 unit 0 tunnel destination Imperva Public IP
root@mx# set interfaces gr-0/0/0 unit 0 family inet address Origin Private IP/30
Note:
▪ In each instance of gr-0/0/0 unit0, you can specify the unit number of the logical interface if other than 0.
▪ description: Enter any free text to make sure you can easily identify the interface.
5. Make sure you can ping the Imperva Private IP:
run ping Imperva Private IP

The next step is to configure the new, protected IP provided by Imperva on your server, or use network address
translation (NAT).
You can configure NAT on a Juniper device, although that is a more complicated method. For more information,
consult the Juniper documentation. Alternatively, you can configure NAT on some other device along the route.
This section demonstrates how to configure the new IP on the server.
Configure a static IP address
Configure the new, protected IP provided by Imperva on your server,
1. Configure the Imperva Anycast IP on your server, using the IP address provided by Imperva.
2. Configure a static route on your router device. This will direct traffic toward the Imperva Anycast IP. The route’s
next hop needs to point to an IP configured on your server. This IP is the one that belongs to your local area
network.
Command syntax:
root@mx# set routing-options static route Imperva Anycast IP next-hop next-hop-IP
next-hop-IP is the address used to reach the server, which is usually among the IPs configured on your server
NIC interface.

Step 3 (Optional): Configure policy-based routing

If you want to use symmetric routing, you must, as a final step, configure policy-based routing to ensure a symmetric
flow. With symmetric routing, traffic directed to your network through the GRE interface must return through the
same interface.
Enter the following commands on your router to establish policy-based routing. Make sure to replace the bold text
with actual values.
1. Configure policy-based routing:
root@mx# set firewall family inet filter TO_GRE term 1 from source-address Imperva Anyca
root@mx# set firewall family inet filter TO_GRE term 1 then next-ip Imperva Private IP
root@mx# set firewall family inet filter TO_GRE term 2 then accept
▪ The purpose of term 1 is to match traffic from the new IP and direct it to the GRE tunnel.
▪ The purpose of term 2 is to match all other traffic and route it normally by using the global routing table.
2. Apply the firewall filter on the LAN interface:
root@mx# set interfaces ge-fpc/pic/port unit 0 family inet filter input TO_GRE
ge-fpc/pic/port is the Junos syntax for configuring a ge (gigabit Ethernet) device with a Flexible PIC Controller
(fpc) address, a Juniper Physical Interface Card (pic) address, and a port number (port). For example, ge-0/0/0.

Set up a GRE tunnel on an Ubuntu AWS client

This topic describes how to set up a GRE tunnel on an Ubuntu AWS Linux instance as part of onboarding Imperva
DDoS Protection for Single IPs.
In this topic:
• Prerequisite
• Step 1: Establish the GRE tunnel
• Step 3: Configure policy-based routing
• Step 4: Final set up
Prerequisite
labeled as follows:
Step 1: Establish the GRE tunnel
The first step is to configure and activate a GRE tunnel on your AWS Ubuntu instance:
1. Use the Amazon EC2 console to determine the EC2 Public IP Address or the EC2 Elastic IP Address assigned to
your Ubuntu server instance.
2. In the AWS security policy, open port 1723 to the Imperva Public IP, and add it to a new Source entry in the
AWS Management Console, setting the TCP port to 1723.
3. Use SSH to connect to your Ubuntu server instance on AWS.
4. Use vim to open /etc/network/interfaces.d/eth0.cfg.
5. Add the following parameters to configure a GRE tunnel. Make sure to replace the bold text with actual values.
auto tun1
iface tun1 inet static
address Origin Private IP
netmask 255.255.255.252

pre-up iptunnel add tun1 mode gre local AWS Internal IP remote Imperva Public IP ttl 255
up ifconfig tun1 multicast
pointopoint Imperva Private IP
post-down iptunnel del tun1
6. After finishing the configuration, press esc :w! to save the file.
7. Bring up the tunnel with the following command:
sudo ifup tun1
8. Verify that the tunnel is operational by pinging the Imperva Private IP.
1. Configure the new Imperva Anycast IP on the loopback interface of your Ubuntu instance. This step is
mandatory.
sudo ip addr add Imperva Anycast IP dev lo
2. Confirm that you’ve successfully started the service and correctly configured all interfaces by issuing the
following command:
ip addr
Check the output against the following example, paying particular attention to the items highlighted in yellow.
In the example, 107.154.50.1/32 represents the Imperva Anycast IP.
Step 3: Configure policy-based routing

Configure policy-based routing to ensure a symmetric flow. With symmetric routing, traffic directed to your network
through the GRE interface must return through the same interface.
In this step, you configure the Ubuntu instance so that only traffic arriving on the tun1 interface is routed back to
Imperva. All other traffic is routed via your instance’s local link — the default route.
Run the following commands on the Ubuntu machine. Make sure to replace the bold text with actual values.

ip route add default via Imperva Private IP dev tun1 table 1

Step 4: add
ip rule Final setImperva
from up Anycast IP tab 1 priority 500
Add the following commands to the /etc/rc.local script on your Ubuntu instance so that it runs each time you
start the instance. These commands will bring up the tunnel, configure the new Imperva Anycast IP, and configure
policy-based routing.
sudo ifup tun1

sudo ip addr add Imperva Anycast IP dev lo
ip route add default via Imperva Private IP dev tun1 table 1
ip rule add from Imperva Anycast IP tab 1 priority 500
Press Esc:w! to save the file.

Settings: DDoS Protection for Individual IPs

View settings for your IP addresses that are configured for the IP Protection service, or onboard a new IP.
In this topic:

• Add an IP to the service
• View IP Protection settings
• Retrieve client IP addresses
• API

Add an IP to the service
To add an IP to the service, click Add Protected IP and fill in the information.
For more details on this self-service onboarding process, see:
• Onboarding IP Protection over TCP/IP

• Onboarding IP Protection over GRE or IP-in-IP
View IP Protection settings
Field Description
The name you assign to the service you want to

protect. If you do not assign a name, your origin IP
address or domain name is used.
Description
Click the description name to view additional
configuration details.
The Imperva global anycast Protected IP. This is the

Imperva Anycast IP IP to use for any internet-facing access to your
service.
Origin Public IP Your origin server IP or CNAME that is protected.
The Imperva IP protection method - Protected IP
Type
over TCP/IP, GRE, or IP-in-IP.
Protected IP over TCP/IP : Indicates if you have

Details
completed the required DNS changes for the
Protected IP.

Field Description
• Fully configured: The domain is fully
configured and resolves to the new IP.
• Pending: You have not yet updated your A
record.
Protected IP over GRE/IP-in-IP: Details on the

Imperva and origin IP addresses.
The connectivity status of your origin IP.
Possible values:
• UP
• DOWN
• MONITORING DISABLED (Protected IP over
TCP/IP only)
Note: The Protected IP over TCP/IP service monitors

Status
connectivity status according to the method defined
on the settings page, when adding or editing the IP.
By default, ICMP is used. For details on monitoring,
see Onboarding IP Protection over TCP/IP.
If you onboarded using your domain's CNAME,

Imperva dynamically resolves it to the associated
IPs, and uses them for load balancing. At least one of
the identified IPs must respond to the monitoring
request to show status as UP.
Retrieve client IP addresses

If you require the IP address of visiting clients, you can retrieve them by enabling the proxy protocol. The proxy
protocol enables Imperva to pass the client IP address on to your destination application or service by adding the
proxy protocol header to the request.
Note:
• Applicable to Protected IP over TCP/IP only.

• Requires support of the Proxy Protocol on the origin side. Do not activate this option if your server does not
support it.
To enable the proxy protocol:
1. In the IP Protection section, click the Description name for the protected IP you want to configure.
2. Under Advanced Settings, select Enable Proxy Protocol.

API
You can also onboard and edit IP Protection settings for Protected IP over TCP/IP using the Imperva API. For details,
see DDoS Protection for Networks API.
Read More
Imperva.

Protected IP API
Onboard your IP addresses to the Imperva DDoS Protection for Individual IPs service and manage their configuration
using the API.
Authentication
In order to use the API, the client must be authenticated by Imperva. To authenticate, send your API ID and API key
using the x-API-Key and x-API-Id headers.
You can create and manage API keys with granular permissions and sub account access. For details, see API Key
Management.
Protected IP API Definition
For instructions on using the Protected IP API, see Protected IP API.
The definition file presents a full, formatted, and interactive version of the Protected IP APIs that you can use to learn
See also:

• Onboarding: DDoS Protection for Individual IPs

Protected IP API Definition


Security Dashboard: DDoS Protection for Networks and

IPs
Explore metrics for traffic flowing through Imperva to your protected networks or IPs. View statistics for your
monitored IP ranges. Examine emerging attacks in real-time, or analyze past attacks up to 90 days back. Gain visibility
into bandwidth volume, packet rate, traffic type, and PoP utilization.
The displayed data reflects all ingress traffic — from clients to your origin network.
In this topic:
• Open the dashboard

• Dashboard at a glance
• Select a view
• View bandwidth and packet rate graphs
• View real-time data
• View historical data
• Check connection status
• Filter the graphs
• Drill down to a specific IP range
• Divert/revert an IP range on demand
• View the Event Log
• Analyze the data

Open the dashboard

2. For protected and monitored networks:
1. On the sidebar, click Network Protection > Dashboard.
2. Click the Security tab.
3. For protected IP addresses: On the sidebar, click IP Protection > Dashboard.

Dashboard at a glance
View protected IPs, IP ranges, or monitored ranges
Filter the graphs

Zoom in
View passed, blocked, or total traffic

Switch the format of displayed data
View real-time or historical data

Check connection status
Select a view
Select options for viewing bandwidth and packet rate data. Your selections are reflected in the data displayed in the
bandwidth graph (bits per second) and packet rate graph (packets per second), and in the tables below the graph.
Main view
View data for your protected IPs, protected IP ranges, or monitored ranges.

Network Protection Security Dashboard:
IP Protection Dashboard:
Note: For accounts with sub accounts:
• In the parent account, the Dashboard presents the data of the parent account and all of its sub accounts.
• In a sub account, the Dashboard presents the data of the specific sub account only.
Infrastructure Protection service: For network level

DDoS protection. View metrics for your networks or
Protected Networks
sub networks that are protected by Imperva from
network layer DDoS attacks.
Infrastructure Monitoring service: The IP ranges that

are monitored by Imperva to automatically detect
Monitored Networks
attacks and activate the on-demand Infrastructure
Protection service.
IP Protection service: For IP level DDoS protection.
View metrics for your IP addresses that are
Protected IPs
protected by Imperva from network layer DDoS
attacks.
View by
Overall All traffic.

View traffic distribution by protected IP range.
Ranges
Displayed when main view selection is IP Ranges.
View traffic distribution by protected IP. Displayed
IPs
when main view selection is IP Protection.
PoP The global distribution of all incoming traffic across

Imperva PoPs.

For the list of PoP codes and locations, see Imperva

The breakdown of packet types by common

Traffic Type
protocols and attack vectors.
Traffic
Passed traffic and blocked traffic are displayed

All
separately in the graphs.
The sum of passed and blocked traffic is displayed
Total
as a unified graph.
Clean traffic that is routed through Imperva and
Passed
passed on to your protected network.
Blocked DDoS traffic that was blocked by Imperva.
View bandwidth and packet rate graphs
View bandwidth and packet rate data in side-by-side graphs.
Hover over the graph to focus in on a specific point in time.
In the bandwidth (bits per second) graph, you can compare your data to the blue 95% percentile indicator. The
indicator is displayed when you select the following view settings:

2. Traffic > All
For more details on calculation of the 95th percentile, see Account Bandwidth Calculation.

View real-time data

By default, the Dashboard graphs display real-time data. Data resolution is 3 seconds.
Note: The Real-Time view on the Network Protection and IP Protection Dashboards is not yet supported in sub
accounts. You can see real-time data when you drill down into a specific range or IP. For more details on the Analytics
Dashboard, see Analytics: DDoS Protection for Networks and IPs.
Select a filter option to zoom in to a specific time frame in the graph.
Or drag the handles on the navigator below the graph.
View historical data

You can view data for the previous 90-days. Select an option, or choose a custom time period.

You can zoom in to a maximum data resolution of 15 seconds to analyze short attacks.
Click and drag an area of the graph to zoom in. Grab another area to zoom in further.
When zoomed out in the historical graphs, each data point represents the peak values for the time range it covers,
such as for the 15 minutes shown in this example.
Check connection status

Check the connection status of your protected networks or IPs. Available in real-time view only.
Infrastructure Protection:

IP Protection:
Connection status is displayed in the following format: Connections up x/y (z)
Green: All connections are up. This status is also

displayed when monitoring is disabled for all
Connections up connections.
Red: At least one connection is down.
The number of active connections out of the total

x/y
number of connections.
The number of connections for which monitoring is
z disabled. This is not displayed if monitoring is
enabled for all connections.
Displays connection status for each connection.
Details

In this example, 16 of a total of 20 connections are up, and monitoring is not disabled for any of the connections.
Here, there are two connections. Monitoring for both connections is disabled.
Filter the graphs
In the legend below a graph:
Click an item to show data for that item only.
To multi-select or clear specific items from the

view, use Alt+click.
Legend
To select all, double-click an item in the legend.
At the bottom of the graph:
Toggle to show actual values or percentage.
Show values/distribution
Values: Bandwidth in bps. Packet rate in pps.
Distribution: View each PoP, IP range, or traffic type

as a percentage of the total traffic.

Drill down to a specific IP range

In the Ranges table, you can view maximum bandwidth and packet rate for all IP ranges, or filter for a specific IP
range.
Click an IP range to drill down and display data on the dashboard for that range only.
Note: When viewing historical data and filtering for either passed or blocked traffic, you can select up to a total of 5
IP ranges to view and compare. In the Ranges table, select the ranges you want and then click Apply Selection. The
data is updated in the graphs.
Status: Displays attack status information for the last 90 days regardless of the time period selected at the top of the
dashboard.
More: Click to zoom in on analytics for the range. For a range with a previous attack or currently under attack, a
focused view of analytics data for the attack is displayed. For more details, see Analytics: DDoS Protection for
Networks and IPs.
Account: If the range is defined in one of the account's sub account, a link to the sub account is provided.
Divert/revert an IP range on demand
If your account is working in on-demand or contingency mode, you can divert and revert your ranges as needed.
Note:
• This feature is available for accounts working in on-demand or contingency modes only.
• Only ranges whose diversion is controlled by Imperva are displayed. If you are controlling your ranges, by
starting/stopping BGP advertisement or adding/removing the "no-export" community, those ranges are not
displayed.
The On-Demand Diverted Ranges widget displays the number of currently diverted ranges, and time remaining until
the range is automatically reverted.
• If a range has been diverted for longer than 72 hours, Upcoming revert pending is displayed.
• For accounts working in on-demand mode with unlimited diversions: If you have multiple ranges diverted, the
revert time of the first range due to be reverted is displayed. You can view revert times for all diverted ranges
inside the configuration screen.
Click Configure to divert or revert a range. If you are working in contingency mode, you can also see the number of
remaining diversions available in your account.
• Monitored tab: Your onboarded ranges that you can choose to divert.
• Diverted tab: View the ranges that are currently diverted and routed through Imperva, or revert a range back to
your network.

If needed, you can extend the diversion for another 72 hours.
When you divert or revert a range, an event is logged and displayed in the Event Log table in the dashboard.
For more details on on-demand range diversions, see Control Network Range Diversions.
View the Event Log
View the log of security events detected by Imperva.
Service Event Description

Connection up (GRE Tunnel/ECX/ BGP peer connectivity status has
Network Protection
Cross Connect/..) changed to UP.
Connection down (GRE BGP peer connectivity status has

Tunnel/ECX/Cross Connect/..) changed to DOWN.
Imperva has detected a DDoS

attack and has started mitigation.
(See SLA for further details.)
A start event is generated when

DDoS event has started
30% of total traffic is blocked
during a period of 5 minutes. The
time stamp displayed in the log is
therefore 5 minutes after the
actual start of the attack.
The DDoS attack has ended.

Imperva has stopped mitigation.
(See SLA for further details.)
A stop event is generated when

DDoS event has ended
there is no blocked traffic for a
period of 3 hours. The time stamp
displayed in the log is therefore 3
hours after the attack actually
ended.
The IP range has been diverted

and traffic is being routed through
the Imperva PoPs. This event is
IP range diverted generated when the diversion is
triggered either by Imperva or by
an account user in the Cloud
Security Console.
The IP range has been reverted
back and traffic is no longer being
IP range reverted
routed through the Imperva PoPs.
This event is generated when the

Service Event Description

revert is triggered either by
Imperva or by an account user in
the Cloud Security Console.
Netflow/sFlow monitored traffic is
Network Monitoring NetFlow traffic has stopped not being received. DDoS
monitoring is currently inactive.
NetFlow traffic has started being received properly. DDoS
monitoring is active.
Incorrect NetFlow traffic invalid. DDoS monitoring is
currently inactive.
Monitored traffic indicated a DDoS
attack is in progress.
GRE tunnel monitoring was able to
IP Protection IP is up verify that tunnel status is UP. The
protected IP is available.
GRE tunnel monitoring was unable
IP is down to verify tunnel status. The IP may
be down.
Tip: Click Export to CSV to download the event log.

Analyze the data
Take a closer look at an emerging attack in real-time, or analyze a past attack.
What should I look at? What can it tell me?
• A straightforward view of traffic volume on

your entire infrastructure.
Overall view
• Understand whether an attack took place or is
currently underway anywhere on the network.
• Traffic volume trends for each of your network

prefixes.
IP range view
• Understand which specific prefix had a spike
in traffic and/or experienced an attack.
• Traffic volume trends for different protocols

across your infrastructure.
Traffic type view
• Understand which type of attack vector was
used and what traffic was passed or blocked.

What should I look at? What can it tell me?
• Traffic volume trends for any or all Imperva

PoPs that help handle ingress traffic.
PoP view
• Understand the location in the world where
the attack is concentrated.
• Different attack vectors may vary in intensity

Compare side-by-side bandwidth and packet rate
of bits (e.g. amplification attacks such as
graphs
SSDP) or intensity of packets (e.g. SYN flood).
Tip: Filter to see blocked traffic only. Attacks can be multi-vector; filter out the traffic type with the highest value to
discover other activity.
Example:
1. Look at overall traffic.
2. Zoom in on the time frame of an attack.

3. Switch to View by: Ranges.
4. Check the graph or IP ranges table to identify the range most impacted by the attack.

5. Click the specific range in the IP Ranges table to drill down for a closer look.
Read More

• Notifications
• Monitor your security posture on the go. For details, see Imperva Security Mobile App.

Performance Dashboard: DDoS Protection for Networks

The DDoS Protection for Networks Performance dashboard provides visibility into the performance of the
connections between Imperva data centers and your origin network.
Visible spikes, or high values seen over time may indicate an area that requires further examination.
In this topic:
• Open the performance dashboard

• View the performance metrics
• View tunnel connections
• Share the dashboard view
• Performance Monitoring API
Open the performance dashboard
Prerequisite: Enable and configure performance monitoring. For details, see Configure performance monitoring.
2. On the sidebar, click Network Protection > Dashboard.
3. Click the Performance tab.

View the performance metrics
The graphs display data for GRE tunnel connections that have performance monitoring enabled. Up to 3 connections
can be displayed simultaneously.
The data in the graphs reflects the time range selected at the top of the dashboard. You can select a predefined time
range or define a custom range of dates.
Each data point represents the maximum value seen during the time range specified for the data point. Hover over the
graph to view more details for each data point.
Note:
• For time periods where Performance Monitoring was not enabled, or the Performance Monitoring (PM) servers
did not send ICMP echo requests due to a server failure, no data points are displayed in the graphs.
• If the PM servers sent ICMP echo requests but did not receive replies for the entire data point period, data points
in the Packet Loss graph display the value 100% and the Latency and Jitter graphs do not display any data
points.
Filter:

• Click connection names in the legend below the graphs to filter the data displayed in the graphs.
• In the Origin Connectivity table, select or clear connections. The data displayed in the graphs is updated.
Zoom: Click and drag an area of a graph to zoom in, to a maximum resolution of one minute. Zooming in on any graph
updates the data displayed in the graphs and in the Origin Connectivity table. To reset the view, select an option from
the time range filter.
Metric Description
All Displays all graphs.
Latency The time delay for arrival of network traffic.
The variation in the arrival time between data

Jitter
packets.
The percentage of packets that failed to reach their

Packet Loss
destination.
View tunnel connections

This table displays additional details about your connections, and enables you to choose which connections are
reflected in the graphs above.
To display data for one or more specific connections, select the connections and click Apply Selection. You can select
up to 3 connections. The dashboard graphs above are then refreshed to show data for the selected connections only.
Note:
• Connections that appear greyed out do not have performance monitoring enabled and cannot be selected.
• Empty data points, where ICMP echo messages were not sent, are excluded from the calculation of the Latency,
Jitter, and Packet Loss average values.
Column Description
The connection name, as defined on the
Name
Imperva Data Center The Imperva data center defined for the connection.
The average latency value for the selected time
Latency (Average)
range.
Jitter (Average) The average jitter value for the selected time range.
The average percentage of packet loss for the
Packet Loss (Average)
selected time range.
Monitoring State
Indicates if performance monitoring is enabled.

Column Description
If monitoring is disabled, statistics are not collected
for the connection.
For instructions on enabling performance

monitoring, see Configure performance monitoring.
Share the dashboard view

There are several options for sharing the current view displayed on the dashboard.
Exports an image of the current view of the

Export to PDF
dashboard in PDF format.
You can copy the dashboard URL to share the
current view with others. The URL is based on your
Copy URL current filter selections. The recipient must be
logged in to the Cloud Security Console to view the
data.
Performance Monitoring API
You can also retrieve performance statistics using the API.
For instructions on using the API, see DDoS Protection for Networks: Performance Monitoring API Definition.
See also:
• Configure Performance Monitoring: DDoS Protection for Networks
• Add a GRE tunnel connection

DDoS Protection for Networks: Performance Monitoring

API Definition

Analytics: DDoS Protection for Networks and IPs

See top traffic patterns for DDoS traffic on your network that was blocked by Imperva or clean traffic that was routed
through Imperva and passed on to your network.
View a breakdown of traffic by source or destination IP, by source or destination port, or by packet size for a specific
IP range.
In this topic:
• View the analytics

• View analytics by region
• Customize the view
• Example
• Download analytics data
View the analytics
You can access the analytics data in several ways:
At the top of the Network Protection Dashboard, a

For a specific event
banner is displayed indicating that there were
recent DDoS attacks on your network.

1. Click Jump to Events Log.
2. In the Event Log table, in the Additional Info

column, click the Analyze attack button to
drill-down into a specific event.
Tip: Filter the Event column for the value

DDoS event has ended to view all events with
Analytics data.
On the drill-down page that opens, analytics data for

blocked traffic is displayed in the Top Traffic
Patterns section.
1. On the Network Protection Dashboard, select

a view.
For a specific time range

2. In the Ranges or IPs table, click an IP range or
a single IP.
3. On the drill-down page that opens:
1. From the date filter, select a previous

time period or a custom time period.
Analytics are not displayed in real-time
view.

2. Filter to display blocked or passed

traffic. (Not applicable to Monitored
Ranges view, which displays passed
traffic only.)
Analytics data is displayed below in the Top Traffic

Patterns section.
Infrastructure Protection Analytics show the highest peak values and highest average values for the selected IP or
range during the selected time period.
For a closer look, zoom in on an area on the Bits Per Second or Packets Per Second graphs at the top of the page. You
can zoom in to a maximum resolution of 15 seconds.
The selection is reflected in the analytics widgets below.
View analytics for the following:

• Source and destination IP addresses

• Source and destination ports
• Packet sizes
• New connections per second - incoming connections from clients to the customer origin and outgoing
connections from the origin.
• Concurrent connections (available for Protected IPs only)
View analytics by region
Once you have displayed the analytics according to the steps above (View the analytics), you can also filter by data
storage region.
In the filter box, under Region, select a data storage region.

By default, analytics are displayed for the region that is currently configured for your account. The drop-down
displays all regions that were configured for your account at some time during the previous 90 days.
For more details on data regions, see Data Storage Management.

Customize the view
Select a two-column or four-column layout for the

widgets on the page.
Layout
For each widget you can select table or graph view.
Widget view
View the highest peak or average values for the

selected time period.
Peak/Average

View the distribution of traffic for the highest values

during the selected time period.
Click Previous/Next to see all values.

Table view
Values over 10% are displayed in bold.
Multiple small values are clustered together under

the label Highly Distributed.
View the distribution of traffic for the highest values

during the selected time period.
Hover over a point in the graph for more details.
Filter the view to zoom in on specific elements using

the legend under the graph. For more details on
filtering, see Security Dashboard: DDoS Protection
for Networks and IPs.
Use the up/down arrows to view the full list of items

displayed in the graph.
Graph view
Example
Among the top peaks in traffic that occurred during the last 24 hours, we see that there was 244.86M blocked from IP
172.23.131.3, which represents 29% of the blocked traffic at that specific point in time.

In this example, one of the highest peaks was one in which 100% of the traffic was directed at and blocked from IP
172.23.131.3.

Download analytics data

Download analytics data in .csv file format:
• For any widget:
• For all top traffic pattern tables:
The data is downloaded into a single file, according to the value type selected in the tables - peak or average.
Read More

DDoS Protection for Networks and IPs: Sub Account

Support
DDoS Protection for Networks and Individual IPs services support sub accounts, enabling you to simplify the
management of enterprise accounts and manage user access.
Note: For general information on sub accounts and role-based access, see Manage Account Resources.
In this topic:
• Enable settings for sub accounts

• Connectivity settings
• Protection settings
• Flow monitoring settings
• View traffic metrics
• Move assets between accounts
Enable settings for sub accounts
To manage your DDoS Protection for Networks and Individual IP assets at the sub account level, enable one or both of
the following options, located in Account Settings:
Note:
• These options are displayed only in accounts subscribed to at least one of the Network Security DDoS
Protection services.
• You cannot disable these options when there are DDoS Protection assets defined in the sub accounts.
Option Description
This option enables you to:
Enable protection and monitoring settings for sub • create assets in sub accounts (note that some
accounts DDoS Protection for Networks assets are
created by the Imperva team at your request
during onboarding, such as Protected
Networks.)

Option Description
• move existing assets between the parent
account and its sub accounts, and between
the sub accounts
This option enables you to create connections in sub

accounts.
Traffic for ranges defined in a sub account then

passes only through the connections defined in the
specific sub account.
Enable connectivity settings for sub accounts
Note: This option can only be enabled when the
Enable protection and monitoring settings for sub
accounts option is selected.
For more details, see Connectivity settings below.
Permissions
To view and manage DDoS Protection assets in your account's sub accounts, you need the following permissions:
• Manage account sub accounts
• Edit single IP
• View Infra Protect settings
Notifications
Notifications of events related to a sub account's assets are sent according to the specific sub account's notification
settings.
For more details on notifications, see:
• Notifications
• Notification Settings
SIEM log events
SIEM events for a sub account are sent to the S3 bucket defined for the sub account.
For more details on the SIEM log integration, see SIEM Log Integration: DDoS Protection for Networks and IPs.
Connectivity settings
You configure connections on the Connectivity Settings page. For details, see Connectivity Settings: DDoS Protection
for Networks.

There are 2 modes of configuring connections between Imperva and your origin network. You must choose only one
of these for your account:
Mode Description
Configure connections on the Connectivity

Settings page in the parent account only.
Connections defined in the parent account can then

Configure connections in the parent account and be shared by the parent and sub accounts, while
use them in both the parent account and sub isolating the management of network ranges to
accounts. specific sub accounts.
Traffic for ranges defined in both the parent and sub

accounts is passed through the connections defined
in the parent account.
If you enable the Enable connectivity settings for

sub accounts option in Account Settings, you can
configure connections on the Connectivity Settings
page in the parent account or in any of its sub
accounts, as follows:
• Connections created in the parent account are

used only in the parent account. Traffic for
Configure separate connections in the parent
ranges defined in the parent account passes
account and in sub accounts.
only through connections defined in the
parent account.
• Connections created in a sub account are used

only in the specific sub account in which they
are created. Traffic for ranges defined in a sub
account passes only through the connections
defined in the specific sub account.
Protection settings
Protected Networks (ranges) can be configured in a parent account or in its sub accounts. They are configured by
Imperva during your onboarding process.
A range can be defined by the onboarding team for a specific sub account. Once configured, you can view the details
on the Protection Settings page in the sub account (Network > Network Protection > Protection Settings).
Flow monitoring settings
You can view and configure exporters for flow-based monitoring on the Flow Monitoring Settings page in your
account and sub accounts (Network > Network Protection > Flow Monitoring Settings).

View traffic metrics

In the parent account, the Network Protection and IP Protection dashboards present the data of all DDoS Protection
assets configured in the account and all of its sub accounts. For assets configured in a sub account, the Ranges and
IPs tables indicate the sub account to which a range or IP belongs.
In a sub account, the dashboards present the data of the specific sub account only.
Note:
• Limitation: The Real-Time view on the Network Protection and IP Protection Dashboards is not yet supported in
sub accounts. You can see real-time data when you drill down into a specific range or IP. For more details on the
Analytics Dashboard, see Analytics: DDoS Protection for Networks and IPs.
• Events for a given asset are displayed in the Event Log table of the dashboard in the relevant sub account only.
• If an asset was moved from the parent account or another sub account, events that occurred before the move
remain in the previous account.
Move assets between accounts
You can move your DDoS Protection assets between the parent account and its sub accounts, or between the
account's sub accounts.
• Protected IPs
• Protected networks
• Connections between Imperva's network and your origin network, along with their associated resources
(routing options, ASNs).
• Flow exporters
Moving these assets does not cause any downtime.
This functionality is available via the API. For instructions, see Asset Migration API Definition. The definition file
presents a full, formatted, and interactive version of the APIs that you can use to learn about the APIs, or test them
using your API ID and key. You can also download the definition file.
Limitation: You cannot move a protected network or IP that is sharing a security or detection policy with another
protected network or IP. These are internal policies configured by Imperva. If you receive an error message about this
issue when running the API, contact Imperva Support for assistance.
See also:

• Sub Accounts Page

• View Account Usage

Asset Migration API Definition

Asset Management API Definition


DNS Protection
Imperva's DNS solutions protect you from attack, while providing DNS acceleration and load reduction benefits.
Primary Managed DNS
An end-to-end service as DNS hosting provider, offering you complete management of your DNS configuration within
Imperva.
as protecting you from Volumetric and DNS DDoS attack. With this solution, your DNS service is hosted within
Imperva.
Protected DNS
Imperva protects your DNS servers from attack and improves performance through DNS caching.
Imperva serves as a DNS proxy, where DNS queries are first processed by Imperva to filter out DDoS attacks before
being forwarded to your origin name server. With this solution, your DNS service is hosted outside of Imperva.
For more details, see How the Protected DNS solution works.
Benefits
• Protection from volumetric and DNS DDoS attack
• Increased performance, reducing DNS queries response time via Imperva’s global anycast network
• Easy onboarding via UI and API
See also:
• DNS Protection API Definition

Onboard DNS Protection

Onboard and manage your DNS zones.
To learn more about Imperva DNS Protection, see DNS Protection.
In this topic:
• Open the DNS Zones page

• Add a DNS zone
• View or edit your DNS zones
• Configuration status
• Export the DNS Zones table
• DNS Protection API

Open the DNS Zones page
2. On the sidebar, click DNS > DNS Zones.

Add a DNS zone
To add a new DNS zone to Imperva, click the Add DNS zone button and select an option. For full details, see:
• Add/Edit a Primary Managed DNS Zone

• Add/Edit a Protected DNS Zone
View or edit your DNS zones
Column Description
The DNS zone name.

DNS Zone
Click the name to view or edit the settings for the
DNS zone.
Type Managed DNS or Protected DNS
The configuration status of the DNS zone in Imperva.

Status
Pending domain validation: You are required to
verify your domain ownership by adding a txt
record, provided by Imperva, to your DNS settings.

Column Description
Pending NS validation You are required to update
the name servers in your domain registrar. Once the
change is completed, DNS queries are routed to
Imperva DNS servers. It may take up to 48 hours for
the change to propagate world-wide.
Fully configured
For more details, see Configuration status.
Click for more options to edit or delete the

DNS zone.
More options
Note: You cannot add another DNS Zone with the
same name within 24 hours of deletion.
Configuration status
After adding your DNS zone to Imperva, the configuration status of the zone is displayed in the table.
For more details and instructions on how to complete the required configuration changes, click the DNS Zone name to
view the settings for the DNS zone.
Under DNS zone details, the status and instructions are displayed. Imperva regularly checks the configuration status.
You can click Verify now to trigger an immediate check.
Export the DNS Zones table
Click the Download CSV button at the top of the page to download the table in CSV format.
DNS Protection API
You can also configure and manage DNS zones using the API.
For instructions on using the Protected DNS Zones API, see DNS Protection API Definition.
The definition file presents a full, formatted, and interactive version of the Protected DNS Zones APIs that you can use
to learn about the APIs, or test them using your API ID and key.

Add/Edit a Primary Managed DNS Zone

To get started with Imperva DNS Protection, add your DNS zones.
Note: Onboarding a domain that is DNSSEC enabled is not currently supported by the Imperva Managed DNS service.
Managed DNS is an end-to-end service as DNS hosting provider, offering you complete management of your DNS
configuration within Imperva.
as protecting you from Volumetric and DNS DDoS attack. With this solution, your DNS service is hosted within
Imperva.
In this topic:
• Add or edit a Managed DNS Zone

• General information settings
• DNSSEC
• DNS Records
• Complete DNS zone configuration
Add or edit a Managed DNS Zone
You can add and edit Managed DNS zones from the Protected DNS Zones page.
To add a new zone:
1. Click Add DNS Zone and select Managed Primary DNS zone.
2. Select one of the options:
▪ Import your zone file: Upload a zone file in BIND format. Intended for websites with a large number of
records.
▪ Manual entry: Fill in the details below.
To edit an existing zone: Click the DNS Zone name.

General information settings

Field Description
DNS zone type Managed DNS
The name of the DNS zone you want to configure in

Imperva.
DNS zone name
For example, example.com
DNS zone owner The email address of the owner of the DNS zone.
Available only when editing an existing DNS zone.
Enables you to check the configuration status of the

Verify now DNS zone, and view the configuration instructions.
Status is also automatically verified by Imperva at

regular intervals.
DNSSEC
Domain Name System Security Extensions (DNSSEC) adds a layer of security by authenticating DNS responses to
Once your managed DNS zone is fully configured in Imperva, you can go ahead and configure DNSSEC.
When you enable DNSSEC, Imperva digitally signs your zone, publishes your public signing keys, and generates your
DS record. In addition, Imperva regularly rotates your zone signing key (ZSK) to ensure your zone security.
Note:
• The DNSSEC configuration options are not displayed until the zone is fully configured.
• If DNSSEC is already enabled for this DNS zone in your registrar, you need to first disable it at the registrar before
enabling it in Imperva.
To enable DNSSEC for a managed DNS zone:
1. On the Add/Edit Managed Primary DNS Zone page, under DNSSEC, click the toggle to enable DNSSEC.
2. Add the DS record details provided by Imperva (under DS Record Information) at your registrar to complete the
configuration. Your website may be inaccessible if the DS record is incorrectly configured at your registrar.
Tip: Click the copy icon in each field to copy the string.
Additional options:

• Verify now: Imperva regularly checks the DNSSEC configuration status with the registrar. You can click Verify
now to trigger an immediate check.
• Cancel DNSSEC: If you want to disable DNSSEC in Imperva, first remove the DS Record from the registrar.
Disabling DNSSEC before removing the DS record from the registrar will result in an unspecified period of
outage and unavailability. Therefore, Imperva will not disable DNSSEC until we verify that the DS record was
removed from the registrar.
DNS Records
Add DNS records for your DNS zones.
To add a new DNS record, click Add new record and fill in the requested details.
To edit, duplicate, or delete a DNS record, click more options in the DNS Records table.
Field Description
Specify a host name for this DNS record. For

Host name
example, www.example.com
The DNS record type. For example A record or

CNAME record.
Type
Supported types: A, AAAA, NS, MX, TXT, CNAME, SRV,
PTR, CAA, NAPTR
Value The IP address or CNAME for the specified host.
Select a TTL value from the list for the specified DNS
record type.
TTL (Time to live) defines the length of time this

TTL
record can be stored in a DNS resolver cache before
a fresh one must be requested.
Default value: 1 hour
Description (Optional) Add a description for the DNS record.

Advanced settings
Expand the Advanced Settings section to change default options or configure the additional settings described
below.
Security Settings
Rate Limiting

Rate limiting is activated when the incoming DNS query rate passes a certain threshold, indicating that you are likely
under attack.
Option Description
Queries for this DNS zone will not be served.
Block DNS Zone Caution: This option blocks all DNS traffic for the
zone and may cause your web service to become
unavailable.
Legitimate queries below this rate are answered.
This rate is calculated globally across all Imperva

Maximum incoming query rate
DNS proxy servers.
Default value: 100 queries per second
TTL (Time to live) settings
Set TTL values for how long the DNS resolver can store responses.
Option Description
The length of time for the DNS resolver to cache a

DNS response before requesting a new one.
Default TTL value
The length of time for the DNS resolver to cache a

negative DNS response - where the information on
the requested domain is unknown or does not exist -
Negative Caching TTL value
before requesting a new one.
Complete DNS zone configuration

When you onboard a new DNS zone and save your settings, you are presented with instructions for completing two
additional steps:
• Validate ownership of your domain by adding a TXT record to your DNS settings with the value provided.
• Update the name servers in your domain registrar using the values provided.
You can choose to make the changes and then click Check configuration, or decide to make the changes later.

To view the domain configuration instructions at a later time:
On the DNS Zones page, click the DNS zone name to view your zone settings. Under General Information, click Check
Status. The status and instructions are displayed.
See also:
• To manage your DNS after onboarding, see Onboard DNS Protection.

• To manage your Protected DNS Zones via the API, see DNS Protection API Definition.

Add/Edit a Protected DNS Zone

To get started with Imperva's DNS Protection service, add your DNS zones.
Protected DNS protects your DNS servers from attack and improves performance through DNS caching.
Imperva serves as a DNS proxy, where DNS queries are first processed by Imperva to filter out DDoS attacks before
being forwarded to your origin name server. With this solution, your DNS service is hosted outside of Imperva.
In this topic:
• Add or edit a Protected DNS Zone

• General information settings
• Complete DNS zone configuration
• Purge the cache
• DNSSEC compliance
Add or edit a Protected DNS Zone
You can add and edit Protected DNS zones from the DNS Zones page.
To add a new zone: Click Add DNS Zone and select Protected DNS zone (proxy). Fill in the required details.
To edit an existing zone: Click the Domain Name field.

General information settings
Field Description
The name of the DNS zone you want to configure in

Imperva.
DNS zone name
For example, example.com
Available only when editing an existing DNS zone.

Verify now
Enables you to check the configuration status of the
DNS zone, and view the configuration instructions.

Field Description
Status is also automatically verified by Imperva at
regular intervals.
Advanced settings
Expand the Advanced Settings section to change default options or configure the additional settings described
below.
DNS Settings > DNS Mode
Select a DNS mode to determine how DNS queries for this zone are handled by Imperva.
Option Description
Default Legitimate queries for this DNS zone are answered.
Block Queries for this DNS zone are not answered.
Queries for this DNS zone bypass Imperva and are
Bypass
served directly by your origin.
Security Settings > Rate Limiting
The rate limiting settings determine how Imperva handles DNS queries for the DNS zone when the incoming DNS
query rate passes a certain threshold, indicating that you are likely under attack.
• The rate limits on outgoing queries are only used after the Maximum incoming query rate is passed.
• Queries are forwarded to your origin DNS server only when they are not located in the Imperva cache.
Option Description
Legitimate queries below this rate are answered.
This rate is calculated globally across all Imperva

Maximum incoming query rate
DNS proxy servers.
Default value: 100 queries per second
For rates above the upper threshold, queries are

Rate limit on outgoing queries - Upper Threshold served from the cache only. No queries are
forwarded to your origin DNS server.
For rates between the lower and upper thresholds,

Rate limit on outgoing queries - Lower Threshold only queries for names in the Safe Record Names
list (that you can define below) are forwarded to
your origin DNS server. Other queries are dropped.

Option Description
For rates below the lower threshold, all queries that
do not have cached responses are forwarded to your
origin DNS server.
Example:
Safe Record Names
Requests for addresses with these prefixes are answered until the request rate passes the upper rate limiting
threshold defined above.
To add another prefix, click Add new record and enter a name.
Override Origin NS Records
When you onboard a domain to DNS Protection, Imperva automatically detects your DNS servers. You can opt instead
to provide the details of your DNS servers in this section, and then the automatic detection is not carried out.
To add an NS record, click Add new record and enter a record name.
Complete DNS zone configuration
When you onboard a new DNS zone and save your settings, you are presented with instructions for completing two
additional steps:
• Validate ownership of your domain by adding a TXT record to your DNS settings with the value provided.
• Update the name servers in your domain registrar using the values provided.

You can choose to make the changes and then click Check configuration, or decide to make the changes later.
To view the domain configuration instructions at a later time:
On the DNS Zones page, click the DNS zone name to view your zone settings. Under General Information, click Check
Status. The status and instructions are displayed.
Purge the cache
If you have made changes to your system and prefer not to wait for the caching period to expire, you can purge the
entire DNS cache, or purge only a subset of the zone's cached records.
Note: The purge settings are available only when editing an existing DNS zone.
In the Cache Operations section, select one of the options.
Option Description
Purge cache Purge the entire cache.
Purge a subset of the cached records.

Purge specific resources
Select a DNS record type to purge and a host name
to purge records for.
DNSSEC compliance
If your origin name server is configured for DNSSEC, you need to update SOA and NS records and resign the zone to
gain the benefit of Imperva DNSSEC support.
1. Prerequisite: Make sure you have the list of NS records that were provided above. To view the NS settings in the
Cloud Security Console:
1. From the sidebar, select DNS > DNS Zones.
2. Click the relevant domain in the Name column.
3. Click General. The list is displayed under NS Settings for Imperva.
2. Update the SOA record in your zone file. Enter the first name server listed in the NS Settings as the primary
master name server for this zone.
3. Update the NS records in your zone file with the list of name servers provided by Imperva.
4. Re-sign the zone with DNSSEC to add the required DNSSEC-related resources.
See also:
• To view or edit your settings after adding DNS zones, see Onboard DNS Protection.
• To manage your Protected DNS Zones via the API, see DNS Protection API Definition.


DNS Protection Dashboard
Explore metrics and advanced analytics for queries flowing through Imperva for your DNS zones.
Under attack? In the event of a current attack on any of your DNS zones, a banner is displayed at the top of the
screen. Click the link to refresh the dashboard with data on the zone under attack.
In this topic:
• Open the dashboard

• Dashboard details
• Attack analysis
Open the dashboard
2. On the sidebar, click DNS > Dashboard.

Dashboard details
Widget Description
Queries per second in the selected time range.

DNS queries
Total queries (peak): The maximal value of passed
and blocked queries per second in the selected time
range.

Widget Description
Total queries (average): The average value of all
passed and blocked queries per second in the
selected time range.
Blocked queries (peak): The maximal value of

blocked queries per second in the selected time
range.
Blocked queries (average): The average value of

blocked queries per second in the selected time
range.
Countries that generated the most requests, in

Top queries by country
descending order.
Details of attacks on your DNS zones.
Click Analyze Attack to view more details on the

Attacked DNS zones
attack.
For more information, see Attack analysis below.
DNS records with the largest number of passed

Top DNS records with passed queries
queries.
DNS records with the largest number of blocked
Top DNS records with blocked queries
queries.
DNS records with the largest number of queries for
Top DNS records with no data domains where the information on the requested
domain is unknown or does not exist.
Attack analysis
Drill down into a specific volumetric DDoS attack against one of your DNS zones.
To view the attack: On the DNS Protection Dashboard, in the Attacked DNS zones table, click Analyze Attack.
In addition to the metrics listed above, you can also view the Top Source IPs - details on the IP addresses that
generated the largest number of queries per second during the attack.

DNS Protection API Definition


Cloud Application Security API Reference

Imperva provides customers and partners with the ability to manage accounts and sites via an API.
Note:
• To better align with REST API standards and best practices, Imperva is gradually rolling out a new version of
APIs, available for your use in managing your Cloud Application Security sites. For details, see API Version 2/3
Overview.
• An API definition file (Swagger) is available for these Cloud Application Security v1 APIs. To view or download
the file, see Cloud Application Security v1/v3 API Definition.
• For more details about Imperva APIs, see Imperva API Documentation.
In this topic:
• Overview
• General request structure
• Pagination
• Time range specification
• General response structure
Overview
The API has the following characteristics:
• Requests are HTTP POST.
• Parameters are specified in the request body in HTML form style. For example:
param1=value1&param2=value2
• All requests are in SSL.
• Response content is provided as a JSON document.
• UTF-8 encoding is always used.
General request structure
Authentication
In order to use the API, the client must be authenticated by Imperva. To authenticate, send your API ID and API key
using the x-API-Id and x-API-Key headers. For example:
x-API-Id: 12345
x-API-Key: 123**************789
You can create and manage API keys with granular permissions and sub account access. For details, see API Key
Management.

Account and site identifiers
Most API operations operate on a specific account or site. Use the following parameters to specify the account or site
to operate on:
Name Description
account_id Numeric identifier of the account to operate on.
site_id Numeric identifier of the site to operate on.
Pagination
Some API operations may return a list of objects. Use the following parameters to enable paging:
Name Description Optional
The number of objects to return in

the response.
page_size Yes
Default: 50
Maximum: 100
The page to return starting from 0.
In order to view the full results, the

client needs to run the API call
page_num with page_num set to 0, then Yes
again with page_num set to 1,
and so forth.
Default: 0
Time range specification

Some operations require the user to specify a time range. This is done via the time_range parameter, which accepts
the following values:
Name Description
Retrieve data from midnight today until the current
today
time.
Retrieve data from midnight of 7 days ago until
last_7_days
midnight today.
last_30_days
midnight today.
last_90_days
midnight today.
Retrieve data from midnight of the first day of the
month_to_date
month until midnight today.

Name Description
Specify a custom time range using two additional

parameters: start and end.
Results are provided for full days only, starting from

midnight. A time range of less than 24 hours gives
results for the full day.
For example:
custom
• A time range of 14:00 - 20:00 yesterday gives
results for all of yesterday (midnight to
midnight) - a full day.
• A time range of 14:00 last Tuesday to 14:00 last
Wednesday gives results for all of Tuesday and
Wednesday - two full days.
• A time range of 14:00 yesterday to 14:00 today
gives results for all of yesterday starting from
midnight until the current time today.
Note:
• If a time range is not specified, today is selected by default.

• All dates should be specified as number of milliseconds since midnight 1970 (UNIX time * 1000). For details, see
http://en.wikipedia.org/wiki/Unix_time.
• Midnight is based on Coordinated Universal Time (UTC).
• The available time ranges depend on the customer subscription plan.
General response structure
Every response contains the following fields in the returned JSON document:
Name Description
The numeric result code for the operation. A result
res
code of 0 indicates success.
The textual representation of the result code (for
res_message
example: "OK" - for success).
General information which is not strictly required for
debug_info
using the API, but is helpful to have.
For example:
{
"res": 0,
"res_message": "OK",
"debug_info": {}
}

General error codes:
Code Description Comment

The server has encountered an
1 Unexpected error
unexpected error.
2 Invalid input Input missing or incorrect.
The server is not available or
Operation timed-out or server
4 reached a time-out while
unavailable
processing the operation.
Authentication parameters
9411 Authentication missing or invalid
missing or incorrect.
The specified account is unknown
Unknown/unauthorized
9403 or client is not authorized to
account_id
operate on it.
The specified site is unknown or
9413 Unknown/unauthorized site_id client is not authorized to operate
on it.
Feature is not available on
9414 Feature not permitted
account's plan.
The requested operation is not
9415 Operation not allowed
allowed.

Cloud Application Security v1/v3 API Definition

Account Management API

The account management APIs enable you to add, delete, and modify accounts, and get account details, such as
status.
In this topic:
• Set S3 configuration for log

storage
• Add a new managed account
• Set SFTP server
• List managed accounts
configuration for log storage
• Add a new sub account
• Set Imperva servers for log
• List account's sub accounts
storage
• Get account status
• Get account login token
• Modify account
• Delete managed account
configuration
• Delete sub account
• Modify account log level
• Get account subscription
• Test connection with S3
details
bucket
• Set default data storage
• Test connection with SFTP
region
server
• Get default data storage
region
Add a new managed account

Available for Reseller accounts only
Use this operation to add a new account that should be managed by the account of the API client (the parent
account). The new account will be configured according to the preferences set for the parent account by Imperva.
Depending on these preferences, an activation e-mail will be sent to the specified e-mail address. The user responds
to the activation e-mail, selects a password, and can then log directly into the Imperva console. The same e-mail
address can also be used to send system notifications to the account. The new account is identified by a numeric
value as provided by Imperva in the response in the field account_id.
/api/prov/v1/accounts/add
Parameters:

api_id API authentication identifier.
api_key API authentication identifier.
Email address. For example:
email
"joe@example.com".
The newly created account's
parent_id Yes
parent id. If not specified, the


invoking account will be assigned
as the parent.
The account owner's name. For
user_name Yes
example: "John Doe".
An identifier of the plan to assign
to the new account. For example,
plan_id Yes
ent100 for the Enterprise 100
plan.
Customer specific identifier for this
ref_id Yes
operation.
account_name Account name. Yes
Sets the log reporting level for the

site.
Possible values: full, security,

log_level none, default Yes
Available only for customers that

purchased the Logs Integration
SKU.
Numeric identifier of the account

that purchased the logs
integration SKU and which collects
the logs. If not specified, operation
will be performed on the account
logs_account_id identified by the authentication Yes
parameters.

SKU.
Response structure:
{
"account":{
"email":"demo_account@incapsula.com",
"plan_id":ent100,
"account_id":4722,
"user_name":"John Doe",
"account_name":"Demo Account",
"logins": {
"login_id":1243,

"email_verified":true
}
},
"res":0,
"res_message":"OK"
}
Specific error codes:

Malformed, missing, or empty
1001 Email invalid
email parameter.
The specified plan is missing,
1003 Plan ID invalid
invalid, or not allowed.
The specified email address is
1010 Account exists already associated with an
account.
List managed accounts
Use this operation to get the list of accounts that are managed by account of the API client (the parent account).
/api/prov/v1/accounts/list
Parameters:

to operate on. If not specified,
account_id operation will be performed on the Yes
account identified by the
authentication parameters.

the response.
page_size Yes
Default: 50
Maximum: 100

page_num Yes
Default: 0

Response structure:
{
"accounts":[
{
"plan_id":ent100,
"account_id":4722,
"logins": {
"login_id":1243,
}
},
...],
"res":0,
"res_message":"OK"
Add
} a new sub account
Use this operation to add a new sub account to be managed by the account of the API client (the parent account).
/api/prov/v1/subaccounts/add
Parameters:

sub_account_name The name of the sub account.
The newly created account's
parent id. If not specified, the
parent_id Yes
invoking account will be assigned
as the parent account.
ref_id Yes
operation.

site.

log_level none, default Yes

SKU.


that purchased the logs
integration SKU and which collects
logs_account_id identified by the authentication Yes
parameters.

SKU.
Response structure:
{
"sub_account":{
"sub_account_id":123456,
"sub_account_name":"My Sub Account",
"is_for_special_ssl_configuration":false,
"support_level":"Standard"
},
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":"999999"
}
}

1001 Email invalid
email parameter.
The specified plan is missing,
1003 Plan ID invalid
invalid, or not allowed.
The specified email address is
1010 Account exists already associated with an
account.
Account reached the maximum Account reached the maximum
1015
allowed number of sub accounts allowed number of sub accounts.
9403 Unknown/unauthorized account id or client is not authorized to
operate on it.
allowed.

List account's sub accounts

Use this operation to get a list of sub accounts that are managed by the account of the API client (the parent account).
/api/prov/v1/accounts/listSubAccounts
Parameters:


the response.
page_size Yes
Default: 50
Maximum: 100

page_num Yes
Default: 0
Response structure:
{
"resultList":[
{
"sub_account_name":"My Sub Account",
"is_for_special_ssl_configuration":false,
},
{
"sub_account_name":"My Other Sub Account",
"is_for_special_ssl_configuration":true,
},
...],
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":"999999"

}
Get account
} status
Use this operation to get information about the account of the API client or one of its managed accounts.
/api/prov/v1/account
Parameters:

Response structure:
{
"account":{
"plan_id":ent100,
"plan_name":"Enterprise",
"trial_end_date":"May 28, 2014",
"account_id":4722,
"ref_id":"123456",
"logins": {
"login_id":1243,
}
"support_level": "Managed",
"support_all_tls_versions": "false"
},
"res":0,
"res_message":"OK"
Modify
} account configuration
Use this operation to change the configuration of the account of the API client or one of its managed accounts.
/api/prov/v1/accounts/configure

Parameters:

Name of the configuration

parameter to set.
Possible values: name | email |

plan_id | error_page_template |
support_all_tls_versions |
naked_domain_san_for_new_www_sites
param
| wildcard_san_for_new_sites |
ref_id
Note: plan_id, email, and

error_page_template parameters
are available for Reseller account
only.
According to the configuration

paramater used.
For name - the updated name, for

e-mail - the updated e-mail
address.
For plan_id - a plan id.
For error_page_template - a
value Base64 encoded template for an
error page.
For log_level - Available only for

customers that purchased the
Logs Integration SKU. Sets the log
reporting level for the site.
none, default
For support_all_tls_versions - Use

this operation to allow sites in the


account to support all TLS versions
for connectivity between clients
(visitors) and the Imperva service.
When this option is set, you can
then enable the option per site to
support all TLS versions. Possible
values: true, false. Note: To remain
PCI-compliant, do not enable this
option.
For
naked_domain_san_for_new_www_sites
- Use this option to determine if
the naked domain SAN will be
added to the SSL certificate for
new www sites. Default value: true
For wildcard_san_for_new_sites -
Use this option to determine if the
wildcard SAN or the full domain
SAN is added to the Imperva SSL
certificate for new sites. Possible
values: true, false, default
(determined by plan) Default
value: default
For ref_id - Sets the Reference ID, a

free-text field that enables you to
add a unique identifier to correlate
an object in our service, such as a
protected website, with an object
on the customer side.
Response structure:
{
"res": 0,
"debug_info": {
"email": "admin@example.com"
}
}


Invalid configuration parameter The specified parameter name is
6001
name missing or invalid.
Invalid configuration parameter The specified parameter value is
6002
value missing or invalid.
Follow the URL in order to
6003 Action required
complete the change plan process.
Modify account log level
Use this operation to change the account log configuration.
/api/prov/v1/accounts/setlog
Parameters:


site.

log_level none, default

purchased the Log Integration
SKU.
Response structure:
{
"res": 0,
"debug_info": {
"log_level": "full"
}
}

Test connection with S3 bucket

Use this operation to check that a connection can be created with your Amazon S3 bucket.
/api/prov/v1/accounts/testS3Connection
Parameters:

account_id
to operate on.
bucket_name S3 bucket name.
access_key S3 access key.
secret_key S3 secret key.
Save this configuration if the test
save_on_success connection was successful. Default Yes
value: false
Response structure:
{
"res": 0,
"debug_info": {
"message": "Test connection succeeded"
}
Test connection
} with SFTP server
Use this operation to check that a connection can be created with your SFTP storage.
/api/prov/v1/accounts/testSftpConnection
Parameters:

account_id
to operate on.
host The IP address of your SFTP server.
A user name that will be used to
user_name
log in to the SFTP server.


A corresponding password for the
password user account used to log in to the
SFTP server.
The path to the directory on the
destination_folder
SFTP server.
Save this configuration if the test
save_on_success connection was successful. Default Yes
value: false
Response structure:
{
"res": 0,
"debug_info": {
"message": "Test connection succeeded"
}
Set S3 configuration
} for log storage
Use this operation to configure your Amazon cloud storage. Once configured, Imperva logs will be uploaded to the
selected location.
/api/prov/v1/accounts/setAmazonSiemStorage
Parameters:
Name Description
bucket_name S3 bucket name.
access_key S3 access key.
secret_key S3 secret key.
Response structure:
{
"res": 0,
"debug_info": {
"message": "Configuration was successfully updated"
}
Set SFTP
} server configuration for log storage
Use this operation to configure your SFTP server storage. Once configured, Incapsula logs will be uploaded to the
selected location.

/api/prov/v1/accounts/setSftpSiemStorage
Parameters:
Name Description
host The IP address of your SFTP server.
A user name that will be used to log in to the
user_name
SFTP server.
A corresponding password for the user account used
password
to log in to the SFTP server.
destination_folder The path to the directory on the SFTP server.
Response structure:
{
"res": 0,
"debug_info": {
}
Set Imperva
} servers for log storage
Use this operation to have your logs saved on Incapsula servers. Once configured, the logs can be retrieved by API
calls.
/api/prov/v1/accounts/setDefaultSiemStorage
Parameters:
Name Description
Response structure:
{
"res": 0,
"debug_info": {
}
}

Get account login token

Tokens are used instead of user/password based authentication to log in to the Imperva Cloud Security Console.
Use this operation to generate a token for an account. The token is valid for 15 minutes.
/api/prov/v1/accounts/gettoken
In order to use the token, the user must use the following link:
https://my.imperva.com/?token={generated_token}
Parameters:

Response structure:
{
"res": 0,
"generated_token": "344ebcaf34dff34"
Delete
} managed account
Use this operation to delete an account.
/api/prov/v1/accounts/delete
Parameters:

account_id Yes
to operate on.

Response structure:
{
"res": 0,
"res_message": "OK"
Delete
} sub account
Use this operation to delete a sub account.
/api/prov/v1/subaccounts/delete
Parameters:
Name Description
sub_account_id Numeric identifier of the sub account to operate on.
Response structure:
{
"res": 0,
"res_message": "OK"
Get account
} subscription details
Use this operation to get subscription details for an account.
/api/prov/v1/accounts/subscription
Parameters:

Response structure:
{
"planStatus": {
"accountId": 12345,
"accountName": "demo_account@incapsula.com",
"websiteProtection": {
"name": "Website Protection",

"planSectionRows": [
{
"name": "Additional Sites",
"purchased": "100",
"used": "2"
},
{
"name": "Load Balancing (old)",
"purchased": "0",
"used": "0"
},
{
"name": "Additional Login Protect Users",
"purchased": "5",
"used": "0"
}
]
},
"infrastructureProtection": {
"name": "Infrastructure Protection",
{
"name": "On Demand Bandwidth (Clean traffic)",
"purchased": "0",
"used": ""
},
{
"name": "GRE Tunnel Pairs",
"purchased": "0 ",
"used": "0"
}
]
},
"dnsProtection": {
"name": "DNS Protection",
{
"name": "Additional DNS Zones",
"purchased": "0",
"used": "0"
}
]
},
"additionalServices": {
"name": "Additional Services",
{
"name": "Always On Bandwidth (Clean traffic)",
"purchased": "10Mbps",

"used": "N/A"
},
{
"name": "DDoS Protection",
"purchased": "None",
"used": ""
},
{
"name": "Support Level",
"purchased": "Standard",
"used": "Standard"
},
{
"name": "SIEM Integration",
"purchased": "10",
"used": "0"
},
{
"name": "Web Attack Analytics",
"purchased": "0",
"used": ""
}
]
}
},
"bandwidthHistory": [
{
"billingCycle": "Current billing cycle",
"onDemandBandwidth": "0bps",
"alwaysOnBandwidth": "3.5kbps"
},
{
"billingCycle": "Previous billing cycle",
"alwaysOnBandwidth": "15kbps"
},
{
"billingCycle": "Earlier billing cycle",
"alwaysOnBandwidth": "7.7kbps"
}
],
"res": 0,
"res_message": "OK"
}
Set default data storage region

Use this operation to set the default data region of the account for newly created sites.
/api/prov/v1/accounts/data-privacy/set-region-default
Parameters:
Name Description
data_storage_region The data region to use.
Possible values for region:
Name Description
APAC Asia Pacific
EU Europe
US United States
Use system default region, based on geolocation of
AU
the origin server registered for a site.
Response structure:
{
"res": 0,
"res_message": "OK"
Get
} default data storage region
Use this operation to get the default data region of the account.
/api/prov/v1/accounts/data-privacy/show
Parameters:
Name Description
Response structure:
{
region: EU
"res":0,
"res_message":"OK"


Site Management API

The site management APIs enable you to add, remove, and update sites.
In this topic:
• Modify site access control

• Adding a site: workflow list (ACL) configuration
• Add site • Modify whitelist
• Get site status configuration
• Get domain approver email • Delete site
addresses • List sites
• Modify site configuration • Get site report
• Modify site log level • Get HTML injection rules
• Set support for all • Add or replace an HTML
Site configuration TLS versions injection rule
• Modify site security • Remove an HTML injection
configuration rule
• Create new CSR • Move site
• Upload custom certificate • Set site data storage region
• Remove custom certificate • Get site data storage region
• Check CAA compliance • Set site regions by origin
• Modify Error Page geolocation
• Get Error Page • Get site regions by origin
geolocation
• Add rule • Delete rule

Rules • Edit rule • List rules
• Enable or disable a rule • Set rule priority
• Modify cached response

• Purge site cache headers
• Modify caching mode • Get cached response
• Get Caching Mode headers
• Modify secure resources • Tag the response according
mode to the value of a header
• Modify stale content settings • Get Header to Tag
Caching
• Get stale content settings Responses By
• Purge resources • Purge hostname from cache
• Modify caching rules • Get XRay access link
• Advanced caching settings • Enable Cache Shield
• Get advanced caching • Is Cache Shield enabled
settings • Modify Cache 404 Settings
• Get Cache 404 Settings

• Add cache rule

• Enable or disable cache rule
Cache Rules • Edit cache rule
• List cache rules
• Delete cache rule
• Add data center

• Edit data center
• Add server
• Delete data center
• Edit server
Data centers • List data centers
• Delete server
• Set data center Origin PoP
• Resume Traffic to Active DCs
• Get data center
recommended Origin PoP
Adding a site: workflow

The process of adding a site to Imperva depends on whether the site requires SSL support. If the site requires SSL
support, Imperva needs to generate a proxy SSL certificate on your behalf, which requires your approval and action.
After a site is added, its status is one of the following:
Name Description
A site with SSL support was added. Domain approval
pending-select-approver email needs to be selected or a new domain
validation method should be selected.
The site owner needs to approve the SSL certificate
generation by completing a domain validation
pending-certificate action (following a link in the approval email, DNS
change, adding an HTML meta tag, adding a new file,
etc.)
The site is ready for the user to perform the required
pending-dns-changes DNS changes in order to be fully configured on the
service.
fully-configured Site is active on the Imperva network.
To add a non-SSL site:
1. Call the Add site operation. A successful response will contain the required DNS changes. The site is in pending-
dns-changes state.
2. Perform the DNS changes. The system will detect the DNS changes in a few minutes and will set the site to the
fully-configured state.
3. Call the Get site status operation periodically until the site is in the fully-configured state.
To add an SSL site:
Prerequisite: Imperva must verify that HTTPS is supported by your site, in order to support SSL for your site.
1. Call the Add site operation. The site is in pending-select-approver state.

2. To continue with E-mail based domain validation:
1. Call the Modify site configuration operation and set the SSL domain validation method to email.
2. Call the Get domain approver email addresses operation and select an email address from the list.
3. Call the Modify site configuration operation again and set the selected email address. The system will
send the certificate generation approval email and set the site to the pending-certificate state.
3. To continue with HTML meta tag domain validation:
1. Call the Modify site configuration operation and set the SSL domain validation method to html. The
operation will return the required HTML snippet to place in the homepage of the site and set the site to
the pending-certificate state.
2. The site owner needs to place the HTML snippet in the homepage of the site.
3. Call the Get site status operation and use the tests parameter to verify that domain validation was
performed successfully.
4. To continue with DNS domain validation:
1. Call the Modify site configuration operation and set the SSL domain validation method to dns. The
operation will return the required DNS records to set on the site's domain and set the site to the pending-
certificate state.
2. The site owner needs to set the DNS records on the site's domain.
3. Call the Get site status operation and use the tests parameter to verify that domain validation was
performed successfully.
5. Call the Get site status operation periodically until the site is in the pending-dns state. The required DNS
changes will be provided in the response.
6. Perform the DNS changes. The system will detect the DNS changes in a few minutes and will set the site to the
fully-configured state.
7. Call the Get site status operation periodically until the site is in the fully-configured state.
To add SSL to an existing site:
1. Verify that Imperva has detected that HTTPS is supported by your site:
1. Call the Get site status operation and look for the detected field under origin_server.
2. If the detected value is false, add the services test parameters and call the Get site status operation
again.
3. Keep calling the Get site status operation until the detected value changes to true.
2. Call the Modify site configuration operation and set the SSL domain validation method. Then, continue
according to the flow above.
Add site
Add a new site to an account. If the site already exists, its status is returned.
/api/prov/v1/sites/add

Parameters:

The domain name of the site. For
domain example: www.example.com,
hello.example.com, example.com
ref_id Yes
operation.
If this value is "false", end users
will not get emails about the add
send_site_setup_emails Yes
site process such as "DNS
instructions" and "SSL setup".
Manually set the web server IP/
site_ip Yes
CNAME.
If this value is "true", manually set
the site to support SSL. This option
force_ssl is only available for sites with Yes
manually configured IP/CNAME
and for specific accounts.
Use “true” to add the naked
naked_domain_san domain SAN to a www site’s SSL Yes
certificate. Default value: true
Use “true” to add the wildcard SAN
or “false” to add the full domain
wildcard_san Yes
SAN to the site’s SSL certificate.
Default value: true
log_level SKU. Sets the log reporting level Yes
for the site. Options are “full”,
“security”, “none” and "default"
SKU. Numeric identifier of the
account that purchased the logs
logs_account_id integration SKU and which collects Yes
identified by the authentication
parameters

Required DNS changes:
The dns section of the responses contains the list of required DNS changes. Each entry contains the following
parameters:
Name Description
dns_record_name Name of a DNS record which needs to be set.
The type of DNS record to set - either CNAME or A.
Note: Any existing CNAME or A records defined for

set_type_to
the specified DNS_record_name should be
removed, but other types of DNS records (e.g. MX,
TXT or SPF) should be kept.
The value to set for the CNAME or A record, typically

set_data_to
an IP address or an Imperva-owned domain name.
Site configuration warnings:
This section contains non-critical configuration warnings. While these warnings are present your site will still be under
Imperva service.
Name Description
Your ftp records are pointing directly to your server
FTP records
instead of to Imperva.
Your mail records are pointing directly to your server
set_type_to
instead of to Imperva.
Response structure:
The structure is the same as for Get site status.

3001 Domain invalid
domain field.
Site is on the CloudFlare network
and cannot be added. In order to
add the site, disable its records on
3002 Site is on the CloudFlare network
CloudFlare, wait a few minutes for
the changes to take effect, and try
again.
Site requires SSL traffic but the
3003 Site requires SSL account is not on a supporting
plan. To add the site, first upgrade


your plan in the Cloud Security
Console.
Site cannot be added since the
Domain belongs to a known domain belongs to a known
3004
service service. Add the site's real domain
instead.
Site is on a service (CDN, load- Site is on a service but account is
balancer, etc.) that is not not on a supporting plan. To add
3005
supported by the plan of the the site first upgrade your plan in
account. the Cloud Security Console.
Site requires multiple IPs support
but the account is not on a
supporting plan. The site was
3006 Site requires multiple IPs support added with a single IP. To enable
multiple IPs support upgrade your
plan in the Cloud Security
Console.
3011 Site unresolvable No DNS entry exists for this site
Cannot connect to site, so no
information can be retrieved
3012 Site unreachable
regarding SSL status. Note that the
site will still be created.
Site already protected by the This site already exists on a
3013
service different account.
Account has reached the
maximum number of sites. To add
3014 Number of allowed sites exceeded.
an additional site first upgrade
your plan.
3015 Internal error Internal error, please try again.
Get site status
Use this operation to get the status of a site.
/api/prov/v1/sites/status
Parameters:

Numeric identifier of the site to
site_id
operate on.
List of tests to run on site before
tests returning its status. A comma Yes
separated list of one of:


domain_validation, services, dns.
See detailed description below.
Site test options:
Name Description
Runs the domain validation test on the specified
site. This test will check for HTML meta tag or DNS
domain_validation
records, according to the selected domain validation
method.
Runs the services test on the specified site. This test
services will check the availability of HTTP and HTTPS
connections on the site.
Runs the DNS test on the specified site. This test will
dns check whether the site owner performed the DNS
changes required in order to protect the site.
Response structure:
{
"res": 0,
"status": "pending_dns_changes",
"ips": [ "34.33.22.1" ],
"dns":
[
{ "dns_record_name": "www.example.com",
"set_type_to": "CNAME",
"set_data_to": "x343.incapdns.net"
},
{ "dns_record_name": "example.com",
"set_type_to": "A",
"set_data_to": "10.200.0.0"
],
"original_dns":[
{
"dns_record_name":"example.com",
"set_type_to":"A",
"set_data_to":[
"66.45.177.11"
]
},
{
"dns_record_name":"www.example.com",
"set_type_to":"A",
"set_data_to":[
"66.45.177.50"

]
}
],
"warnings":
[
{
"type":"FTP",
"dns_record_name": "ftp.example.com",
"set_type_to": "A",
"set_data_to": "10.200.0.0"
},
{
"type":"MAIL",
"mail_record_name": "mail.example.com",
"set_type_to": "A",
"set_data_to": "10.200.0.0"
}
],
"security": {
"waf": {
"rules" : [
{
"id":"api.threats.bot_access_control",
"name":"Bot Access Control",
"block_bad_bots":true,
"challenge_suspected_bots":true
},
{
"id":"api.threats.sql_injection",
"name":"SQL Injection",
"action":"api.threats.action.block_request",
"action_text":"Block Request",
},
{
"id":"api.threats.cross_site_scripting",
"name":"Cross Site Scripting (XSS)",
"exceptions":[
{
"values":[
{
"urls":[
{
"value":"/gsddg",
"pattern":"EQUALS"
}
],
"id":"api.rule_exception_type.url",
"name":"URL"
}

],
"id":244711494
},
...
],
"action":"api.threats.action.alert",
"action_text":"Alert Only",
},
{
"id":"api.threats.illegal_resource_access",
"name":"Illegal Resource Access",
"action":"api.threats.action.block_user",
"action_text":"Block User",
},
{
"id":"api.threats.ddos",
"name":"DDoS",
"activation_mode":"api.threats.ddos.activation_mode.
"activation_mode_text":"Off",
"ddos_traffic_threshold":"api.threats.ddos.ddos_tras
"ddos_traffic_threshold_text":"750",
},
{
"id":"api.threats.backdoor",
"name":"Backdoor Protect",
"action":"api.threats.action.quarantine_url",
"action_text":"Auto-Quarantine",
},
{
"action":"api.threats.action.block_ip",
"action_text":"Block IP",
"id":"api.threats.remote_file_inclusion",
"name":"Remote File Inclusion"
}
]
},
"acls":{
"rules":[
{
"ips":[
"2.3.4.5"
],
"exceptions":[
{
"values":[
{
"urls":[
{
"value":"/home",

"pattern":"EQUALS"
}
],
"id":"api.rule_exception_type.url",
"name":"URL"
},
...
],
"id":493271006
},
...
],
"id":"api.acl.blacklisted_ips",
"name":"Visitors from blacklisted IPs"
},
...
]
}
},
"active": "active",
"acceleration_level": "advanced",
"site_creation_date": 1372573842000
"sealLocation":{
"id":"api.seal_location.bottom_right",
"name":"Bottom right"
},
"ssl" : {
// Example for case HTTPS support was detected on the site
"origin_server":{
"detected":true,
"detectionStatus":"ok"
},
// Example for case HTTPS support was not detected on the site
"origin_server":{
"detected":false,
"detectionStatus":"hostname_mismatch"
},
// Example for HTML validation

"generated_certificate" : {
"ca" : "GS",
"validation_method" : "html",
"validation_data" : {
"https://example.com/.well-known/pki-validation/gsdv.txt": [
"<meta name="globalsign-domain-verification" content="rgwlWGF7wQsdWdhbd5
]
},

"san" : ["*.example.com", "example.com"],

"validation_status" : "pending_user_action"
}
// Example for DNS validation

"generated_certificate" : {
"ca" : "globalsign",
"validation_method" : "dns",
"validation_data" : [
{"dns_record_name": "www.example.com", "set_type_to": "TXT", "set_da
...
],
"san" : ["*.example.com", "example.com"],
"validation_status" : "pending_user_action"
},
"custom_certificate" : {
"active":true,
"expirationDate":1460100446000,
"revocationError":false,
"validityError":false,
"chainError":false,
"hostnameMismatchError":true,
"fingerPrint":"SHA1 Fingerprint=A7:89:E5:05:A8:17:A1:22:EA:90:5F:A6:EA:A3:D4:8B:
"serialNumber":"FE:BA:E1:4A:F1:34:ED:60"
}
},
"login_protect":{
"enabled":true,
"specific_users_list":[
{
"email":"john@example.com",
"name":"John Doe",
"status":"INVITATION_SENT"
},
{
"email":"jane@example.com",
"name":"Jane Doe",
"status":"ACTIVATED"
}
],
"send_lp_notifications":true,
"allow_all_users":false,
"authentication_methods":[
"sms",
"ga"
],
"urls":[
"/wp-admin"

],
"url_patterns":[
"PREFIX"
]
},
"performance_configuration":{
"advanced_caching_rules":{
"never_cache_resources":[
{
"pattern":"SUFFIX",
"url":"/test.html"
}
],
"always_cache_resources":[
{
"pattern":"NOT_EQUALS",
"url":"/index.html",
"ttl":5,
"ttlUnits":"SECONDS"
},
{
"pattern":"EQUALS",
"url":"/home.html",
"ttl":6,
"ttlUnits":"DAYS"
}
]
},
"acceleration_level":"advanced",
"async_validation":true,
"minify_javascript":true,
"minify_css":true,
"minify_static_html":true,
"compress_jpeg":true,
"progressive_image_rendering":true,
"aggressive_compression":true,
"compress_png":true,
"on_the_fly_compression":true,
"tcp_pre_pooling":true,
"comply_no_cache":true,
"comply_vary":true,
"use_shortest_caching":true,
"support_all_tls_versions":true,
"prefer_last_modified":true,
"disable_client_side_caching":true,
"cache_headers":[
{
"headerName":"Content-type: application/pdf"
}

]
},
"res":0,
"res_message":"OK"
}
Name Description
status The current status of the site.
ips IP addresses or hostname of the site's servers.
The required DNS changes. Sent when the site is in
dns
pending_dns_changes or fully_configured status.
A list of warnings regarding the configuration of the
warning
site.
security The security settings of the site.
A text string indicating whether the site is active or
active has been moved into bypass mode, one of: active |
bypass.
A text string indicating the acceleration level of the
acceleration_level
site, one of: off | standard | advanced.
The creation date of the site in milliseconds since
site_creation_date
1970.
The current location of the seal. One of:
api.seal_location.bottom_left |
api.seal_location.none |
seal_location api.seal_location.right_bottom |
api.seal_location.right | api.seal_location.left |
api.seal_location.bottom_right |
api.seal_location.bottom
Information regarding the SSL configuration of the
ssl site and the SSL configuration detected on the site's
origin server. For more details see the table below.
login_protect The Login Protect configuration of the site.
performance_configuration The performance configuration of the site.
Details for the ssl.origin_server section:
Name Description
detected Imperva detected HTTPS support on the site.
detectionStatus HTTPS detection status/failure reason for site.
Possible values for ssl.origin_server detectionStatus field:
Name Description
ok SSL detected.
ssl_connection_not_established For example: no server certificate found.
hostname_mismatch Hostname in certificate did not match.

Name Description
invalid_server_response Received an invalid response from server.
host_unreachable Could not reach host.
unclassified_error Received an unclassified error.
ssl_network_detection_not_run SSL network detection test did not run.
Details for the ssl.generated_certificate section:
Name Description
The certificate authority Imperva is using to
ca
generate the certificate for the site.
The domain names that will be added to the
san certificate as part of the Subject Alternative Names
section (SAN).
The SSL domain validation method. One of: email |
validation_method
html | dns.
For e-mail validation the selected approver email
validation_data address, for HTML validation the HTML snippet to
use, for DNS validation the DNS records to set.
validation_data.set_type_to The type of DNS record to set. One of: CNAME | TXT
The status of the SSL domain validation process.

One of:
• pending_user_action (system did not detect

changes by site owner)
• pending_ca (system is waiting for the
certificate authority to generate the
validation_status certificate)
• pending_extended_validation (certificate
authority has decided to perform an extended
validation procedure, expect delay in
certificate generation)
• pending_caa_records_change (CAA records
are not compliant - User action required)
• done
Details for the ssl.custom_certificate section:
Name Description
Custom certificate was successfully uploaded for the
active
site.
The expiration date of the custom certificate, in
expirationDate milliseconds, since 1970. For a detailed description,
see Cloud Application Security API Reference.

Name Description
The custom certificate was revoked by the CA (is
revocationError
under the CRL - certificate revocation list).
The custom certificate is either expired or not valid
validityError
yet.
The custom certificate chain is broken / contains
chainError
untrusted intermediate certificate.
The site is not covered by the subject or Subject
hostnameMismatchError
Alternative Names on the custom certificate.
Get domain approver email addresses
Use this operation to get the list of email addresses that can be used when adding an SSL site.
/api/prov/v1/domain/emails
Parameters:
Name Description
The domain name of the site. For example:
domain www.example.com, hello.example.com,
example.com
Response structure:
{
"res": 0,
"domain_emails": [
"admin@example.com",
"webmaster@example.com"
]
}

3001 Domain invalid
domain field.
3011 Site unresolvable No DNS entry exists for this site.
Modify site configuration
Use this operation to change one of the basic configuration settings of the site.
/api/prov/v1/sites/configure

Parameters:
Name Description
Name of configuration parameter to set. See table
param
below.
value According to the param value. See table below.
Parameter values:
Name Description
Whether the site is active or bypassed by the
active
Imperva network. One of: active | bypass.
Comma separated list of IPs. For example:
site_ip
8.8.8.8,1.2.2.2
Sets the domain validation method that will be used

to generate an SSL certificate. One of: email | html |
dns | cname
If doing site validation by DNS records, select: dns

when using a TXT record, cname when using a
CNAME record.
For 1-step onboarding of a new site, after adding a

site and configuring your traffic to point to Imperva,
use the html option to automatically add SSL
support. Certificate creation takes approximately 5
minutes, during which no traffic will reach the origin
domain_validation
server.
Note: When running domain validation on a site,

you may see the following error message in the API
response: Internal error - "Add site operation hasn't
finished".
After running the add site process, it may take

several minutes for the database to finish updating.
During this time, attempts to further configure the
site are blocked.
In some cases, the database is not updated even

after the add site process is complete.

Name Description
If the issue does not resolve after a few minutes,
contact Support.
Sets the approver e-mail address that will be used to

approver
perform SSL domain validation.
Sets the ignore SSL flag (if the site is in pending-
ignore_ssl select-approver state). Pass "true" in the value
parameter.
Sets the acceleration level of the site, one of: none |
standard | aggressive. It is advised to use the newer
acceleration_level
Modify caching mode API call instead, as it provides
enhanced functionality.
Sets the seal location, e.g.
seal_location
"api.seal_location.bottom_right".
Sets the redirect naked to full flag. Pass "true" in the
domain_redirect_to_full
value parameter.
Sets the remove SSL from site flag. Pass "true" in the
remove_ssl
value parameter.
Sets the Reference ID, a free-text field that enables
you to add a unique identifier to correlate an object
ref_id
in our service, such as a protected website, with an
object on the customer side.
When set to true, the cookie that Imperva sends to
site visitors is sent without the naked domain
set_cookies_without_domain
associated with your site. By default, the domain is
included.
Response structure:
{
"res": 0,
"debug_info": {
"domain_email": "admin@example.com"
}
}

Invalid configuration parameter The specified parameter name is
6001
name missing or invalid.
Invalid configuration parameter The specified parameter value is
6002
value missing or invalid.

Modify site log level

Use this operation to change the site log configuration.
/api/prov/v1/sites/setlog
Parameters:

site_id
operate on.

SKU. Sets the log reporting level
log_level for the site. Yes

none, default
Response structure:
{
"res": 0,
"debug_info": {
"log_level": "full"
}
Set support
} for all TLS versions
Use this operation to support all TLS versions for the site for connectivity between clients (visitors) and the Imperva
service. To remain PCI-compliant, do not enable this option.
/api/prov/v1/sites/tls
Parameters:
Name Description
support_all_tls_versions Support all TLS versions. Default value: false

Response structure:
{
"res": 0,
"debug_info": {
"support_all_tls_versions": "true"
"new_A_record": "1.2.3.4"
}
Modify }site security configuration
Use this operation to change the security configuration of a site. To modify the configuration for a specific rule,
additional parameters may be required, as documented below.
/api/prov/v1/sites/configure/security
Parameters:

site_id
operate on.
ID of the security rule to change.

For possible values, see the rule_id
rule_id table below. See also the security
section in the Get site status API
call.
Whether or not to block bad bots.

block_bad_bots Yes
Whether or not to send a challenge
to clients that are suspected to be
challenge_suspected_bots Yes
bad bots (CAPTCHA for example).
Possible values: off, auto, on
• off - security measures are

disabled even if site is under
activation_mode
a DDoS attack
• auto - security measures will
be activated automatically
when the system suspects
site is under a DDoS attack


• on - security measures are
enabled even if site is not
under a DDoS attack
The syntax is as
follows:<rule_id>.activation_mode.<value>
For example, for 'off', use

'activation_mode=api.threats.ddos.activation_mode.off'.
Note: This parameter is relevant

and required for a DDoS rule only
-- where
rule_id=api.threats.ddos.
The action that should be taken

when a threat is detected, for
example:
api.threats.action.block_ip.
Different actions are allowed per
security_rule_action Yes
different threats, e.g. backdoors
may only be quarantined, ignored,
or trigger an alert. For possible
values see the
security_rule_action table below.
Removes quarantined URLs from

the backdoor protection list, as
defined in the Cloud Security
Console Website Settings > WAF
Settings > Backdoor Protect.
To remove a URL from the

backdoor protection list, use the
following parameters with the
quarantined_urls Yes
specified values:
• quarantined_urls:
<URL full path>
• rule_id:
api.threats.backdoor
•
security_rule_action: api.threats.action.quarantine_url
Consider site to be under DDoS if

ddos_traffic_threshold the request rate is above this Yes
threshold. The valid values are 10,


20, 50, 100, 200, 500, 750, 1000,
2000, 3000, 4000, 5000.
Example: Bot access control request
api_id=123
api_key=abcdefg
rule_id=api.threats.bot_access_control
block_bad_bots=true
challenge_suspected_bots=true
Example: Block SQL Injection
api_id=123
api_key=abcdefg
rule_id=api.threats.sql_injection
security_rule_action=api.threats.action.block_request
Values for the rule_id parameter:
Name
api.threats.bot_access_control
api.threats.sql_injection
api.threats.cross_site_scripting
api.threats.illegal_resource_access
api.threats.backdoor
api.threats.ddos
api.threats.remote_file_inclusion
Values for the security_rule_action parameter:
Name Description
api.threats.action.disabled Threat is not blocked, site owner is not notified.
api.threats.action.alert Threat is not blocked, site owner is notified.
Threat blocked by stopping the request, site owner
api.threats.action.block_request
is notified.
Threat blocked by stopping the request. Additional
requests by the client application will be
api.threats.action.block_user
automatically blocked for a duration of several
minutes. Site owner is notified.
Threat blocked by stopping the request. Additional
requests from the same IP addresses will be
api.threats.action.block_ip
automatically blocked for a duration of several
minutes. Site owner is notified.
Relevant only for Backdoor Protect. When detecting
api.threats.action.quarantine_url
a backdoor, additional requests to the URL of the

Name Description
backdoor will be automatically blocked. Site owner
is notified.
Example: DDoS request
api_id=123
api_key=abcdefg
rule_id=api.threats.ddos
activation_mode=api.threats.ddos.activation_mode.auto
ddos_traffic_threshold=750
Response structure:

account's plan.
Modify site access control list (ACL) configuration
Use this operation to change the ACL configuration of a site.
To modify the configuration for a specific ACL rule, its values are required, as documented below.
To delete an entire ACL list, send an empty string as the list values.
/api/prov/v1/sites/configure/acl
Parameters:

site_id
operate on.
The id of the acl, e.g
rule_id api.acl.blacklisted_ips. See other
examples below.
A comma separated list of resource

paths.
urls Yes
For example, /home and /admin/
index.html are resource paths,


while http://www.example.com/
home is not.
Each URL should be encoded

separately using percent encoding
as specified by RFC 3986 (http://
tools.ietf.org/html/
rfc3986#section-2.1).
An empty URL list will remove all

URLs.
A comma separated list of url

patterns. One of: contains | equals
| prefix | suffix | not_equals |
not_contain | not_prefix |
url_patterns not_suffix. Yes
The patterns should be in

accordance with the matching urls
sent by the urls parameter.
A comma separated list of country

countries Yes
codes.
A comma separated list of
continents Yes
continent codes.
A comma separated list of IPs or IP
ranges, e.g: 192.168.1.1,
ips Yes
192.168.1.1-192.168.1.100 or
192.168.1.1/24
Values for the rule_id parameter:
Name Description
Visitors from blacklisted countries and/or
api.acl.blacklisted_countries
continents.
api.acl.blacklisted_urls Visitors from blacklisted URLs.
api.acl.blacklisted_ips Visitors from blacklisted IPs.
api.acl.whitelisted_ips Visitors from whitelisted IPs.
Example: Blacklisted URLs
api_id=123
api_key=abcdefg
rule_id=api.acl.blacklisted_urls

urls=%2Fadmin%2Fdashboard%2Fstats%3Fx%3D1%26y%3D2%23z%3D3,%2Fadmin
url_patterns=contains,equals
Example: Blacklisted countries
api_id=123
api_key=abcdefg
rule_id=api.acl.blacklisted_countries
countries=CA,US
continents=SA
Example: Blacklisted IPs
api_id=123
api_key=abcdefg
rule_id=api.acl.blacklisted_ips
ips=1.2.3.4,192.168.1.1-192.168.1.100,192.168.1.1/24
Example: Whitelisted IPs
api_id=123
api_key=abcdefg
rule_id=api.acl.whitelisted_ips
ips=1.2.3.4
Example: Delete the IPs ACL (send an empty list of IPs)
api_id=123
api_key=abcdefg
rule_id=api.acl.blacklisted_ips
ips=
Response structure:

Modify whitelist configuration
Use this operation to set whitelists to security rules or ACLs. To update an existing whitelist, send its ID in the id
parameter. If the id parameter does not exist a new whitelist will be created.
/api/prov/v1/sites/configure/whitelists
Parameters:

site_id
operate on.


The id of the rule (either a security
or an acl rule), e.g
rule_id
api.acl.blacklisted_ips. See other
examples below.
The id (an integer) of the whitelist
to be set. This field is optional - in
whitelist_id
case no id is supplied, a new
whitelist will be created.
An optional boolean parameter. If
it is set to "true" and a whitelist id
delete_whitelist Yes
is sent, the whitelist will be
deleted.

paths.
For example, /home and /admin/

index.html are resource paths,
while http://www.example.com/
home is not.
urls Yes
rfc3986#section-2.1).
An empty URL list will remove all

URLs.
A comma separated list of country

countries Yes
codes.
continents Yes
continent codes.
A comma separated list of IPs or IP
ranges, e.g: 192.168.1.1,
ips Yes
192.168.1.1-192.168.1.100 or
192.168.1.1/24
A comma separated list of client
client_app_types Yes
application types,
A comma separated list of client
client_apps Yes
application IDs.
parameters Yes
encoded parameters.
user_agents Yes
encoded user agents.


Return only the new/edited
exception_id_only Yes
exception id.
The following API call adds a whitelist to the SQL injection security rule. SQL injections will not be handled for requests that are either
the specified URLs, IPs, or countries:
api_id=123
api_key=abcdefg
rule_id=api.threats.sql_injection
urls=%2Fadmin%2Fdashboard%2Fstats%3Fx%3D1%26y%3D2%23z%3D3,%2Fadmin
ips=1.2.3.4,192.168.1.1-192.168.1.100,192.168.1.1/24
countries=GT,VN
The following API call updates a whitelist to the countries acl. SQL injections will not be handled for requests that are from the
specified countries:
api_id=123
api_key=abcdefg
rule_id=api.acl.blacklisted_countries
whitelist_id=1234567
countries=CA,US
continents=SA
The following API call removes a whitelist whose id is 123456:
api_id=123
api_key=abcdefg
rule_id=api.acl.blacklisted_urls
whitelist_id=123456
delete_whitelist=true
Response structure:

Delete site
Delete a site.
/api/prov/v1/sites/delete
Parameters:
Name Description

Response structure:
{
"res": 0,
"res_message": "OK"
List
} sites
List sites for an account. If the specified account has sub accounts, the operation returns results of the sites in the
account and in all of its sub accounts.
/api/prov/v1/sites/list
Parameters:


operation will be performed on the
account_id Yes
If the account has sub accounts,
the operation returns results for
the sites in the account and in all
of its sub accounts.

the response.
page_size Yes
Default is 50.
Maximum: 100

page_num Yes
Default is 0.
Response structure:
{
"res": 0,
"sites":
[
{Same as Get Site Status},
{Same as Get Site Status},

...
],
"debug_info": {}
}

9403 or the client is not authorized to
account_id
operate on it.
Get site report
Use this operation to get a report for a site. Reports are sent using Base64 encoding.
The time_range parameter is ignored for accounts with the WAF Rules policy feature. For such accounts, the report
returns the current status.
/api/prov/v1/sites/report
Parameters:

site_id
operate on.
The report to get. One of: pci-
report
compliance.
The format to get the report in.
format
One of: pdf | html
Time range to fetch data for. For a
detailed description, see Cloud
time_range
Application Security API
Reference.
Start date in milliseconds since
1970. For a detailed description,
start Yes
see Cloud Application Security API
Reference.
End date in milliseconds since
end Yes
Reference.
Response structure:
{
"res": 0,

"format" : "pdf",
"report" : "JVBERi0xLjUNCiXvv73vv73vv73vv70NCjEgMCBvYmoNCjw8L1R5cGUvQ2F0YWxvZy9QYWdlcyAy
}

Requested report is missing,
empty, or malformed, or the
5001 Report invalid
account is not on a supporting
plan.
Report format missing, empty,
5002 Format invalid malformed, or not supported by
the specified report.
Purge site cache
Use this operation to purge all cached content on our proxy servers for a specific site.
Our Proxy servers keep cached content of your sites in order to accelerate page load times for your users. When you
want this cached content to be refreshed (for example, after making adjustments in your site) you can use this API call.
To purge the entire cached content for this site, use the API call with no parameters.
To purge a specific resource, add the resource name as a parameter.
/api/prov/v1/sites/cache/purge
Parameters:

site_id
operate on.
The pattern of the resource to be

purged from the cache. For
example:
• Resource_name - Resources
that contain Resource_name
purge_pattern Yes
will be purged
• ^Resource_name-
Resources that start with
Resource_name will be
purged
• Resource_name$ -
Resources that end with


Resource_name will be
purged.
A comma separated list of tag

purge_tag_names Yes
names to purge.
Response structure:
{
"res": 0,
"res_message": "OK"
}

The pattern should be of the form
5010 Pattern invalid
^?.*$?
Get HTML injection rules
Use this operation to list all the HTML Injection rules.
/api/prov/v1/sites/htmlinjections
Parameters:
Name Description
Response structure:
{
"html_injections":[
{
"url":"/",
"url_pattern":"prefix",
"location":"head",
"content":"Some content"
},
...
],
"res":0,
"res_message":"OK"
}

Add or replace an HTML injection rule

Use this operation to add a new HTML injection rule or to replace an existing rule.
/api/prov/v1/sites/configure/htmlInjections
Parameters:

site_id
operate on.
The URL where the content is
url
injected.
The url pattern. One of: contains |
not_contains | equals | not_equals
url_pattern
| prefix | suffix | not_prefix |
not_suffix
The location of the injection inside
location
the URL ('head' or 'body_end').
The injected HTML snippet,
content Yes
Base64-encoded.
Response structure:
The structure is the same as for Get HTML injection rules.
Example: The following API call adds the HTML content "Hello World!" to any URL containing "/index.php", in the
beginning of the HEAD section. If content was already injected for the specified configuration, the existing content will
be replaced by "Hello World!". Note that the text itself is Base64 encoded.
api_id=123
api_key=abcdefg
url=/index.php
url_pattern=contains
location=head
Remove an HTML injection
content=SGVsbG8gV29ybGQh rule
Use this operation to removes an existing HTML injection rule. To confirm the removal, set the parameter
delete_content to true.
/api/prov/v1/sites/configure/htmlInjections

Parameters:

site_id
operate on.
The URL where the content is
url
injected.
The url pattern. One of: contains |
not_contains | equals | not_equals
url_pattern
| prefix | suffix | not_prefix |
not_suffix.
The location of the injection inside
location
the URL ('head' or 'body_end').
Whether or not to delete existing

HTML content.
delete_content Yes
Possible values: true/false
Response structure:
The structure is the same as for Get HTML injection rules.
Example: The following API call removes (if exists) the HTML content from any URL ending with ".php", found in the
BODY section. The content itself does not have to be supplied, any content previously injected in the specified URL,
URL pattern, and Location will be removed.
api_id=123
api_key=abcdefg
url=.php
url_pattern=ends_with
location=body_end
Modify caching mode
delete_content=true
Use this operation to edit basic site caching settings.
/api/prov/v1/sites/performance/cache-mode
Parameters:

site_id
operate on.

Possible values:
• disable
• custom_cache_rules_only
cache_mode • static_only
• static_and_dynamic
• aggressive
Default value: static_only.
Profile dynamic pages and cache

duration. Pass a number followed
by '_' and one of: hr | min | sec |
dynamic_cache_duration Yes
days | weeks.
Default: 5_min
Cache resource duration. Pass a

number followed by '_' and one of:
aggressive_cache_durationhr | min | sec | days | weeks Yes
Default: 1_hr
Response structure:
{
"res": 0,
"res_message": "OK"
}

9413 Unknown/unauthorized site_id the client is not authorized to
operate on it.
Get Caching Mode
Use this operation to get a site's caching mode.
/api/prov/v1/sites/performance/cache-mode/get

Parameters:
Name Description
Response structure:
{
"cache_mode":"static_and_dynamic",
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":"999999"
}
}

operate on it.
Modify secure resources mode
Use this operation to edit basic site caching settings.
/api/prov/v1/sites/performance/secure-resources
Parameters:
Name Description
do_not_cache - Do not cache HTTPS resources
defaults - Use default HTTPS caching. Do not cache

HTML pages
secured_resources_mode
defaults_with_html - Use default HTTPS caching.
Also cache HTML pages
general - Cache HTTPS according to general caching

settings

Response structure:
{
"res": 0,
"res_message": "OK"
}

2 Invalid input Input missing or incorrect
operate on it.
allowed.
Modify stale content settings
When Imperva can't connect to the origin server, serve stale content instead of displaying an error to end users for the
specified amount of time. Expired resources are returned from cache, and refreshed asynchronously in the
background.
/api/prov/v1/sites/performance/stale-content
Parameters:

site_id
operate on.
Pass true to serve stale content,
serve_stale_content
false to disable the option.
Pass ADAPTIVE to use Imperva's

algorithm, or CUSTOM to specify
an amount of time. When using
stale_content_mode Yes
CUSTOM, you must specify the
time and time_unit
parameters.
A positive number representing

time the amount of time to serve stale Yes
content.
Stale content time unit. One of
time_unit Yes
SECONDS, MINUTES, HOURS.

Response structure:
{
"res": 0,
"res_message": "OK"
}

The requested operation is
5 Operation unavailable
currently unavailable.
operate on it.
allowed.
Get stale content settings
When Imperva can't connect to the origin server, Imperva can serve stale content instead of displaying an error to end
users for the specified amount of time. Expired resources are returned from cache, and refreshed asynchronously in
the background.
/api/prov/v1/sites/performance/stale-content/get
Parameters:
Name Description
Response structure:
{
"enabled":true,
"mode":"ADAPTIVE",
"time":11,
"unit":"SECONDS",
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":"999999"
}
}


operate on it.
allowed.
Modify Cache 404 Settings
Use this operation to modify the caching settings of 404 responses for a site.
/api/prov/v1/sites/performance/cache404/modify
Parameters:

site_id
operate on.
Pass 'true' to cache 404 responses,
enable
'false' to disable the option.
A positive number representing
time the amount of time to cache 404 Yes
responses. Default value: 10
Unit of time for caching 404
responses. One of MINUTES,
time_unit Yes
HOURS, DAYS, WEEKS. Default
value: HOURS

operate on it.
allowed.
Get Cache 404 Settings
Use this operation to get the caching settings of 404 responses for a site.
/api/prov/v1/sites/performance/cache404

Parameters:
Name Description
Response structure:
{
"enabled": true,
"time": 10,
"time_unit": "HOURS",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

operate on it.
allowed.
Purge resources
Use this operation to purge site resources.
/api/prov/v1/sites/performance/purge
Parameters:

site_id
operate on.
Comma separated list of URLs
resource_url
where the resource is located.
Comma separated list of pattern.
resource_pattern One of: contains | equals | prefix |
suffix

Should purge all cached resources

on site.
Possible values:
If the parameter does not exist, is

null, or an empty string, it is
ignored and only specific
resources defined by the
resource_pattern and
should_purge_all_site_resources Yes
resource_url parameters are
purged.
true or TRUE: All site resources are

purged.
false or FALSE: Nothing is done.
Any other string: An error is

returned.
Response structure:
The structure is the same as for Modify caching mode.

on it.
Modify caching rules
Use this operation to set-up advanced caching rules.
/api/prov/v1/sites/performance/caching-rules
Parameters:



site_id
operate on.
Comma separated list of always

always_cache_resource_url Yes
cache resources url
Comma separated list of always

cache resources pattern. One of:
contains | equals | prefix | suffix |
always_cache_resource_pattern Yes
not_equals | not_contains |
not_prefix | not_suffix
Duration that resources will be in

cache, pass number followed by
'_' and one of: hr | min | sec | days |
weeks.
Either provide a comma separated Yes

always_cache_resource_duration
list of duration expressions,
matching the number of always
cache rules, or a single duration
expression to be used for all
always cache rules.
Comma separated list of never

never_cache_resource_url Yes
cache resources url.
Comma separated list of never
cache resources pattern. One of:
contains | equals | prefix | suffix |
never_cache_resource_pattern Yes
not_equals | not_contains |
not_prefix | not_suffix
Comma separated list of cached

cache_headers Yes
headers.

clear_always_cache_rules set to "true", the site's always Yes
cache rules will be cleared.
clear_never_cache_rules set to "true", the site's never Yes
cache rules will be cleared.
clear_cache_headers_rulesset to "true", the site's cache Yes
header rules will be cleared.

Response structure:

on it.
Advanced caching settings
Use this operation to modify advanced caching settings.
/api/prov/v1/sites/performance/advanced
Parameters:
Name Description
param
below.
value According to the param value. See table below.
Possible values for param and value parameters:
Name Description
Sets Async validation. Pass "true" or "false" in the
async_validation
value parameter.
Sets the Minify JS. Pass "true" or "false" in the value
minify_javascript
parameter.
Sets the Minify CSS. Pass "true" or "false" in the
minify_css
value parameter
Sets Minify static HTML. Pass "true" or "false" in the
minify_static_html
value parameter
Sets the Compress JPEG. Pass "true" or "false" in the
compress_jpeg
value parameter.
Sets the Progressive Image rendering flag. Pass
progressive_image_rendering
"true" or "false" in the value parameter.
Sets the Aggressive compression rendering flag.
aggressive_compression
Pass "true" or "false" in the value parameter.
Sets the Compress PNG flag. Pass "true" or "false" in
compress_png
the value parameter.

Name Description
"On the fly" Compression. Pass "true" or "false" in
on_the_fly_compression
TCP Pre-Pooling. Pass "true" or "false" in the value
tcp_pre_pooling
parameter.
Comply with no-cache and max-age directives in
comply_no_cache client requests. Pass "true" or "false" in the value
parameter.
Comply with the Vary header. Pass "true" or "false"
comply_vary
in the value parameter.
Use shortest caching duration in case of conflicts.
use_shortest_caching
Prefer 'last modified' over eTag. Pass "true" or
prefer_last_modified
"false" in the value parameter.
Disable client side caching. Pass "true" or "false" in
disable_client_side_caching
Cache 300X responses. Pass "true" or "false" in the
cache_300x
value parameter.
Use the same cache for full and naked domains. For
unite_naked_full_cache example, use the same cached resource for
cache_empty_responses Cache responses that don’t have a message body.
cache_http_10_responses the Content-Length header or chunking. Pass "true"
or "false" in the value parameter.
send_age_header
support_non_sni_clients this option to block non-SNI clients. Pass "true" or
By default, TCP connections that are opened for a
client request remain open for a short time to
origin_connection_reuse handle additional requests that may arrive. This
option disables that behavior.. Pass "true" or "false"
response.
Enables supporting browsers to take advantage of

http_2 the performance enhancements provided by HTTP/2
for your website. Non-supporting browsers can
connect via HTTP/1.0 or HTTP/1.1. HTTP/2 support

Name Description
requires that SSL is configured for your website.
Pass "true" or "false" in the value parameter
Response structure:

on it.
Get advanced caching settings
Use this operation to get advanced caching settings.
/api/prov/v1/sites/performance/advanced/get
Parameters:
Name Description
param
below.
Possible values for param and value parameters:
Name Description
Sets Async validation. Pass "true" or "false" in the
async_validation
value parameter.
Sets the Minify JS. Pass "true" or "false" in the value
minify_javascript
parameter.
Sets the Minify CSS. Pass "true" or "false" in the
minify_css
value parameter
Sets Minify static HTML. Pass "true" or "false" in the
minify_static_html
value parameter
Sets the Compress JPEG. Pass "true" or "false" in the
compress_jpeg
value parameter.
Sets the Progressive Image rendering flag. Pass
progressive_image_rendering
"true" or "false" in the value parameter.

Name Description
Sets the Aggressive compression rendering flag.
aggressive_compression
Sets the Compress PNG flag. Pass "true" or "false" in
compress_png
"On the fly" Compression. Pass "true" or "false" in
on_the_fly_compression
TCP Pre-Pooling. Pass "true" or "false" in the value
tcp_pre_pooling
parameter.
Comply with no-cache and max-age directives in
comply_no_cache client requests. Pass "true" or "false" in the value
parameter.
Comply with the Vary header. Pass "true" or "false"
comply_vary
Use shortest caching duration in case of conflicts.
use_shortest_caching
Prefer 'last modified' over eTag. Pass "true" or
prefer_last_modified
Disable client side caching. Pass "true" or "false" in
disable_client_side_caching
Cache 300X responses. Pass "true" or "false" in the
cache_300x
value parameter.
Use the same cache for full and naked domains. For
unite_naked_full_cache example, use the same cached resource for
cache_empty_responses Cache responses that don’t have a message body.
cache_http_10_responses the Content-Length header or chunking. Pass "true"
or "false" in the value parameter.
send_age_header
support_non_sni_clients this option to block non-SNI clients. Pass "true" or
By default, TCP connections that are opened for a
client request remain open for a short time to
origin_connection_reuse handle additional requests that may arrive. This
option disables that behavior.. Pass "true" or "false"
response.
Enables supporting browsers to take advantage of
http_2
the performance enhancements provided by HTTP/2

Name Description
for your website. Non-supporting browsers can
connect via HTTP/1.0 or HTTP/1.1. HTTP/2 support
requires that SSL is configured for your website.
Pass "true" or "false" in the value parameter
Response structure:
{
"value":true,
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":"999999"
}
}

on it.
Modify cached response headers
Use this operation to modify cached response headers.
/api/prov/v1/sites/performance/response-headers
Parameters:

site_id
operate on.
Comma separated list of header
cache_headers Yes
names to be cached.
Cache all response headers. Pass
"true" or "false" in the value
cache_all_headers parameter. Cannot be selected Yes
together with cache_headers.
Default:false
Response structure:


operate on it.
allowed.
Get cached response headers
Use this operation to get a site's cached response headers.
/api/prov/v1/sites/performance/response-headers/get
Parameters:
Name Description
Response structure:
{
"enabled":true,
"mode":"CUSTOM",
"custom_headers":[
"header1",
"header2",
"header3"
],
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":"999999"
}
}

operate on it.
allowed.

Tag the response according to the value of a header

Specify which origin response header contains the cache tags in your resources
/api/prov/v1/sites/performance/tag-response
Parameters:
Name Description
Specify which origin response header contains the
header
cache tags in your resources. default: "".
Response structure:

operate on it.
allowed.
Get Header to Tag Responses By
Use this operation to get the origin response header containing the cache tags in your resources.
/api/prov/v1/sites/performance/tag-response/get
Parameters:
Name Description
Response structure:
{
"header":"some_header",
"res":0,
"res_message":"OK",

"debug_info":{
"id-info":"999999"
}
}

operate on it.
allowed.
Purge hostname from cache
Use this operation to purge the hostname from the cache.
This API is for customers who use the same CNAME provided by Imperva for multiple hostnames and would like to
change the CNAME for a particular hostname. Purging the hostname is required for the CNAME change to take effect.
/api/prov/v1/sites/hostname/purge
Parameters:
Name Description
host_name The hostname to purge from the cache.
Response structure:
{
"res": 0,
"res_message": "OK"
}

The client is not authorized to
19001 Unauthorized domain
purge this specified hostname.
Get XRay access link
Use this operation to get a URL that enables debug headers on a specific site.
/api/prov/v1/sites/xray/get-link

Parameters:
Name Description
Example request:
Add cache
curl rule
-d api_id=12345 -d api_key=48d69342-eaec-44cf-8a5c-56c4ff1cd5e8 -d site_id=14081980 htt
Use this operation to add a cache rule.
/api/prov/v1/sites/performance/caching-rules/add
Parameters:

site_id
operate on.
name Rule name.
Rule action. See Possible action
action
parameter values.
Rule will trigger only a request that
filter matches this filter. For more Yes
details on filters, see Syntax Guide.
Rule TTL. Only relevant when
action is
ttl Yes
HTTP_CACHE_MAKE_STATIC or
HTTP_CACHE_CLIENT_CACHE_CTL
Rule TTL time unit.
Must be one of SECONDS,

MINUTES, HOURS, DAYS or WEEKS.
If no time unit is provided,
ttl_unit Yes
SECONDS is used.
Only relevant when action is

Value to differentiate by.

differentiated_by_value HTTP_CACHE_DIFFERENTIATE_BY_HEADER
Yes
- header name,


HTTP_CACHE_DIFFERENTIATE_BY_COOKIE
- cookie name,
HTTP_CACHE_DIFFERENTIATE_BY_GEO
- geo location (ISO 3166-1 alpha-2
country codes ), otherwise
irrelevant.
Comma separated list of
params Yes
parameters to ignore.
When set to true: all parameters in

cache key will be ignored.
Default: false.
all_params Yes
Relevant for
HTTP_CACHE_IGNORE_PARAMS
action
tag_name The name of the tag to add. Yes

Add text to the cache key as suffix.
Relevant for the
text Yes
HTTP_CACHE_ENRICH_CACHE_KEY
action
Possible action parameter values
Name Description
HTTP_CACHE_MAKE_STATIC Cache Resource
HTTP_CACHE_CLIENT_CACHE_CTL Cache Resource on Client
HTTP_CACHE_FORCE_UNCACHEABLE Don't Cache Resource
HTTP_CACHE_DIFFERENTIATE_SSL Differentiate Cache Key by HTTP/HTTPS Scheme
HTTP_CACHE_DIFFERENTIATE_BY_HEADER Differentiate Cache Key by Header
HTTP_CACHE_DIFFERENTIATE_BY_COOKIE Differentiate Cache Key by Cookie
HTTP_CACHE_IGNORE_PARAMS Ignore Paramteres in Cache Key
HTTP_CACHE_IGNORE_AUTH_HEADER CacheRuleAction.HTTP_CACHE_IGNORE_AUTH_HEADER
HTTP_CACHE_FORCE_VALIDATION Force User Authentication
HTTP_CACHE_ADD_TAG Create Tag
HTTP_CACHE_ENRICH_CACHE_KEY Enrich Cache Key
Edit cache rule
Use this operation to edit a cache rule.
/api/prov/v1/sites/performance/caching-rules/edit

Parameters:

api_id API authentication identifier. No
api_key API authentication identifier. No
site_id No
operate on.
rule_id ID of the rule to change. No
name Rule name. Yes
Rule action. See Possible action
action No
parameter values.
filter matches this filter. For more Yes
details on filters, see Syntax Guide.
Rule TTL. Only relevant when
action is
ttl Yes
Rule TTL time unit.
Must be one of SECONDS,

MINUTES, HOURS, DAYS or WEEKS.
If no time unit is provided,
ttl_unit Yes
SECONDS is used.
Only relevant when action is

Value to differentiate by.

HTTP_CACHE_DIFFERENTIATE_BY_HEADER
- header name,
HTTP_CACHE_DIFFERENTIATE_BY_COOKIE
differentiated_by_value - cookie name, Yes
HTTP_CACHE_DIFFERENTIATE_BY_GEO
- geo location (ISO 3166-1 alpha-2
country codes ), otherwise
irrelevant.
Comma separated list of
params Yes
parameters to ignore.
When set to true: all parameters in

all_params cache key will be ignored. Yes
Default: false.


Relevant for
HTTP_CACHE_IGNORE_PARAMS
action
tag_name The name of the tag to add. Yes

Add text to the cache key as suffix.
Relevant for the
text Yes
HTTP_CACHE_ENRICH_CACHE_KEY
action
Possible action parameter values
Name Description
HTTP_CACHE_MAKE_STATIC Cache Resource
HTTP_CACHE_CLIENT_CACHE_CTL Cache Resource on Client
HTTP_CACHE_FORCE_UNCACHEABLE Don't Cache Resource
HTTP_CACHE_DIFFERENTIATE_SSL Differentiate Cache Key by HTTP/HTTPS Scheme
HTTP_CACHE_DIFFERENTIATE_BY_HEADER Differentiate Cache Key by Header
HTTP_CACHE_DIFFERENTIATE_BY_COOKIE Differentiate Cache Key by Cookie
HTTP_CACHE_IGNORE_PARAMS Ignore Paramteres in Cache Key
HTTP_CACHE_IGNORE_AUTH_HEADER CacheRuleAction.HTTP_CACHE_IGNORE_AUTH_HEADER
HTTP_CACHE_FORCE_VALIDATION Force User Authentication
HTTP_CACHE_ADD_TAG Create Tag
HTTP_CACHE_ENRICH_CACHE_KEY Enrich Cache Key
Delete cache rule
Use this operation to delete a cache rule.
/api/prov/v1/sites/performance/caching-rules/delete
Parameters:

api_id API authentication identifier. No
api_key API authentication identifier. No
site_id No
operate on.
rule_id ID of the rule to change. No

Object could not be found and
2002 Object is not found
cannot be removed


on it.
allowed.
Enable or disable cache rule
Use this operation to enable or disable a cache rule.
/api/prov/v1/sites/performance/caching-rules/enable
Parameters:
Name Description
rule_id ID of the rule to change.
When true, the rule will be enabled. Set to false to
enable
disable.

Object could not be found and
2002 Object is not found
cannot be removed
on it.
allowed.
List cache rules
Use this operation to list cache rules for a site.
/api/prov/v1/sites/performance/caching-rules/list
Parameters:

site_id
operate on.


the response.
page_size Yes
Default is 50.
Maximum: 100

page_num Yes
Default is 0.
Response structure:
{
"HTTP_CACHE_FORCE_UNCACHEABLE": [
{
"id": "3746",
"name": "rule1",
"action": "HTTP_CACHE_FORCE_UNCACHEABLE",
"filter": "URL == \"/admin\"",
"disabled": "false",
"disabledByCacheMode": "false"
}
],
"HTTP_CACHE_DIFFERENTIATE_BY_COOKIE": [
{
"id": "3749",
"name": "rule3",
"action": "HTTP_CACHE_DIFFERENTIATE_BY_COOKIE",
"filter": "CookieExists == \"xGroup\"",
"differentiatedByValue": "xGroup"
}
],
"HTTP_CACHE_CREATE_TAG": [
{
"id": "3745",
"name": "rule4",
"action": "HTTP_CACHE_CREATE_TAG",
"filter": User-Agent contains \"Iphone\" | User-Agent contains \"Android\"",
"tag": "mobile",
}
],
"HTTP_CACHE_IGNORE_PARAMS": [
{

"id": "3751",
"name": "rule7",
"action": "HTTP_CACHE_IGNORE_PARAMS",
"params": "oid",
"filter": "ParamExists == \"oid\"",
},
{
"id": "3752",
"name": "rule8",
"action": "HTTP_CACHE_IGNORE_PARAMS",
"params": "xid",
"filter": "ParamExists == \"xid\"",
}
],
"HTTP_CACHE_MAKE_STATIC": [
{
"id": "3744",
"name": "rule9",
"action": "HTTP_CACHE_MAKE_STATIC",
"ttl": "1",
"ttlUnit": "MINUTES",
"filter": "URL == \"/admin\"",
}
]
Create
} new CSR
Use this operation to create a certificate signing request (CSR) for your site. For details on how to provide Imperva
with a custom certificate without a private key, see Upload a Certificate without a Private Key.
/api/prov/v1/sites/customCertificate/csr
Parameters:

site_id
operate on.
The common name. For example:
www.example.com,
domain Yes
hello.example.com, example.com.
Defaults to the site display name.


email Yes
joe@example.com
The legal name of your
organization. This should not be
organization Yes
abbreviated or include suffixes
such as Inc., Corp., or LLC.
The division of your organization
organization_unit handling the certificate. For Yes
example, "IT Department".
The two-letter ISO code for the
country country where your organization is Yes
located.
The state/region where your
state organization is located. This Yes
should not be abbreviated.
The city where your organization is
city Yes
located.
Response structure:
{
"csr_content":"-----BEGIN CERTIFICATE REQUEST-----\nMIICyTCCAbECAQAwgYMxCzAJBgNVBAYT
"res": 0,
}

The site does not support SSL
4205 Site does not have SSL
(HTTPS).
account's plan.
Upload custom certificate
Use this operation to upload a custom certificate for your site.
The following SSL certificate file formats are supported: PFX, PEM, CER.
/api/prov/v1/sites/customCertificate/upload

Parameters:

site_id
operate on.
The certificate file in base64
certificate
format.
The private key of the certificate in
private_key base64 format. Optional in case of Yes
PFX certificate file format.
The passphrase used to protect
passphrase Yes
your SSL certificate.
Example request:
#!/bin/sh
CERT_B64=`base64 -i a.crt`
KEY_B64=`base64 -i a.key`
curl -d api_id=12345 -d api_key=48d69342-eaec-44cf-8a5c-56c4ff1cd5e8 -d site_id=14081980 \

-d certificate="$CERT_B64" -d private_key="$KEY_B64" -d passphrase=12345678 \
https://my.imperva.com/api/prov/v1/sites/customCertificate/upload
Response structure:
{
"res": 0,
"debug_info":{
"details":{
"active":true,
"expirationDate":1460100446000,
"revocationError":false,
"validityError":false,
"chainError":false,
"coverageError":true
},
"id-info":"999999"
}
}
Custom certificate information is provided under 'debug_info'. See the Get site status response structure,
ssl.custom_certificate section.


(HTTPS).
account's plan.
Remove custom certificate
Use this operation to remove custom certificate.
/api/prov/v1/sites/customCertificate/remove
Parameters:
Name Description
Response structure:
{
"res": 0,
"res_message": "OK"
}

(HTTPS).
account's plan.
Add rule
Use this operation to add a security, delivery, or rate rule.
/api/prov/v1/sites/incapRules/add

Parameters:

site_id
operate on.
name Rule name. Yes
Rule action. See the possible
action Yes
values in the table below.

matches this filter. For more
details on filter guidelines, see
filter Syntax Guide. Yes
The filter may contain up to 400

characters.
Redirect rule's response code.

response_code Valid values are 302, 301, 303, 307, Yes
308.
protocol Yes
Add cookie or header if it doesn't
add_missing Yes
exist (Rewrite cookie rule only)
The pattern to rewrite.
For RULE_ACTION_REWRITE_URL -
The URL to rewrite.
For
RULE_ACTION_REWRITE_HEADER
- The header value to rewrite.
from Yes
For
RULE_ACTION_REWRITE_COOKIE -
The cookie value to rewrite.
For
RULE_ACTION_SIMPLIFIED_REDIRECT
- Follow guidelines in Create
Simplified Redirect Rules.
to Yes
The pattern to change to.


The URL to change to.
For
- The header value to change to.
For
The cookie value to change to.
For
Name of cookie or header to

rewrite. Applies only for
rewrite_name RULE_ACTION_REWRITE_COOKIE Yes
and
RULE_ACTION_REWRITE_HEADER.
Data center to forward request to.
dc_id Applies only for Yes
RULE_ACTION_FORWARD_TO_DC.
Context for port forwarding. "Use
Port Value" or "Use Header Name".
port_forwarding_context Yes
Applies only for
RULE_ACTION_FORWARD_TO_PORT.
Port number or header name for
port_forwarding_value port forwarding. Applies only for Yes
The context of the rate counter.
Possible values: IP / Session.
rate_context Yes
Applies only to rules using
RULE_ACTION_RATE.
The interval (in seconds) of the
rate counter. Possible values: A
rate_interval multiple of 10 from 10-300. Applies Yes
only to rules using
RULE_ACTION_RATE.
Apply the rule only to the IP

is_test_mode Yes
address the API request was sent
from.


This option is not available for
Simplified Redirect rules.
Possible action parameter values for Delivery Rules:
Name Description
Redirect the client to a different URL, responding
RULE_ACTION_REDIRECT
with a 30X response.
RULE_ACTION_SIMPLIFIED_REDIRECT with a 30X response. For more details, see Create
Modify the path to which a specific request is
RULE_ACTION_REWRITE_URL
targeted.
Modify or add a request header before passing traffic
Modify or add cookies that are sent by the client to
RULE_ACTION_REWRITE_COOKIE the origin server. The cookie name and value should
be indicated.
Remove a specific request header, which means that
RULE_ACTION_DELETE_HEADER
it won’t be sent to the origin server.
Remove a specific cookie set on the client, which
RULE_ACTION_DELETE_COOKIE
Define the data center to which a specific request
RULE_ACTION_FORWARD_TO_DC
will be sent.
Define the port to which a specific request will be
RULE_ACTION_FORWARD_TO_PORT
sent.
Modify or add a header to the response received
RULE_ACTION_RESPONSE_REWRITE_HEADER
from the origin server.
Remove a specific response header, which means
RULE_ACTION_RESPONSE_DELETE_HEADER
that it won't be returned to the client.
Modify the response code received from the origin
RULE_ACTION_RESPONSE_REWRITE_RESPONSE_CODE
server
Possible action parameter values for security rules:
Name Description
RULE_ACTION_ALERT Generate a non blocking alert for this event.
Block the current request and generate an alert for
RULE_ACTION_BLOCK
this event.
Block the current session and generate an alert for
RULE_ACTION_BLOCK_USER this event. Any subsequent request from the same
Session will be blocked.

Name Description
Block the current IP and generate an alert for this
RULE_ACTION_BLOCK_IP event. Any subsequent request from the same IP will
be blocked for a period of 10 minutes.
Require any client matching the rule filters to
RULE_ACTION_RETRY
support cookies in order to complete the request.
support javascript in order to complete the request.
RULE_ACTION_INTRUSIVE_HTML Since the Javascript test is embedded in an HTML
page, this action should only be enabled for HTML
resources.
Require any client matching the rule filters to pass a
CAPTCHA test in order to complete the request.
RULE_ACTION_CAPTCHA Since the CAPTCHA test is embedded in an HTML
resources.
Possible action parameter values for counter (rate) rules:
Name Description
Count the number of requests received that match
RULE_ACTION_RATE
the rule filter.
Example request:
#!/bin/sh
Edit rule
curl -X POST -d api_id=12345 -d api_key="48d69342-eaec-44cf-8a5c-56c4ff1cd5e8" -d site_id=14
Use this operation to edit an existing security, delivery, or rate rule.
/api/prov/v1/sites/incapRules/edit
Parameters:

rule_id Rule ID.
name Rule name. Yes
Rule action. See the possible
action Yes
values in the table below.
matches this filter. For more
filter Yes
details on filter guidelines, see
Syntax Guide.


Redirect rule's response code.
response_code Valid values are 302, 301, 303, 307, Yes
308.
protocol Yes
Add cookie or header if it doesn't
add_missing Yes
exist (Rewrite cookie rule only)
The pattern to rewrite.
The URL to rewrite.
For
- The header value to rewrite.
from Yes
For
The cookie value to rewrite.
For
The pattern to change to.
The URL to change to.
For
- The header value to change to.
to Yes
For
The cookie value to change to.
For
Name of cookie or header to

rewrite_name rewrite. Applies only for Yes
RULE_ACTION_REWRITE_COOKIE


and
RULE_ACTION_REWRITE_HEADER.
Data center to forward request to.
dc_id Applies only for Yes
RULE_ACTION_FORWARD_TO_DC.
Context for port forwarding. "Use
Port Value" or "Use Header Name".
port_forwarding_context Yes
Applies only for
Port number or header name for
port_forwarding_value port forwarding. Applies only for Yes
The context of the rate counter.
Possible values: IP / Session.
rate_context Yes
Applies only to rules using
RULE_ACTION_RATE.
The interval (in seconds) of the
rate counter. Possible values: A
rate_interval multiple of 10 from 10-300. Applies Yes
only to rules using
RULE_ACTION_RATE.
Make rule apply only for IP address

the API request was sent from.
is_test_mode Yes
This option is not available for
Simplified Redirect rules.
Possible action parameter values for Delivery Rules:
Name Description
RULE_ACTION_REDIRECT
with a 30X response.
RULE_ACTION_SIMPLIFIED_REDIRECT with a 30X response. For more details, see Create
Modify the path to which a specific request is
RULE_ACTION_REWRITE_URL
targeted.
Modify or add a request header before passing traffic
Allows the modification and addition of cookies that
RULE_ACTION_REWRITE_COOKIE are sent by the client to the origin server. The cookie
name and value should be indicated.
Remove a specific request header, which means that
RULE_ACTION_DELETE_HEADER
it won’t be sent to the origin server.

Name Description
Remove a specific cookie set on the client, which
RULE_ACTION_DELETE_COOKIE
Define the data center to which a specific request
RULE_ACTION_FORWARD_TO_DC
will be sent.
Define the port to which a specific request will be
RULE_ACTION_FORWARD_TO_PORT
sent.
Modify or add a header to the response received
RULE_ACTION_RESPONSE_REWRITE_HEADER
from the origin server.
Remove a specific response header, which means
RULE_ACTION_RESPONSE_DELETE_HEADER
that it won't be returned to the client.
Modify the response code received from the origin
RULE_ACTION_RESPONSE_REWRITE_RESPONSE_CODE
server
Possible action parameter values for security rules:
Name Description
RULE_ACTION_ALERT Generate a non blocking alert for this event.
Block the current request and generate an alert for
RULE_ACTION_BLOCK
this event.
Block the current session and generate an alert for
RULE_ACTION_BLOCK_USER this event. Any subsequent request from the same
Session will be blocked.
Block the current IP and generate an alert for this
RULE_ACTION_BLOCK_IP event. Any subsequent request from the same IP will
be blocked for a period of 10 minutes.
RULE_ACTION_RETRY
support cookies in order to complete the request.
support javascript in order to complete the request.
RULE_ACTION_INTRUSIVE_HTML Since the Javascript test is embedded in an HTML
resources.
Require any client matching the rule filters to pass a
CAPTCHA test in order to complete the request.
RULE_ACTION_CAPTCHA Since the CAPTCHA test is embedded in an HTML
resources.
Possible action parameter values for counter (rate) rules:
Name Description
Count the number of requests received that match
RULE_ACTION_RATE
the rule filter.

Example request:
#!/bin/sh
Enable or disable
curl -X POST a rule
-d api_id=12345 -d api_key="48d69342-eaec-44cf-8a5c-56c4ff1cd5e8" -d rule_id=62
Use this operation to enable or disable a security, delivery, or rate rule.
Note: You cannot disable a rate rule that is used by another rule.
/api/prov/v1/sites/incapRules/enableDisable
Parameters:
Name Description
rule_id Rule ID.
When true, the rule will be enabled. Set to false to
enable
disable.
Example request:
#!/bin/sh
curl -X rule
Delete POST -d api_id=12593 -d api_key="64cc622a-9da5-4911-b389-c98a4997b4a0" -d rule_id=10
Use this operation to delete a security, delivery, or rate rule.
Note: You cannot delete a rate rule that is used by another rule.
/api/prov/v1/sites/incapRules/delete
Parameters:
Name Description
rule_id Rule ID.
List rules
Use this operation to list security, delivery, and rate rules for a given site.
/api/prov/v1/sites/incapRules/list

Parameters:

site_id
operate on.
Whether or not delivery rules
include_ad_rules should be included. Defaults to Yes
"Yes".
Whether or not security rules be
include_incap_rules Yes
included. Defaults to "Yes".

the response.
page_size Yes
Default is 50.
Maximum: 100

page_num Yes
Default is 0.
Example request:
#!/bin/sh
curl -X POST "https://my.imperva.com/api/prov/v1/sites/incapRules/list?api_key=48d69342-eaec
Response structure:
{
"incap_rules_data": {
"All": [
{
"id": "3660",
"last_7_days_requests_count": "0",
"name": "Ortal",
"action": "RULE_ACTION_ALERT",
"filter": ""
}
]
},
"ad_rules_data": {
"Redirect": [
{
"to": "/home.php",
"id": "3648",

"priority": "1",
"name": "Test new",
"action": "RULE_ACTION_REWRITE_URL",
"from": "*/home.html",
"filter": "ASN == 1"
}
],
"Forward": [
{
"id": "3628",
"priority": "2",
"name": "move to rewrite",
"dc_id": "54313",
"action": "RULE_ACTION_FORWARD_TO_DC",
"filter": ""
}
]
},
"rate_rules":{
"Rates":[
{
"id":"4723",
"enabled":"true",
"interval":"120",
"name":"Test Rate IP",
"context":"IP",
"action":"RULE_ACTION_RATE",
"internal_name":"test-rate-ip",
"filter":" ASN == 2"
}
]
}
Set
} rule priority
Use this operation to change a Delivery Rule's priority.
/api/prov/v1/sites/incapRules/priority/set
Parameters:
Name Description
rule_id Rule ID.
priority New priority for the selected rule.

Example request:
#!/bin/sh
curl -X POST "https://my.imperva.com/api/prov/v1/sites/incapRules/priority/set?api_key=48d69

Add data center
Use this operation to add a data center to a site.
You can configure up to 40 data centers per site.
/api/prov/v1/sites/dataCenters/add
Parameters:

site_id
operate on.
name The new data center's name.
The server's address. Possible
server_address
values: IP, CNAME
is_enabled Enables the data center. Yes
The data center will be available
is_content for specific resources (Forward Yes
Delivery Rules).
Data center load balancing

algorithm. Possible values are:
LB_LEAST_PENDING_REQUESTS -
Server with least pending requests
LB_LEAST_OPEN_CONNECTIONS -
Server with least open
lb_algorithm Yes
connections
LB_SOURCE_IP_HASH - Server by
IP hash
RANDOM - Random server
WEIGHTED - Server by weight

Example request:
#!/bin/sh
curl -X POST "https://my.imperva.com/api/prov/v1/sites/dataCenters/add?api_key=48d69342-eaec
Response structure:
{
"status": "ok",
"datacenter_id": "484377"
Edit
} data center
Use this operation to edit a site's data center.
/api/prov/v1/sites/dataCenters/edit
Parameters:

dc_id The data center's ID.
name The new data center's name. Yes
is_enabled Enables the data center. Yes
Defines the data center as standby
is_standby Yes
for failover.
The data center will be available
is_content for specific resources (Forward Yes
Delivery Rules).
Example request:
#!/bin/sh
Delete
curl -X data center
POST "https://my.imperva.com/api/prov/v1/sites/dataCenters/edit?api_key=48d69342-eae
Use this operation to delete a site's data center.
/api/prov/v1/sites/dataCenters/delete
Parameters:
Name Description

List data centers

Use this operation to list a site's data centers including the data centers' servers.
/api/prov/v1/sites/dataCenters/list
Parameters:
Name Description
Example request:
#!/bin/sh
curl -X POST "https://my.imperva.com/api/prov/v1/sites/dataCenters/list?api_key=48d69342-eae
Response structure:
[
{
"isActive": true,
"id": "54313",
"enabled": "false",
"isStandBy": "false",
"servers": [
{
"id": "1034487",
"enabled": "true",
"address": "69.61.27.182"
}
],
"contentOnly": "true"
}
Add
] server
Use this operation to add a server to a data center.
/api/prov/v1/sites/dataCenters/servers/add

server_address Server IP address. Yes


Set the server as Active (P0) or
is_standby Yes
Standby (P1) (Boolean).
Edit server
Use this operation to edit a server in a data center.
/api/prov/v1/sites/dataCenters/servers/edit
Parameters:

server_id Server ID.
The IP address of the server to
server_address Yes
modify.
Enable or disable the server
is_enabled Yes
(Boolean).
Set the server as Active (P0) or
is_standby Yes
Standby (P1) (Boolean).
Delete server
Use this operation to delete a data center's server.
/api/prov/v1/sites/dataCenters/servers/delete
Parameters:
Name Description
server_id Server ID.
Check CAA compliance
Check site’s associated SANs for CAA compliance. If a given SAN is compliant, its SSL domain validation status is
updated accordingly.
This operation returns an updated list of the site’s associated SANs that are not compliant. An empty list indicates that
all SANs are compliant.
/api/prov/v1/caa/check-compliance
Parameters:
Name Description

Name Description
Example request:
curl -X POST -d api_id=12345 -d api_key=48d69342-aaaa-44cf-1a2b-56c4ff1cd5e8 -d site_id=1234
Response structure:
{
"non_compliant_sans": [
"*.caa.incaptest.co"
],
"res": 0,
Move
} site
Use this operation to move a site from one account to another. You can move a site from a master account to one of its
sub accounts, or from one sub account to another.
/api/prov/v1/sites/moveSite
Parameters:
Name Description
site_id Numeric identifier of the site to move.
The numeric identifier of the account which the site
destination_account_id
will be moved to.
Response structure:
{
"dnsInstructions":[
{
"aRecords":[
],
"aaaaRecords":[
],
"dnsComment":""
}
],
"status":"",
"sslInstructions":[

{
"recordName":"",
"recordType":"",
"recordValue":"",
"sslComment":""
}
],
"res":0,
"res_message":"OK",
"debug_info":{
"id-info":""
}
}
Name Description
dnsInstructions.aRecords The new A records for the site.
dnsInstructions.aaaaRecords The new AAAA records for the site.
For sites pending CA approval, indicates whether
dnsInstructions.dnsComment
DNS changes will be required once the site is moved.
One of the following:
• MOVED - the site successfully moved

status
• PENDING_CA_APPROVAL - the site is awaiting
CA approval
• FAILED - the site was not moved
sslInstructions.recordName DNS record name needed for CA approval.

sslInstructions.recordType DNS record type needed for CA approval.
sslInstructions.recordValue DNS record value needed for CA approval.
sslInstructions.sslComment Additional information about SSL instructions.
Set site data storage region
Use this operation to set the site's data storage region.
/api/prov/v1/sites/data-privacy/region-change
Parameters:
Name Description
data_storage_region The data region to use.

Possible values for reqion:
Name Description
APAC Asia Pacific
EU Europe
US United States
Response structure:
{
"res": 0,
"res_message": "OK"
Get
} site data storage region
Use this operation to get the site's data storage region.
/api/prov/v1/sites/data-privacy/show
Parameters:
Name Description
Response structure:
{
region: EU
"res":0,
"res_message":"OK"
}
Set site regions by origin geolocation
Use this operation to set the data storage region for each new site based on the geolocation of the origin server.
/api/prov/v1/sites/data-privacy/override-by-geo
Parameters:

account_id to operate on. If not specified, Yes
operation will be performed on the


A boolean parameter. If it is set to
"true", the data storage region for
override_site_regions_by_geo
each new site will be based on the
geolocation of the origin server.
Response structure:
{
"res":0,
"res_message":"OK"
Get site}regions by origin geolocation
Use this operation to check if the data storage region for each new site is based on the geolocation of the origin server.
/api/prov/v1/sites/data-privacy/show-override-by-geo
Parameters:

Response structure:
{
"override_site_regions_by_geo": true,
"res":0,
"res_message":"OK"
Set data} center Origin PoP
Set an origin PoP for a given data center.
/api/prov/v1/sites/datacenter/origin-pop/modify
Parameters:



Numeric identifier of the data
dc_id
center to operate on.
The ID of the PoP that serves as an
access point between Imperva and
origin_pop Yes
the customer’s origin server. For
example: “lax”, for Los Angeles.
Get data center recommended Origin PoP
Get a list of recommended origin PoPs for a given data center.
/api/prov/v1/sites/datacenter/origin-pop/recommend
Parameters:

Numeric identifier of the data
dc_id
center to operate on.
Response structure:
{
"pops":[
{
"id":"ord",
"name":"Chicago, IL",
"region":"US Central",
"rtt":1
},
{
"id":"nyc",
"name":"New York, NY",
"region":"US East",
"rtt":8
}
],
"reason":"N/A",
"res": 0,
"debug_info": {
}
Enable }Cache Shield
Enable Cache Shield for a given site.
/api/prov/v1/sites/performance/cache-shield/enable

Parameters:
Name Description
Use true to enable cache shield on the specified site,
enable
and false to disable it.
Is Cache Shield enabled
Use this operation to get the enablement state of the Cache Shield feature for a given site.
/api/prov/v1/sites/performance/cache-shield
Parameters:
Name Description
Modify Error Page
Use this operation to set a custom error page for a given site.
/api/prov/v1/sites/performance/error-page/modify
Parameters:
Name Description
The error page HTML template. $TITLE% and
error_page_template
$BODY$ placeholders are required.
Example requests:
Adding a custom error page: When posting the full HTML file, use single quotation marks around the page code, as
follows:
curl -d "api_id=xxxxx&api_key=xxxxxxxxxxx&site_id=xxxxxx" -d 'error_page_template="INSERT_FU
To remove a custom error page, leave the error_page_template parameter empty, as follows:
curl -d api_id=xxxx -d api_key="xxxxx" -d site_id=12345678 -d "error_page_template=" https:/


operate on it.
allowed.
Get Error Page
Use this operation to get the custom error page for a given site.
/api/prov/v1/sites/performance/error-page
Parameters:
Name Description
Example request:
curl -d api_id=xxxx -d api_key="xxxxxxxxxxx" -d site_id=12345678 https://my.imperva.com/api/

operate on it.
allowed.
Resume Traffic to Active DCs
Use this operation to resume traffic to your active data centers.
When at least one active data center is back up, you can manually reroute your traffic back to the active data center.
Traffic does not revert automatically to your active data centers.
/api/prov/v1/sites/dataCenters/resume
Parameters:
Name Description

Name Description

operate on it.

DDoS Protection for Networks API

The following operations enable you to manage your settings for IP Protection over TCP/IP.
In this topic:
• Protected IP over TCP - Add by Origin IP

• Protected IP over TCP - Add by CNAME
• Protected IP over TCP - Add by DNS and Origin IP
• Protected IP over TCP - Add by DNS and CNAME
• Protected IP over TCP - Edit by Origin IP
• Protected IP over TCP - Edit by CNAME
• Protected IP over TCP - Edit by DNS and Origin IP
• Protected IP over TCP - Edit by DNS and CNAME
• Protected IP over TCP - Edit HA Protocol Setting
• Protected IP over TCP - Remove
Protected IP over TCP - Add by Origin IP
Use this operation to onboard a public origin IP to the 'IP Protection over TCP' service.
If successful, the operation will return the generated Edge IP.
/api/prov/v1/ddos-protection/edge-ip/add/ip
Parameters:

Public origin IP to onboard to
origin_id
service
Provide 'true' to enable the Proxy
enable_ha_protocol Protocol setting (disabled by Yes
default)
Optional description for the
description Yes
generated Edge IP
Response structure:
{
"origin_ip": "1.2.3.4",
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}


3015 Internal error Internal error. Please try again.
Exceeded the number of IPs for IP
7002 IP Protection quota exceeded
protection defined in plan
The provided IP cannot be used.
Either it is not a valid internet
7003 IP cannot be used
address or a different owner was
detected
Could not onboard the provided
entity. It already has IP Protection
7007 This entity is already protected
and duplicate protection is not
currently allowed.
Protected IP over TCP - Add by CNAME
Use this operation to onboard a CNAME record to the 'IP Protection over TCP' service.
/api/prov/v1/ddos-protection/edge-ip/add/cname
Parameters:

CNAME record to onboard to
cname
service
default)
description Yes
generated Edge IP
Response structure:
{
"cname": "imperva.test.com",
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}


protection defined in plan
currently allowed.
The provided CNAME cannot be
used. Either it is not a valid CNAME
7008 CNAME cannot be used
record or a different owner was
detected.
Protected IP over TCP - Add by DNS and Origin IP
Use this operation to onboard a public origin IP with an associated DNS name to the 'IP Protection over TCP' service.
If DNS check is enabled, the response will include the list of resolved IPs for the provided domain name, and the
operation will only succeed if the provided origin IP will be included in that list.
/api/prov/v1/ddos-protection/edge-ip/add/dns-with-ip
Parameters:

Domain name to onboard to
dns_name
service
origin_ip
service
Provide 'true' to disable DNS
disable_dns_check resolution check (enabled by Yes
default)
default)
description Yes
generated Edge IP
Response structure:
{
"resolved_ips": [
"157.166.226.25",

"157.166.248.11",
"157.166.249.10"
],
"origin_ip": "157.166.249.10",
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

Operation failed. The IP you
provided could not be found
IP not among DNS resolved among the DNS resolved records.
7001
records Please retry with one of the
resolved IPs included in the
response.
protection defined in plan.
detected
The provided domain name
cannot be used. Either it is not a
7004 Domain name cannot be used
valid internet domain or a
different owner was detected.
No records were found for the
7005 No DNS records found
provided domain name.
currently allowed.
Protected IP over TCP - Add by DNS and CNAME
Use this operation to onboard a CNAME record with an associated DNS name to the 'IP Protection over TCP' service.
If DNS check is enabled, the response will include the list of resolved CNAME records for the provided domain name,
and the operation will only succeed if the provided CNAME will be included in that list.
/api/prov/v1/ddos-protection/edge-ip/add/dns-with-cname

Parameters:

dns_name
service
CNAME record to onboard to
cname
service
default)
default)
description Yes
generated Edge IP
Response structure:
{
"resolved_cnames": [
"imperva.test.com"
],
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

protection defined in plan.


currently allowed.
detected.
Operation failed. The CNAME you
CNAME not among DNS resolved among the DNS resolved records.
7009
resolved CNAMEs included in the
response.
Protected IP over TCP - Edit by Origin IP
Use this operation to assign a new origin IP to the provided Edge IP under the 'IP Protection over TCP' service.
This operation is also able to change the type of the entity protected by the provided Edge IP (Any existing
combination of Origin IP/CNAME and DNS name will be overwritten).
If successful, the operation will return the Edge IP.
WARNING: Any entity already protected by this Edge IP prior to the change will no longer be protected once
modification is successful, unless duplicate protection is used.
/api/prov/v1/ddos-protection/edge-ip/edit/ip
Parameters:

origin_ip
service
edge_ip Imperva generated Edge IP
Response structure:
{
"origin_ip": "5.6.7.8",
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}


detected
Could not find the provided Edge
7006 Edge IP not found IP. It may have already been
deleted.
currently allowed.
Protected IP over TCP - Edit by CNAME
Use this operation to assign a new CNAME record to the provided Edge IP under the 'IP Protection over TCP' service.
combination of Origin IP/CNAME and DNS will be overwritten).
/api/prov/v1/ddos-protection/edge-ip/edit/cname
Parameters:

cname CNAME to onboard to service
Response structure:
{
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}


deleted.
currently allowed.
detected.
Protected IP over TCP - Edit by DNS and Origin IP
Use this operation to assign a new origin IP with an associated DNS name to the provided Edge IP under the 'IP
Protection over TCP' service.
If DNS check is enabled, the response will include the list of resolved IPs for the provided domain name, and the
operation will only succeed if the provided origin IP is included in that list.
/api/prov/v1/ddos-protection/edge-ip/edit/dns-with-ip
Parameters:

origin_ip
service
dns_name
service
default)

Response structure:
{
"resolved_ips": [
"157.166.226.25",
"157.166.248.11",
"157.166.249.10"
],
"origin_ip": "157.166.249.10",
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

Operation failed. The IP you
IP not among DNS resolved among the DNS resolved records.
7001
resolved IPs included in the
response.
detected
deleted.
currently allowed.
Protected IP over TCP - Edit by DNS and CNAME
Use this operation to assign a new CNAME record with an associated DNS name to the provided Edge IP under the 'IP
Protection over TCP' service.

If DNS check is enabled, the response will include the list of resolved CNAME records for the provided domain name,
and the operation will only succeed if the provided CNAME is included in that list.
/api/prov/v1/ddos-protection/edge-ip/edit/dns-with-cname
Parameters:

cname CNAME to onboard to service
dns_name
service
default)
Response structure:
{
"resolved_cnames": [
"imperva.test.com"
],
"edge_ip": "172.17.14.1",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}



deleted.
currently allowed.
detected.
Operation failed. The CNAME you
CNAME not among DNS resolved among the DNS resolved records.
7009
resolved CNAMEs included in the
response.
Protected IP over TCP - Edit HA Protocol Setting
Use this operation on the provided Edge IP to toggle its HA Protocol setting on or off.
By default, this setting is disabled during onboarding unless explicitly set to 'true'.
WARNING: Do not modify this setting unless you are familiar with the proxy protocol and understand the implications
of enabling or disabling it for your account.
/api/prov/v1/ddos-protection/edge-ip/edit/ha-protocol
Parameters:

enable_ha_protocol
Protocol setting, 'false' to disable
Response structure:
{
"res": 0,
"debug_info": {

"id-info": "999999"
}
}

deleted.
Protected IP over TCP - Remove
Use this operation on the provided Edge IP to remove it from the 'IP Protection over TCP' service.
WARNING: Any entity already protected by this Edge IP will no longer be protected once the operation is successful,
unless duplicate protection was enabled and used.
/api/prov/v1/ddos-protection/edge-ip/remove
Parameters:

Response structure:
{
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

deleted.

Traffic Statistics and Details API

The following operations enable you to retrieve traffic statistics and logs for sites or accounts. Data can be fetched for
one or more sites or for an account.
In this topic:
• Fetch data for sites or accounts

• Get statistics
• Get visits
• Upload public key
• Change Logs Collector Configuration Status
• Get Infrastructure Protection Statistics
• Get Infrastructure Protection Events
• Get Infrastructure Protection Top Items (Table View)
• Get Infrastructure Protection Top Items (Graph View)
• Get Infrastructure Protection Histogram
Fetch data for sites or accounts
To fetch data for a managed account, specify its ID in the account_id parameter.
To fetch data for specific sites, specify their IDs in a comma separated list in the site_id parameter.
To fetch data for all sites of the current account, do not specify the account_id or site_id parameters.
Get statistics
Use this operation to get site statistics for one or more sites. This operation may return multiple statistics, as specified
in the stats parameter.
/api/stats/v1
Parameters:


to fetch data for.
account_id Yes
Note: You must specify either
account_id or site_id.
Time range to fetch data for. For a

detailed description and the list of
time_range possible values, see Cloud
Reference.


1970. Used together with the
time_range parameter to
start specify a custom time range. For a Yes
Reference.
1970. Used together with the
time_range parameter to
end specify a custom time range. For a Yes
Reference.

fetch data for. Multiple sites can be
specified in a comma separated
site_id list. For example: 123,124,125. Yes
Note: You must specify either

account_id or site_id.
Statistics to fetch, as specified in

the table below. Multiple statistics
stats can be specified in a comma
separated list. For possible values
see below.
Time interval in milliseconds

between data points for time
series statistics. (See the
timeseries values in the table
below.)
The default granularity depends

on the specified time range, as
granularity Yes
follows:
• Time range of less than 24

hours: Default granularity is
7200000 (2 hours).
• Time range of between 24
hours and 30 days: Default
granularity is 86400000 (1
day).


• Time range of more than 30
days: Default granularity is
259200000 (3 days).
The response includes one result

for each interval. For example, if
you specify a time range value of
last_7_days, the default
granularity is 1 day, and the
response will return 7 results.
Values for the stats parameters:
Name Description
visits_timeseries Number of visits by type (Humans/Bots) over time.
Number of hits by type (Humans/Bots/Blocked) over
hits_timeseries
time and per second.
Amount of bytes (bandwidth) and bits per second
(throughput) transferred via the Imperva network
bandwidth_timeseries
from clients to proxy servers and vice-versa over
time.
Total number of requests routed via the Imperva
requests_geo_dist_summary
network by data center location.
Total number of visits per client application and
visits_dist_summary
country.
Total number of requests and bytes that were
caching
cached by the Imperva network.
Number of requests and bytes that were cached by
the Imperva network, with one day resolution, with
caching_timeseries
info regarding the caching mode (standard or
advanced).
Total number of threats by type with additional
threats information regarding the security rules
configuration.
List of security rules with total number of reported
incap_rules
incidents for each rule.
List of security rules with a series of reported
incap_rules_timeseries
incidents for each rule with the specified granularity.
List of delivery rules with total number of hits for
delivery_rules
each rule.
List of delivery rules with total number of hits for
delivery_rules_timeseries
each rule with the specified granularity.

The data parameter
For all of the time series parameters, the data parameter gives results as follows:
[<Unix epoch timestamp>,<number of occurrences during the time interval>]
The time interval is defined by the value of the granularity parameter.
This example shows results for two buckets, with the time stamp and number of human visits for each, with
granularity set to 10 minutes.
"visits_timeseries" : [
{
"id":"api.stats.visits_timeseries.human",
"name":"Human visits",
"data":[
[1344247200000,50],
[1344247800000,40],
...
]
},
Structure of the threats statistics:
The threats statistics provide the number of security incidents per threat type and additional information regarding
the configuration of the site with respect to each threat type. When fetching data for multiple sites or for an account
only, the name and incidents parameters will be returned.
Name Description
name Name of threat.
Total number of security incidents of this threat
incidents type. A negative value represents N/A, indicating
that data is not available.
Status of this security rule for the site.

status
Possible values: ok, warning, error
status_text_id ID of the status_text field.

Name of this security rule status. For example, one
status_text of the following: Block | Not Supported | 3 ips in
blacklist | ...
Followup action. For example:
followup api.threats.followup.view or
api.threats.followup.upgrade
followup_text
Name of followup action.

Name Description
Possible values: View Incidents, Upgrade
followup_url URL for followup action.
Response structure:
{
"res": 0,
"visits_timeseries" : [
{
"id":"api.stats.visits_timeseries.human",
"name":"Human visits",
"data":[
[1344247200000,50],
[1344247500000,40],
...
]
},
{
"id":"api.stats.visits_timeseries.bot",
"name":"Bot visits",
"data":[
[1344247200000,10],
[1344247500000,20],
...
]
}
],
"requests_geo_dist_summary" : {
"id":"api.stats.requests_geo_dist_summary.datacenter",
"name":"Requests by data-center location",
"data":[
['Tokyo, JA',24365435],
['Los Angeles, CA',98762738],
...
]
},
"caching" : {
"saved_requests":23984923,
"total_requests":48723648,
"saved_bytes":762394786,
"total_bytes":1098349834
},
"caching_timeseries":[
{
"id":"api.stats.caching_timeseries.hits.standard",
"name":"Standard Requests Caching",

"data":[
[
1349647200000,
5
],
...
]
},
{
"id":"api.stats.caching_timeseries.bytes.standard",
"name":"Standard Bandwidth Caching",
"data":[
[
1349647200000,
3440
],
...
]
},
{
"id":"api.stats.caching_timeseries.hits.advanced",
"name":"Advanced Requests Caching",
"data":[
[
1349647200000,
0
],
...
]
},
{
"id":"api.stats.caching_timeseries.bytes.advanced",
"name":"Advanced Bandwidth Caching",
"data":[
[
1349647200000,
0
],
...
]
},
{
"id":"api.stats.caching_timeseries.hits.total",
"name":"Total Requests",
"data":[
[
1349647200000,
5000
],

...
]
},
{
"id":"api.stats.caching_timeseries.bytes.total",
"name":"Total Bandwidth",
"data":[
[
1349647200000,
10000
],
...
]
},
],
"hits_timeseries":[
{
"id":"api.stats.hits_timeseries.human",
"name":"Human requests",
"data":[
[
1360108800000,
131837
],
...
]
},
{
"id":"api.stats.hits_timeseries.bot",
"name":"Bot requests",
"data":[
[
1360108800000,
81804
],
...
]
},
{
"id":"api.stats.hits_timeseries.blocked",
"name":"Blocked requests",
"data":[
[
1360108800000,
629
],
...
]
},

{
"id":"api.stats.hits_timeseries.human_ps",
"name":"Human requests per second",
"data":[
[
1360108800000,
427
],
...
]
},
{
"id":"api.stats.hits_timeseries.bot_ps",
"name":"Bot requests per second",
"data":[
[
1360108800000,
261
],
...
]
},
{
"id":"api.stats.hits_timeseries.blocked_ps",
"name":"Blocked requests per second",
"data":[
[
1360108800000,
0
],
...
]
}
],
"threats" : [
{
"id":"api.threats.bot_access_control"
"name: "Badbot Visits",
"incidents": 12,
"status": "ok",
"status_text_id": "api.threats.action.block_request",
"status_text": "Block Request",
"followup":"api.threats.followup.view",
"followup_text": "View Incidents",
"followup_url": "https://my.incapsula.com/sites/siteVisits?token=1123_103_132344
},
{
"id":"api.threats.sql_injection"
"name": "SQL Injection",

"incidents": 3,
"status": "error",
"status_text_id": "api.threats.rule_support.not_supported",
"status_text": "Not Supported",
"followup":"api.threats.followup.upgrade",
"followup_text": "Upgrade",
"followup_url": "https://my.incapsula.com/billing/selectplan?token=1123_103_1323
},
...
],
"visits_dist_summary":[
{
"data":[
[
"np",
11
],
[
"no",
778
],
...
],
"id":"api.stats.visits_dist_summary.country",
"name":"Visits by country"
},
{
"data":[
[
"lwp-request",
122
],
[
"elkMonitor",
11550
],
...
],
"id":"api.stats.visits_dist_summary.client_app",
"name":"Visits by client application"
}
],
{
"bandwidth_timeseries":[
{
"data":[
[
1361318400000,

13078801085
],
...
],
"id":"api.stats.bandwidth_timeseries.bandwidth",
"name":"Bandwidth"
},
{
"data":[
[
1361318400000,
2520535
],
...
],
"id":"api.stats.bandwidth_timeseries.bps",
"name":"Bits per second"
}
],
"res":0,
"res_message":"OK"
}
"res":0,
"res_message":"OK"
}
"debug_info": {
"timerange": "last_7_days",
"site_id": 123
}
}

Timerange malformed, missing, or
13001 Timerange invalid the account is not on a supporting
plan.
Granularity malformed or not a
13002 Granularity Invalid
number.
Get visits
Use this operation to get a log of recent visits to a website.
/api/visits/v1
Note: Requests are limited to 10 per site per 10-minute period.
The visits are fetched in reverse chronological order, starting with the most recent visit.

Not all visits are recorded - only visits with abnormal activity are recorded, such as a violation of security rules, visits
from black-listed IPs/Countries, etc.
A visit may still be updated even after it was retrieved. Visits are aggregated into a session, and Imperva may use a
suppression mechanism to trim repetitive events. This session is set by the Imperva reverse proxy and does not
correlate with the application session set between the end user browser and the origin server. To retrieve only visits
that will no longer be updated, use the list_live_visits parameter.
Parameters:

site_id
operate on.
Time range to fetch data for.
time_range Yes
Default is last_7_days.
start Yes
Reference.
end Yes
Reference.
page_size the response. Defaults to 50. Yes
Maximum is 100.
page_num Yes
Default to 0.
Filter the sessions that were
handled according to the security-
related specifications. Multiple
security Yes
values are supported, e.g.:
"api.threats.action.block_ip,
api.threats.sql_injection".
Filter the sessions coming from the
country Yes
specified country.
Filter the sessions coming from the
ip Yes
specified IP.
Comma separated list of visit IDs
visit_id Yes
to load.
Whether or not to list visits that

list_live_visits Yes
did not end and that may still be
updated.


Default: true
Visit fields:

id The ID of this visit.
The timestamp in which this visit
startTime started. For example:
1317952740000
The timestamp in which this visit
endTime ended. For example: Yes
1317952740000
The IP addresses used by the
clientIPs
client.
The code of the country the site
countryCode
was visited from.
The country the site was visited
country
from.
The client software application
clientType
category. For example, Browser
The client software application.
clientApplication
For example: Firefox
The version of the client software
clientApplicationVersion Yes
application.
The HTTP version number. One of:
httpVersion
1.0, 1.1 or 2.0
userAgent The UserAgent header value.
os The operating system type. Yes
osVersion The operating system version. Yes
Whether or not the client
supportsCookies application software supports Yes
cookies.
Whether or not the client
supportsJavaScript application software supports Yes
JavaScript.
The total number of HTTP requests
hits in this visit, including requests to
images, static resources, etc.
The total number of pages viewed
pageViews
in this visit.
The referrer header value of the
entryReferer Yes
first request to this visit, i.e. the


last URL viewed by the client
application before navigating to
the site.
The URL of the first request in this
entryPage Yes
visit.
The Imperva data center from
servedVia
which this request was served.
The actions that took place for the
current session. Each such session
actions Yes
may include specific threats, with
its related details.
A mapping between the security
securitySummary rules (and acls) that took place per
this session, and their frequency.
Action fields:

The threats associated with the
threats Yes
action.
For post requests, the request
postData body. The value is Base64- Yes
encoded.
The decision made by the Imperva
requestResult proxy server on how to process the
request.
The number of milliseconds it took
responseTime Yes
the server to return the response.
The number of milliseconds it took
thinkTime the server to generate the Yes
response.
The HTTP response status code
httpStatus that was received from the origin Yes
server.
Threat fields:

The security rule associated with
securityRule the threat, e.g.
api.threats.illegal_resource_access.
Imperva internal threat
attackCodes Yes
categorization.
The location of the alert,
alertLocation Yes
"api.alert_location." + one of:


path, param_name, param_value,
response_data.
threatPattern The payload of the threat. Yes
The action taken to mitigate the
securityRuleAction
threat.
Response structure:
{
"visits":[
{
"id":"133077760038625792",
"siteId":7,
"startTime":1361468485000,
"clientIPs":[
"12.13.14.15"
],
"country":[
"Sweden"
],
"countryCode":[
"SE"
],
"clientType":"Unclassified",
"clientApplication":"Bot",
"clientApplicationVersion":"0",
"httpVersion":"2.0",
"userAgent":"Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)",
"os":"Windows",
"osVersion":"Windows",
"supportsCookies":true,
"supportsJavaScript":false,
"hits":1,
"pageViews":1,
"entryReferer":"http://lp.usafis.org/_Incapsula_Resource?CWUDNSAI=9_E1521557&inc
"entryPage":"www.incapsula.com/ddos/ddos-mitigation-services",
"servedVia":[
"Los Angeles,
CA"
],
"securitySummary":{ // The following lists detected threats
"api.threats.sql_injection" : 2,
"api.threats.cross_site_scripting" : 1,
"api.threats.illegal_resource_access" : 3,
"api.threats.remote_file_inclusion" : 2,
"api.threats.customRule" : 3,
"api.threats.ddos=DDoS" : 4,
"api.threats.backdoor" : 2,

// Bot Access Control may only take 1 as value, indicating t

"api.threats.bot_access_control" : 1,
// Blacklists may only take 1 as value, indicating some requ
"api.acl.blacklisted_countries" : 1,
"api.acl.blacklisted_urls" : 1,
"api.acl.blacklisted_ips" : 1
},
"actions":[
{
"requestResult":"api.request_result.req_challenge_javascript",
"isSecured":false,
"url":"www.google.com/ddos/ddos-mitigation-services",
"threats":[
{
"securityRule":"api.threats.illegal_resource_access",
"alertLocation":"api.alert_location.alert_location_path",
"attackCodes":[
"9070.0"
],
"securityRuleAction":"api.rule_action_type.rule_action_block"
},
{
"securityRule":"api.threats.bot_access_control",
"alertLocation":"api.alert_location.alert_location_path",
"attackCodes":[
"915.0"
],
"securityRuleAction":"api.rule_action_type.rule_action_block"
}
]
}
]
},
...
],
"res": 0,
"debug_info": {
"site_id": 123
}
Upload
} public key
Available only for customers that purchased the Security Logs Integration SKU.
Overview
Organizations that purchased the Security Logs Integration SKU can download security events created for their
account and archive or push those events into their SIEM solution.

In both cases, it is highly recommended to encrypt the events using a private-public key pair generated by the
customer.
Imperva uses two layers for encrypting the security events:
• Imperva encrypts the security events using a symmetric key.

• The symmetric key itself is asymmetrically encrypted using a public key supplied by the customer.
In order to decrypt the security events, the customer needs to:
• Use the private key to decrypt the symmetric key.

• Use the symmetric key to decrypt the security events in the log file sent by Imperva.
Using the API
The Upload Public Key API is used to upload the public key created by the customer.
Once the API is successfully invoked, the new public key is used to encrypt the symmetric key (used for encrypting the
log files). Since the process of replacing/updating the public key may take several seconds, the customer decrypting
the log files should prepare to use the correct private key.
To let the customer know what public key was used for the encryption (and accordingly what private key to use for the
decryption), the Upload Public Key API returns an ID uniquely identifying the key pair. This ID is also added to the log
file’s metadata.
Customers should maintain the mapping between the ID and the key pair.
/api/logscollector/upload/publickey
Parameters:
Name Description
config_id The Logs Collector configuration identifier.
The public key file (2048bit) in base64 format
public_key
(without password protection).
Response structure:
The response contains the public key ID generated by Imperva.
{
"publicKeyId":1,
"res":0,
"res_message":"OK"
}


The input is not a valid RSA public
13007 Invalid public key
key.
The configuration ID doesn’t exist
13008 Invalid configuration ID or is not authorized with the
provided API key and ID.
The uploaded key length is
13009 Insufficient key length insufficient, please uplaod 2048bit
length key.
Change Logs Collector Configuration Status
Available only for customers that purchased the Security Logs Integration SKU.
Use this operation to change the status of the Logs Collector configuration.
/api/logscollector/change/status
Parameters:
Name Description
config_id The Logs Collector configuration identifier.
The new configuration status of the Logs Collector.

logs_config_new_status
Possible values: ACTIVE, SUSPENDED
Response structure:
{
"res":0,
"res_message":"OK"
}

The configuration ID doesn’t exist
13008 Invalid configuration ID or is not authorized with the
provided API key and ID.

Get Infrastructure Protection Statistics

Use this operation to get Infrastructure Protection statistics for an account or IP range.
/api/v1/infra/stats
Parameters:

Specific Protected IP or IP range.
ip_prefix Yes
For example, 1.1.1.0/24.
Specific traffic. One of: Total,
traffic Yes
Passed, Blocked.
A comma separated list of specific
traffic types. Any of: UDP, TCP,
DNS, DNS_RESPONSE, ICMP, SYN,
traffic_type Yes
FRAG, LARGE_SYN, NTP, NETFLOW,
SSDP, GENERAL. Cannot be used
together with the pop parameter.
PoP names. For example: iad, tko.
Cannot be used together with the
pop Yes
traffic_type parameter. For
the list of PoP codes and locations,
see Imperva Data Centers (PoPs).
The start date in milliseconds,
since 1970. For a detailed
start Yes
description, see Cloud Application
Security API Reference.
The end date in milliseconds, since
end Yes
Reference.
Response structure:
{
"stats":[
{
"objectId":607074,

"payload":[
{
"interval":15000,
"startTime":1509936300000,
"data":[
0,
15,
...
],
"metric":"pps",
"pop":"tko",
"ipPrefix":"192.168.205.0/24",
"ipPrefixType":"bgp",
"traffic":"passed"
},
{
"interval":15000,
"startTime":1509936300000,
"data":[
7968575,
8484564,
...
],
"metric":"bw",
"pop":"tko",
"ipPrefix":"192.168.205.0/24",
"ipPrefixType":"bgp",
"traffic":"passed"
},
...
]
},
...
],
"res": 0,
"debug_info": {
}
Get
} Infrastructure Protection Events
Use this operation to get Infrastructure Protection event information for an account.
/api/v1/infra/events
Parameters:



event types. Any of:
GRE_TUNNEL_UP,
GRE_TUNNEL_DOWN,
ORIGIN_CONNECTION_GRE_UP,
ORIGIN_CONNECTION_GRE_DOWN,
ORIGIN_CONNECTION_ECX_UP,
ORIGIN_CONNECTION_ECX_DOWN,
ORIGIN_CONNECTION_CROSS_CONNECT_UP,
ORIGIN_CONNECTION_CROSS_CONNECT_DOWN,
event_type Yes
DDOS_START_IP_RANGE,
DDOS_STOP_IP_RANGE,
DDOS_QUIET_TIME_IP_RANGE,
EXPORTER_NO_DATA,
EXPORTER_BAD_DATA,
EXPORTER_GOOD_DATA,
MONITORING_CRITICAL_ATTACK,
PROTECTED_IP_STATUS_UP,
PROTECTED_IP_STATUS_DOWN,
PER_IP_DDOS_START_IP_RANGE.
Specific Protected IP or IP range.
ip_prefix Yes
For example, 1.1.1.0/24.

the response.
page_size Yes
Default: 50
Maximum: 100

page_num Yes
Default: 0
start Yes
end Yes
Reference.

Response structure:
{
"events":[
{
"eventTime":"2017-12-08 10:54:59 UTC",
"eventType":"DDOS_STOP_IP_RANGE",
"bwTotal":9000,
"ppsTotal":90,
"bwPassed":200,
"ppsPassed":87,
"bwBlocked":8800,
"ppsBlocked":3,
"eventTarget":"103.28.250.93/32",
"itemType":"IP_RANGE",
"reportedByPop":"zrh",
},
...
],
"res": 0,
"debug_info": {
}
Get
} Infrastructure Protection Top Items (Table View)
Use this operation to view the highest peak values and highest average values for a protected IP range during a
/api/v1/infra/top-table
Parameters:

ip_range The customer's IP range.
One of the following: BGP,
range_type
NETFLOW, PROTECTED_IP
start


end
Reference.
One of the following: SRC_IP,
data_type DST_IP, SRC_PORT_PROTOCOL,
DST_PORT_PROTOCOL
metric_type One of the following: BW, PPS
mitigation_type One of the following: BLOCK, PASS
One of the following: PEAK,
aggregation_type
AVERAGE
The data region to use. If not
data_storage_region specified, account's default data Yes
region will be used.
Possible values for data storage region
Name Description
EU Europe
US United States of America
APAC Asia Pacific
Response structure
{
"stats":[
{
"object":"100.13.0.1",
"value":334229.33,
"total":1111616
},
{
"object":"100.13.0.3",
"value":334160,
"total":1109938
},
...
],
"res":0,
"res_message":"OK",
"debug_info":{
}
Get
} Infrastructure Protection Top Items (Graph View)
Use this operation to view the highest peak values and highest average values for a protected IP range during a

/api/v1/infra/top-graph
Parameters:

range_type
NETFLOW, PROTECTED_IP
start
end
Reference.
One of the following: SRC_IP,
data_type DST_IP, SRC_PORT_PROTOCOL,
DST_PORT_PROTOCOL
metric_type One of the following: BW, PPS
A comma separated list of items to
fetch data for. e.g., 10.10.10.10,
objects Yes
2.2.2.2. If not specified, top items
are automatically fetched.
Name Description
EU Europe
APAC Asia Pacific
Response structure
{
"stats":[

{
"objectId":200,
"time":1522761000000,
"payload":[
{
"interval":15000,
"startTime":1522761000000,
"data":[
4627,
4067,
4245,
...
],
"metric":"pps",
"dataType":"ip",
"item":"100.13.0.1",
"traffic":"blocked"
},
{
"interval":15000,
"startTime":1522761000000,
"data":[
331656,
333291,
333387,
...
],
"metric":"pps",
"dataType":"ip",
"item":"100.13.0.3",
"traffic":"blocked"
},
...
]
}
],
"res":0,
"res_message":"OK",
"debug_info":{
}
Get
} Infrastructure Protection Histogram
Use this operation to view the highest packet size values for a protected IP range during a selected time period.
/api/v1/infra/histogram

Parameters:

range_type
PROTECTED_IP
start
end
Reference.
Name Description
EU Europe
APAC Asia Pacific
Response structure
{
"stats":{
"PL_100":366450640,
"PL_200":305475960,
"PL_300":0,
"PL_400":0,
"PL_500":0,
"PL_600":0,
"PL_700":0,
"PL_800":6053680,
"PL_900":0,
"PL_1000":0,

"PL_1100":0,
"PL_1200":0,
"PL_1300":0,
"PL_1400":0,
"PL_1500":0
},
"res":0,
"res_message":"OK",
"debug_info":{
}
}

Login Protect API

The Login Protect API can be used to provision Login Protect users and to configure the protected pages.
In this topic:
• Overview
• Add Login Protect User
• Edit Login Protect User
• Get Login Protect User
• Remove Login Protect User
• Send SMS to User
• Modify Site Login Protect Configuration
• Configure Login Protect on Admin Areas
Overview
What is Login Protect?
Imperva’s Login Protect feature lets online businesses implement strong two-factor authentication on any website or
application without integration, coding, or software changes.
Single-click activation lets you protect administrative access to any page or URL, secure remote access to corporate
web applications, and restrict access to a particular webpage.
Login Protect manages and controls multiple logins across several websites in a centralized manner. Two-factor
authentication is supported using either email, SMS, or Google Authenticator.
User Provisioning
Login Protect users are the users that will be allowed to access the protected pages. They are added to the account’s
Login Protect users list. Access permissions for specific sites can be decided during configuration of the site's
protected pages. Login Protect users can be provisioned using the Add Login Protect User API call.
If user details are available they can be associated with each user using the name, email and phone parameters.
If the details are not available the should_send_activation_email parameter should be set to True, in which case
users will get an activation email in which they will be able to enter their details.
(The “Send SMS” API call can be used in order to validate a user’s phone number, in case the
should_send_activation_email option is not used. In that case, it is advised to generate a random code, and send it
to the user’s phone using the Send SMS to User API call ).
Configuring protected pages for a site
Protected pages are added using the Modify Site Login Protect Configuration API call. The URLs of the protected pages
can be entered, in comma separated format, using the “urls” parameter. In order to define URL patterns (e.g. “URL
starts with” or “URL contains”) use the “url_patterns” parameters in accordance with the entered URLs.

It is also possible to allow access to specific users out of the account’s Login Protect users list using the
“specific_users_list” parameter. In order to get notifications on successful user logins to the protected pages use the
“send_lp_notifications“. Allowed authentication methods for the site can be decided using the
“authentication_methods” parameter.
Add Login Protect User
Use this operation to add a Login Protect user for a site.
/api/prov/v1/sites/lp/add-user
Parameters:

account_id
to operate on.
email
"joe@example.com"
name Example: John Smith Yes
Phone number, <country code>-
phone <number>. For example: Yes
"1-8662507659"
Whether or not to skip email
is_email_verified Yes
address verification.
Whether or not to skip phone
is_phone_verified Yes
verification.
Whether or not to send activation
should_send_activation_email Yes
email to user.
Response structure:
{
"res": 0,
"debug_info": {
"user E-Mail": "admin@example.com"
}
}

1001 Email invalid
email parameter.


account_id
operate on it.
Could not send email, please
18004 Failed to Send E-Mail
check syntax.
This user already exists under this
18005 Login Protect User Exists
account.
Skipping login protect verification
18006 Operation Not Allowed
is not allowed for this account.
Your account is not allowed to skip
18009 Not Supported Action
Login Protect verification.
Edit Login Protect User
Use this operation to edit a Login Protect user's settings.
/api/prov/v1/sites/lp/edit-user
Parameters:

account_id
to operate on.
email
"joe@example.com"
name Example: John Smith Yes
Phone number, <country code>-
phone <number>. For example: Yes
"1-8662507659"
Whether or not to skip email
is_email_verified Yes
address verification.
Whether or not to skip phone
is_phone_verified Yes
verification.
Whether or not to send activation
should_send_activation_email Yes
email to user.
Example: Edit user's phone number
api_id=123
api_key=your key
account_id=1234
email=user@example.com
phone=1-8662507659
is_phone_verified=true

Response structure:
{
"res": 0,
"debug_info": {
"user E-Mail": "admin@example.com"
}
}

1001 Email invalid
email parameter.
account_id
operate on it.
check syntax.
account.
Your account is not allowed to skip
18009 Not Supported Action
Login Protect verification.
Get Login Protect User
Use this operation to get the account's login protect user list.
/api/prov/v1/sites/lp/users
Parameters:
Name Description
Response structure:
{
"res":0,
"users":[
{
"phone":"617-9876543",
"creation_date":"Jun 17, 2014 10:20:04 AM",
"email":"John@example.com",

"name":"John Doe",
"status":"INVITATION_SENT"
},
{
"phone":"972-38887778",
"creation_date":"May 15, 2012 08:01:11 PM",
"email":"Jame@example.com",
"name":"Jane Doe",
"status":"REVOKED"
}
]
"res_message":"OK"
}

1001 Email invalid
email parameter.
account_id
operate on it.
Phone number is invalid or does
18003 Invalid phone number
not fit the region.
check syntax.
account.
Remove Login Protect User
Use this operation to remove a login protect user from an account's user list.
/api/prov/v1/sites/lp/remove
Parameters:
Name Description
email Email address. For example: "joe@example.com"


1001 Email invalid
email parameter.
account_id
operate on it.
not fit the region.
check syntax.
account.
Send SMS to User
Use this operation to send an SMS to a login protect user.
/api/prov/v1/sites/lp/send-sms
Parameters:
Name Description
email Email address. For example: "joe@example.com"
sms_text Text that will be sent in SMS.

account_id
operate on it.
not fit the region.
Number of allowed SMS a day is
18007 Exceeded Allowed SMS
exceeded.
Could not send SMS, try again
18008 Failed to Send SMS
later.
Login Protect user does not exist
18010 Invalid User
on this account.
18011 Invalid SMS Text Please provide text for the SMS.

Modify Site Login Protect Configuration

Use this operation to change Login Protect settings for a site.
/api/prov/v1/sites/lp/configure
Parameters:

site_id
operate on.
Pass true to enable login protect

on site, and false to disable it.
enabled Yes
Default: true
Comma separated email list to set

login protect users for the site. If
specific_users_list the list is empty all users will be Yes
allowed to access the site using
Login Protect.
Pass true to send notification on

successful login using login
send_lp_notifications protect. Yes
Default: false
Pass true to allow all login protect

users to access the site. If you want
to allow only a specific list of users
to access the site using Login
allow_all_users Yes
Protect set this to false, and add
the list to specific_user_list.
Default: true
Comma separated list of allowed

authentication_methods authentication methods: sms | Yes
email | ga
paths. For example, /home and /
urls Yes
admin/index.html are resource
paths, while http://


www.example.com/home is not.
rfc3986#section-2.1). An empty
URL list will remove all URLs.
A comma separated list of url

patterns. Possible values: contains
| equals | prefix | suffix | not_equals
url_pattern | not_contain | not_prefix | Yes
not_suffix. The patterns should be
in accordance with the matching
urls sent by the urls parameter.
Example: Edit specific users list
api_id=123
api_key=your key
site_id=1234
specific_users_list=user1@example.com,user2@example.com,user3@example.com
allow_all_users=false
Add URL list:
api_id=123
api_key=your key
site_id=1234
urls=/admin,index.php
url_patterns=equals,contains
Response structure:
{
"res": 0,
"res_message": "OK"
}

1001 Email invalid
email parameter.
account_id
operate on it.


on it.
18001 Format invalid Invalid email for specific user list.
Application is not one of
18002 Application invalid
wordpress | joomla | phpBB.
not fit the region.
Configure Login Protect on Admin Areas
Use this operation to configure Login Protect on wordpress | joomla | phpbb admin areas.
/api/prov/v1/sites/lp/configure-app
Parameters:

site_id
operate on.
Protect admin areas of joomla |
proteted_app Yes
wordpress | phpBB.
Configure admin areas for wordpress:
api_id=123
api_key=your key
site_id=1234
protected_app=wordpress

1001 Email invalid
email parameter.
account_id
operate on it.
on it.
18001 Format invalid Invalid email for specific user list.
Application is not one of
18002 Application invalid
wordpress | joomla | phpBB.


not fit the region.

Integration API
The following operations may be used to implement various integration scenarios with the Imperva service.
In this topic:
• Get Imperva IP ranges

• Get texts
• Get geographical info
• Get client application info
Get Imperva IP ranges
Use this operation to get the updated list of Imperva IP ranges. This list may be used to define firewall rules that
restrict access to customers sites from non-Imperva IPs.
/api/integration/v1/ips
Parameters:
Response format.
Possible values: json | apache |

resp_format Yes
nginx | iptables | text
Default: json
Response structure:
// JSON format
{
"ipRanges":[
"199.83.128.0/21",
"198.143.32.0/19",
...
],
"ipv6Ranges":[
"2a02:e980::/29"
],
"res":0,
"res_message":"OK"
}
// Apache htaccess format

order deny,allow
deny from all

allow from 199.83.128.0/21

allow from 198.143.32.0/19
...
// Nginx format
allow 199.83.128.0/21;
allow 198.143.32.0/19;
...
// iptables format
iptables allow host
tcp:in:d=80:s:199.83.128.0/21
tcp:in:d=80:s:198.143.32.0/19
...
// text format
199.83.128.0/21
198.143.32.0/19

14001 Format invalid Format malformed or missing
Get texts
Use this operation to retrieve a list of all text messages that may be part of API responses. For each message a key and
a value are provided. The key is the unique identifier of the message and the value is the message text itself, in the
API's default locale (English).
/api/integration/v1/texts
Parameters:
Name Description
Response structure:
{
"texts" : {
"api.stats.visits_timeseries.human":"Human visits",
"api.stats.visits_timeseries.bot":"Bot visits",
...
"api.threats.followup.view":"View Incidents"
},
"res": 0,
}

Get geographical info

Use this operation to retrieve a list of all the countries and continents codes.
/api/integration/v1/geo
Parameters:
Name Description
Response structure:
{
"countriesCodes":{
"BD":"Bangladesh",
"BE":"Belgium",
...
},
"continentsCodes":{
"AF":"Africa",
...
},
"res": 0,
Get
} client application info
Use this operation to retrieve a list of all the client applications.
/api/integration/v1/clapps
Parameters:
Name Description
Response structure:
{
"clientApps":{
"1":"Firefox",
...
},
"clientAppTypes":{
"1":"Browser",
...

},
"res": 0,
}

Infrastructure Protection Test Alerts API

The Test Alerts API enables you to send dummy notifications. Many of the parameters are optional. If you do not use
them, sample data is created automatically based on your existing configuration and used to generate the test alerts.
There is no impact on your actual configuration.
Note: Make sure your account settings are set up to send notifications to the correct recipients. For details, see
Notifications.
In this topic:
Infrastructure Protection
Infrastructure Protection IP Protection
Monitoring
• DDoS Start • Monitoring Start

• DDoS Stop • IP Protection Status Up • Monitoring Stop
• Connection Up • IP Protection Status Down • Monitoring Bad Data
• Connection Down • Monitoring Attack Start
DDoS Start
Use this operation to send a test notification informing you that an Infrastructure Protection DDoS attack has started.
You can optionally provide additional parameters to determine the magnitude of the attack.
/api/v1/infra-protect/test-alerts/ddos/start
Parameters:

The IP prefix to send a notification
ip_prefix Yes
for. For example, 10.10.10.10.
bps Number of bits per second. Yes
pps Number of packets per second. Yes
Response structure:
{
"ip_prefix": "100.1.2.0/24",
"status": "DDoS start notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}


account's plan.
DDoS Stop
Use this operation to send a test notification informing you that an Infrastructure Protection DDoS attack has ended.
/api/v1/infra-protect/test-alerts/ddos/stop
Parameters:

The IP prefix to send a notification
ip_prefix Yes
for. For example, 10.10.10.10.
Response structure:
{
"ip_prefix": "100.1.2.0/24",
"status": "DDoS stop notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.
Connection Up
Use this operation to send a test notification informing you that the Infrastructure Protection connection is up.
/api/v1/infra-protect/test-alerts/connection/up

Parameters:

The connection to send a
notification for. Enter the
connection name as it appears in
connection_name Yes
the Cloud Security Console’s
Protection Settings page. For
example, Test_GRE_Tunnel.
Response structure:
{
"connection_name": "CONNECTION_NAME",
"status": "Connection up notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.
Connection Down
Use this operation to send a test notification informing you that the Infrastructure Protection connection is down.
/api/v1/infra-protect/test-alerts/connection/down
Parameters:

The connection to send a
notification for. Enter the
connection name as it appears in
connection_name Yes
the Cloud Security Console’s
Protection Settings page. For
example, Test_GRE_Tunnel.

Response structure:
{
"connection_name": "CONNECTION_NAME",
"status": "Connection down notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.
IP Protection Status Up
Use this operation to send a test notification informing you that the IP Protection status is up.
/api/v1/infra-protect/test-alerts/ip-protection-status/up
Parameters:

The IP to send a notification for.
ip_protection Yes
For example, 10.10.10.10.
Response structure:
{
"ip": "100.1.2.1",
"status": "IP Protection - status up notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}



account's plan.
IP Protection Status Down
Use this operation to send a test notification informing you that the IP Protection status is down.
/api/v1/infra-protect/test-alerts/ip-protection-status/down
Parameters:

The IP to send a notification for.
ip_protection Yes
For example, 10.10.10.10.
Response structure:
{
"ip": "100.1.2.1",
"status": "IP Protection - status down notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.
Monitoring Start
Use this operation to send a test notification informing you that NetFlow monitoring has started.
/api/v1/infra-protect/test-alerts/monitoring/start
Parameters:



The exporter IP to send a
notification for. For example,
10.10.10.10. The exporter IP can be
exporter_ip Yes
found in the Cloud Security
Console’s Monitoring Settings
page.
Response structure:
{
"exporter_ip": "100.1.2.1",
"status": "Monitoring start notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.
Monitoring Stop
Use this operation to send a test notification informing you that NetFlow monitoring has stopped.
/api/v1/infra-protect/test-alerts/monitoring/stop
Parameters:

exporter_ip Yes
page.
Response structure:
{
"exporter_ip": "100.1.2.1",

"status": "Monitoring stop notification sent successfully",

"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.
Monitoring Bad Data
Use this operation to send a test notification informing you that the monitoring service is receiving messages that do
not conform to the accepted format.
/api/v1/infra-protect/test-alerts/monitoring/bad-data
Parameters:

exporter_ip Yes
page.
Response structure:
{
"exporter_ip": "100.1.2.1",
"status": "Monitoring - bad data notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}


account's plan.
Monitoring Attack Start
Use this operation to send a test notification informing you that the monitoring service has detected a DDoS attack.
/api/v1/infra-protect/test-alerts/monitoring/attack-start
Parameters:

The IP range to send a notification
ip_prefix Yes
for. For example, 1.1.1.0/24.
Packet type. (UDP, TCP, DNS,
DNS_RESPONSE, ICMP, SYN, FRAG,
packet_type Yes
LARGE_SYN, NTP, NETFLOW, SSDP,
GENERAL)
Response structure:
{
"ip_prefix": "100.1.2.1",
"status": "Monitoring attack start notification sent successfully",
"res": 0,
"debug_info": {
"id-info": "999999"
}
}

account's plan.



API Version 2/3 Overview

To better align with REST API standards and best practices, Imperva is gradually rolling out a new version of APIs,
available for your use in managing your Cloud Application Security sites.
All existing version 1 APIs, as documented in the Cloud Application Security API Reference, continue to be supported.
The APIs documented in this section either provide an alternative to existing APIs, or provide APIs with new
functionality.
In this topic:
• What's new in Version 2 and 3?

• Overview
What's new in Version 2 and 3?
• Naming and formatting conventions for the HTTP requests are consistent with REST API standards and best
practices. For example:
• The resource to operate on, such as the rule ID, is included in the core HTTP request and not as an
additional parameter.
• Parameters are sent in JSON format in the body of the request, and not as form data.
• In addition to POST, other common HTTP methods are used (GET, POST, PUT, DELETE).
• In addition to reporting error codes in the response body, proper HTTP response status codes are now also
returned.
Overview
The API has the following characteristics:
• Authentication parameters are sent in the query string.

• All other parameters are specified in JSON format in the request body.
• All requests are in SSL.
• Response content is provided as a JSON document.
• UTF-8 encoding is always used.
• Standard HTTP response error codes are used.
See also:
For more details about Imperva APIs, see Imperva API Documentation.

Cloud WAF v2 API Definition


Imperva Data Centers (PoPs)

Imperva's globally distributed network consists of the following data centers (PoPs) and their locations:
Americas EMEA APAC

Americas
Location Code Facility
Availability
Ashburn, VA, United
IAD Equinix - DC2 ECX
States
Atlanta, GA, United States ATL Equinix - AT1 ECX
Bogota D.C., Bogota,
BOG Equinix - BG1 ECX
Colombia
Buenos Aires, Argentina EZE CenturyLink Artigas - DC4
Chicago, IL, United States ORD Equinix - CH2 ECX
Dallas, TX, United States DFW Equinix - DA2 ECX
Denver, CO, United States DEN CoreSite - DE1
Los Angeles, CA, United
LAX CoreSite - LA1 Megaport
States
Miami, FL, United States MIA Equinix - MI1 ECX
Newark, NJ, United States NYC Equinix - NY1 ECX
Rio de Janeiro, Brazil RIO Equinix - RJ2 ECX
San Jose, CA, United
SJC Equinix - SV5 ECX, Megaport
States
São Paulo, Brazil GRU Equinix - SP3 ECX
Santiago, Chile SCL Entel
Seattle, WA, United States SEA Equinix - SE2 ECX
Toronto, ON, Canada TOR Equinix - TR2 ECX
Tultitlán, Mexico MEX KioNetwork - MEX5
Vancouver, BC, Canada VAN Cologix - VAN 2
EMEA
Availability
Amsterdam, Netherlands AMS Equinix - AMS5 ECX
Cape Town, South Africa CPT Teraco CT1
Copenhagen, Denmark CPH Interxion - CPH1
Dubai, United Arab
DXB Equinix - DX1 ECX
Emirates
Dublin, Ireland DUB Equinix - DB3
Frankfurt, Germany FRA Interxion - FRA7
Istanbul, Turkey IST Verizon - IST1


Availability
Johannesburg, South
JNB Teraco
Africa
Telehouse - Telehouse
London, United Kingdom LON ECX
West
Madrid, Spain MAD Interxion - MAD1
Milan, Italy MXP Equinix - ML2 ECX
Paris, France CDG Equinix - PA3 ECX
Stockholm, Sweden STO Equinix - SK1 ECX
Tel Aviv, Israel MED Med-1
Vienna, Austria VIE Interxion - VIE2
Warsaw, Poland WAR Equinix - WA1
Zürich, Switzerland ZRH Equinix - ZH2 ECX
APAC
Availability
Auckland, New Zealand AKL Vocus - VDC-AKL01
Bangkok, Thailand BKK TCC Technology - BNDC
Hong Kong, Hong Kong HKG Equinix - HK2 ECX
Telin - NeuCentrIX STO
Jakarta, Indonesia CGK
Karet Tengsin
Manilla, Philippines MNL PLDT – VM2
Melbourne, VIC, Australia MEL Equinix - ME1 ECX, Megaport
Mumbai, India BOM Nxtra data - Mumbai II
New Delhi, India NDL Nxtra data - Manesar
Osaka, Japan OSK Equinix - OS1 ECX
Selangor, Malaysia KUL NTT MSC - CBJ3
Seoul, South Korea KOR LG CNS Gasan - KINX
Singapore, Singapore SIN Equinix - SG3 ECX
Sydney, NSW, Australia SYD Equinix - SY2 ECX, Megaport
Chief Telecom - Chief LY
Taipei, Taiwan TPE
Building
Tokyo, Japan TKO Equinix - TY6 ECX

Data Storage Management

The Imperva service provides regional data isolation and control for storing events and network layer data. Data can
be isolated per region, per site, in accordance with data privacy requirements.
In this topic:
• Regional data storage

• View or change the data storage region
• Data storage regions
• Data masking
• Delete stored data
Regional data storage
The data stored for your account includes:
• Events, as displayed on the Events page in the Cloud Security Console, and the associated threat alerts based
on the events.
Threat alerts are generated by the Imperva Cloud Security Console and are also stored temporarily in the
selected region. For more details on threat alerts, see Web Protection - WAF Settings, Website Notification
Settings, and Notifications.
• SIEM integration weblogs
Note: If log integration is enabled for a site, and you do not want data stored in the US, you must use the push
method (SFTP or Amazon S3). When using the pull method (Imperva Cloud Application Security API), Imperva
logs are temporarily stored in the Imperva cloud repository located in the US. For more details on log
integration, see Cloud WAF Log Integration.
• Network layer 3/4 headers, which contain IP addresses.

View or change the data storage region
You can select a default data region for storing events and network layer data. The available regions are APAC, AU, EU,
and US.
The account administrator or a user with the appropriate permissions can set the default data storage region for new
sites created in the account, and also change the region for individual sites.
Account-level settings
The account-level data region setting sets the default storage region for new sites created in your account, and also
determines where network layer data is stored.
By default, network layer data collected for your account by Imperva is stored in the US. You can select an alternative
data storage region.
In the Cloud Security Console, open the Account Settings page and scroll to the Data Management section.

Setting Description
Sets the default data storage region for new sites

created in your account.
Default data storage region
This setting also determines where network layer
data is stored.
Overrides the default setting and enables the system

Override site event data region by origin geolocation to automatically select the WAF event storage
location for each website independently.
For more details, see Account Settings.
Site-level setting
The site-level data region setting determines the geographical region for storing your Layer 7 (application layer)
Imperva data.
By default, data that is collected for a site (events, logs) is assigned to its designated regional PoPs (data centers).
Imperva assigns a region to a site based on geolocation of the origin server registered for the site. You can override the
default storage region defined for your account.
On the Website General Settings page, scroll to the Data Storage section.
Setting Description
Sets the region for storing Layer 7 (application layer)

data for a specific site.
Region
For more details, see Website General Settings.
Data storage regions
APAC EU US AU
• Auckland, New • Amsterdam,

• Ashburn, VA, United
Zealand (AKL) Netherlands (AMS)
States (IAD)
• Bangkok, Thailand • Copenhagen,
• Atlanta, GA, United
(BKK) Denmark (CPH)
States (ATL) • Melbourne, VIC,
• Dubai, United Arab • Frankfurt, Germany
• Chicago, IL, United Australia (MEL)
Emirates (DXB) (FRA)
States (ORD) • Sydney, NSW,
• Hong Kong (HKG) • London, United
• Dallas, TX, United Australia (SYD)
• Johannesburg, Kingdom (LON)
States (DFW)
South Africa (JNB) • Madrid, Spain
• Los Angeles, CA,
• Seoul, South Korea (MAD)
United States (LAX)
(KOR) • Milan, Italy (MXP)

APAC EU US AU
• Miami, FL, United
States (MIA)
• Mumbai, India • Newark, NJ, United
(BOM) • Paris, France (CDG) States (NYC)
• New Delhi, India • Stockholm, Sweden • San Jose, CA,
(NDL) (STO) United States (SJC)
• Osaka, Japan (OSK) • Vienna, Austria (VIE) • São Paulo, Brazil
• Singapore (SIN) • Warsaw, Poland (GRU)
• Taipei, Taiwan (TPE) (WAR) • Seattle, WA, United
• Tel Aviv, Israel • Zürich, Switzerland States (SEA)
(MED) (ZRH) • Toronto, ON,
• Tokyo, Japan (TKO) Canada (TOR)
• Vancouver, BC,
Canada (VAN)
Data masking
You can choose to enable the hashing method for masking fields in your sites' logs and in the Events page, instead of
default (XXX) data masking. For details, see Website General Settings.
Delete stored data
You can permanently delete the data stored for your account. This enables you to remove all potentially sensitive or
personal data that is stored in our systems, such as IP addresses.
Note: Available for account admins only.
• You can delete the data in your account at any time.

• Stored data is deleted from the account and from all sites and sub accounts under the account.
• Data that has been stored up until the time you begin the process is deleted. New data continues to be stored
from this point forward.
• No account or site settings are deleted or changed in any way.
What to expect after the data is deleted:
Feature Description
Events that occurred before the deletion are no

longer displayed.
Website Events page
A session that started prior to the deletion is
completely deleted, including events in the session
that occur after the deletion process began.
Statistics on deleted events are still displayed, as the

Website Dashboard
statistics themselves do not include sensitive data.
SIEM logs If you are using the pull mode for log integration, the
logs created before the deletion are no longer

Feature Description
available for download from the Imperva cloud
repository.
Data from before the deletion is no longer displayed

Infrastructure Protection Analytics
in the Top Traffic Patterns section.
Incidents that occurred before the deletion are no

Attack Analytics
longer displayed.
To delete stored data:
On the Cloud Security Console sidebar, select Management and navigate to Account Settings > Data Management >
Delete sites’ security and access event data and click Delete.
After you click to confirm the deletion, the process begins and an email confirmation is sent to you.
Note: Email notifications are sent to the email addresses listed under E-mail for notifications in your account
settings. For details, see Account Settings.
During the deletion process, a notification banner is displayed when you log in to your Imperva account, indicating
that the deletion is underway. Data is permanently deleted within 48 hours.
When the process is complete, another email notification is sent.

Web Protection - Dedicated Network

Using an Imperva dedicated network ensures that you have a unique static IP address for your website. Once a
dedicated network is allocated, it is never shared among other Imperva clients. As such, it gives you additional control
over your TLS certificates.
Using a dedicated network is recommended to support the following use cases:
• Non-HTTP traffic needs to be passed to the origin server with no WAF inspection (e.g., proprietary protocols).
• HTTP/S traffic needs to bypass WAF inspection and tunnel directly to a specific origin server (impacting all
domains sharing the IP).
• Non-SNI clients, such as APIs, need to be served with a custom SAN certificate for multiple customer domains.
• Non-SNI clients need to be served with a custom cipher-list or TLS versions.
• Only your domains are allowed to appear on the Imperva-generated SAN certificate list, such that no other
brands or competitors will share the same certificate.
Set up of a dedicated network is configured by the Imperva support team. Note that some dedicated network settings
require a Professional Services engagement.

CNAME Reuse
This topic describes how to link multiple domains under the same Imperva site configuration and policy.
Note: The availability of this feature depends on your subscription. For more information or to upgrade your plan,
contact an Imperva sales representative.
In this topic:
• Overview
• The Imperva CNAME reuse flow
• CNAME reuse and third-party CDNs
• CNAME reuse examples
Overview
Imperva enables the use of site settings for several different domains that share the same IP address. This is
implemented by using a CNAME.
Using a CNAME is the most common way to “symlink” one DNS record to another. Queries asking for a specific
destination are referred by domain name to the target destination, which may be located somewhere else on the
internet.
This setup is called CNAME reuse. When you reuse a CNAME, Imperva proxies make a public DNS query in order to find
the host and resolve it to the original site.
To reuse a CNAME, use the CNAME provided by Imperva for all relevant domains that you want to link under the same
site configuration and policy used by the target record.
When configuring CNAME reuse keep in mind that:
• Any domain can use the CNAME of any other domain that is configured as a Website in the Imperva Cloud
Security Console (Cloud WAF).
• The domains sharing the CNAME will also share the Imperva console configuration (dashboards, statistics,
settings, WAF, etc), of the website configured in Imperva.
• CNAME reuse can be used only for domains hosted by the same origin server (same IP address).
• SSL support:
• Imperva-generated certificate (valid for SNI and non-SNI clients): CNAME reuse requires the
multiple domains to be under the same wildcard SAN (e.g. *.somedomain.com) configured on the
Imperva-generated certificate for the website that is configured in Imperva. Otherwise, each domain
should be registered as a separate website.
• Custom certificate (valid for SNI Clients only): CNAME reuse requires the multiple domains to be
listed in the custom certificate uploaded for the website that is configured in Imperva.
CNAME reuse example
Here is a subset of a BIND zone file format with CNAME reuse:

example.com.
3600 IN A 8.8.8.8
www.example.com.
3600 IN CNAME incap.abc123.com.
blog.example.com.
e-
store.example.com.
In this example:
• the same CNAME, incap.abc123.com, is used across all three domains

• the customer's Imperva account contains one site configured in Imperva: example.com (naked domain)
• the customer used its assigned CNAME for two other non-registered sites
For additional examples, see CNAME reuse examples.

The Imperva CNAME reuse flow
1. The HTTP request is received on the Imperva server.
2. The system checks whether the Host header value (i.e., domain name) exists as a site on Imperva.
3. If the domain name is registered on Imperva, the request is sent to that site.
4. If the domain name is not registered on Imperva, it sends the request to the site that is linked with the specific
CNAME.
5. If the request is a cache hit, a response is returned from the site's CDN cache.
6. If the request is a cache miss, it is sent to the origin server IP.
7. The origin recognizes the host name based on the value of the Host header and sends it to the relevant site.
CNAME reuse and third-party CDNs
In some cases, the customer won't be able to point the reused sites directly to the Imperva CNAME. For example, if
there is another CDN in front of Imperva. In that case, the Imperva Support team can create a special CNAME mapping
to ensure that the Imperva proxy correlates between the third-party CDN entry and the relevant Imperva CNAME.
Note: There can be a situation in which a site is already configured on Imperva and in addition, also points to a
CNAME value of a different site on Imperva. In this case, the Imperva proxy sends the request to the Host which is
explicitly configured on Imperva, and not to the derived site that the CNAME value belongs to.
CNAME reuse examples
Use Case 1 - SUPPORTED: Non-SSL sites, different domains, all served by the same origin IP
www.somedomain.com > 8.8.8.8
blog.somedomain.com > 8.8.8.8
www.someotherdomain.com > 8.8.8.8

www.yetanotherdomain.es > 8.8.8.8
In this example, an Imperva customer onboards one site only, such as www.somedomain.com, gets an Imperva
CNAME such as xyz.x.incapdns.net, and points all of their domains to the same CNAME.
www.somedomain.com > xyz.x.incapdns.net
blog.somedomain.com > xyz.x.incapdns.net
www.someotherdomain.com > xyz.x.incapdns.net
www.yetanotherdomain.es > xyz.x.incapdns.net
xyz.x.incapdns.net > 8.8.8.8
Use Case 2 - SUPPORTED: SSL sites, all subdomains covered by same wildcard, served by the same origin IP
Wildcard: *.somedomain.com
Sites:
www.somedomain.com > 8.8.8.8
blog.somedomain.com > 8.8.8.8
api.somedomain.com > 8.8.8.8
In this example, an Imperva customer onboards one site only, such as www.somedomain.com, performs wildcard
domain validation for SSL, gets an Imperva CNAME such as xyz.x.incapdns.net, and points all their sites to the same
CNAME.
www.somedomain.com > xyz.x.incapdns.net
blog.somedomain.com > xyz.x.incapdns.net
api.somedomain.com > xyz.x.incapdns.net
xyz.x.incapdns.net > 8.8.8.8

HTTP/2 FAQ
Answers to some common questions about HTTP/2 and Imperva.
What is HTTP/2?
Hypertext transport protocol (HTTP) is how browsers communicate with web servers and how pages are rendered in
them since the 90s.
HTTP/2 is the latest update to HTTP. It provides multiple new features that enhanced website performance by
resolving HTTP’s inherent limitations.
What Are the Benefits of HTTP/2?
Enhancing Website Performance
• Multiple Requests Served by a Single Server Connection: When HTTP is used to surf a website, the initial
request retrieves the page. Additional items attached to the page, such as JavaScript or images, must each be
retrieved by a separate additional request.
HTTP/2 provides browser multiplexing so that multiple requests can be passed through a single server
connection. This enables the server to push several resources at once, which causes the pages to load more
efficiently and reduces network load.
• Transmission in Binary Code: Older HTTP versions send data via text, which is then translated by the host
through parsing. HTTP/2 transfers information in binary code, which speeds up the connections by offloading
the data transformation efforts.
Increasing Security
Current browsers only support HTTP/2 through an encrypted connection, making it safer than alternative protocols.
How Does HTTP/2 Work?
Imperva acts as a reverse proxy between end-user browsers and the website origin servers.
Imperva serves HTTP/2 to browsers that support it without changing anything between the Imperva proxy and the
origin server.
Imperva HTTP/2 support is not required on the customer web server. Browsers that support HTTP/2 all enforce
encrypted connections and therefore SSL must be enabled.
How Can I See HTTP/2 Traffic Distribution?
Dashboard
To display a graph that shows traffic breakdown by HTTP versions:

3. On the sidebar, click WAF > Dashboards.
4. Click a site name to access the its dashboard.
5. On the Dashboard page, click the Perfomance tab and scroll down to the HTTP versions graph:
To see whether a specific visitor is using HTTP/2:
On the Dashboard page, click the Real-Time tab, then click the Show visitor samples button to display the details of
specific visitors.

Events Log
To see the protocols of a specific client:
3. On the sidebar, click Security Events. The names of the traffic protocols are displayed.

How do I configure HTTP/2?

For details, see:

IPv6 Support
Imperva provides IPv6 support for websites on Imperva’s service.
In this topic:
• What is IPv6?
• The transition from IPv4 to IPv6
• Imperva as your IPv6 gateway
• Providing the end user’s IP address
• IPv4/IPv6 load balancing
• Compressing IPv6 zeros
What is IPv6?
IPv6 (Internet Protocol Version 6) is the successor to Internet Protocol Version 4 (IPv4). IPv6 is being deployed to fulfill
the need for more Internet addresses. The growth of the Internet will soon use up the IPv4 addresses.
IPv6 uses 128-bit addresses that enable up to 2128 addresses (three hundred and forty trillion, trillion trillion unique
IP addresses), which is a lot more than IPv4.
An example IPv6 address is:
2005:db5:5555:5:555:5555:5555:5555
IPv6 is designed to allow the Internet to grow significantly, both in terms of the number of connected hosts and the
total amount of data traffic transmitted.
The transition from IPv4 to IPv6
Currently, IPv4 is still the prevalent Internet Protocol used for addresses. Only a small percentage of traffic is currently
transmitted via IPv6 (maybe less than 5% of total Internet traffic). A variety of Internet leaders, governments and
regulation entities throughout the world are leading the migration to IPv6.
The new IPv6 will coexist with the older IPv4 for some time, possibly for many years. The two protocols are not
designed to be interoperable, thus complicating the transition to IPv6. However, several IPv6 transition mechanisms
have been devised to permit communication between IPv4 and IPv6 hosts.
Imperva as your IPv6 gateway
Imperva provides IPv6 support of both client-side and server-side IPv6 traffic. This means that IPv6 is supported both
for traffic between your end users and Imperva’s PoP and also for traffic between Imperva’s PoP and your origin
servers.
In this way, Imperva can act as an IPv6 gateway for you, so that you can retain your IPv4 setups and Imperva will
service your clients who send IPv4 and IPv6, as needed. This saves you the significant investment of updating your
origin servers’ set up to support IPv6 and allows you to service your clients without having to upgrade your servers.
When a client connects via IPv6, we attempt to connect to the IPv6 origin address. If it is not available or does not
exist, we connect to the origin’s IPv4 address. For example, if your origin server only services IPv4 and an end user
sends an IPv6 message, then Imperva acts as an IPv6 gateway. Imperva receives the IPv6 message and forwards the
message to your origin server according to the server’s unique IPv4 address.

Providing the end user’s IP address

The question arises of how your origin server can access and parse the IP addresses of end users sending IPv6
addresses. For example, for logging and statistics.
For this purpose Imperva adds an RFC HTTP X-Forwarded-For header to each end user request before forwarding it to
your origin server. This is done in a similar manner to how each HTTP proxy adds another X-Forwarded-For header
before forwarding. An X-Forwarded-For (XFF) HTTP header is an existing standard (not originating from IPv6) for
identifying the originating IP address of a client connecting to a web server through an HTTP proxy.
Note: A Request for Comments (RFC) is a formal document from the Internet Engineering Task Force (IETF) that is the
result of committee drafting and subsequent review by interested parties.
Imperva uses the X-Forwarded-For header to append the actual IP address of your end user.
Imperva can append X-Forwarded-For headers that contain the end user’s IPv6 addresses. Appending this X-
Forwarded-For header enables your origin server to see the actual IP address of the end users. Otherwise, the origin
server does not see end users’ IP addresses, but only sees Imperva’s IP address.
Imperva does not activate this functionality by default because, some parsers on the origin side (mostly the ones used
by logging and statistics applications), may not be able to parse IPv6 addresses and will not function properly.
Therefore, in order to get this functionality, you must open a ticket and request it.
In general, an end user’s IP address is not required by applications on your origin server. This is because these
applications can communicate with end users using Imperva’s proxy IP (that was sent in the request). However, if
these applications require an end user’s IP address, then it can be extracted from the X-Forwarded-For header. For
example, an application might require an end user’ s IP address for statistical purposes, marketing purposes or other
purposes that detect the geolocation of the end user.
IPv4/IPv6 load balancing
The following describes how Imperva handles the situation where you have multiple origin servers. In this case some
of your origin servers are IPv4 only, some are IPv6 only and some are dual stack (IPv4 and IPv6).
The dual stack server is treated as if it is two different servers even if they are running on the same physical device.
By default Imperva handles load balancing of IPv4 and IPv6 as follows:
• IPv4 traffic is sent to all servers.

• IPv6 traffic is only sent to the servers that support IPv6.
• However, if all your servers that support IPv6 are down, then IPv6 traffic is sent to your IPv4 servers.
Imperva also enables you to configure load balancing so that IPv6 traffic is only sent to IPv6 servers and IPv4 traffic is
only sent IPv4 servers. Alternatively, you can configure that Imperva sends traffic to any origin server, regardless of
whether it is IPv4 or IPv6.
Contact Imperva support to configure this feature.
Note: Each IP address, regardless of whether it is IPv4 or IPv6 appears separately in the Imperva dashboard. Traffic is
not separated by server in any way. For example, in the scenario described above, each request from a different user

(meaning each IP address) to any server appears separately in the Imperva dashboard. The dual stack server appears
in the Imperva dashboard as if it is two different servers even if they are running on the same physical device.
Compressing IPv6 zeros
Imperva supports both compressed-zeroes format and non-compressed zeros format for entering IPv6 addresses
Many IPv6 addresses contain long sequences of zeros. Imperva simplifies the representation of such IPv6 addresses,
by removing contiguous sequences of zeros according to RFC conventions and using the standard library to do these
conversions.
For example, the following address: 1111:0000000000:000000000:555 is represented by: 1111::555

Basic DNS Terms

The Internet enables people to type recognizable names into a web browser in order to browse to a site (e.g.,
www.yourdomain.com). However, each site actually resides on a specific web server machine that is represented by a
numeric IP address. Each IP address is a unique string of numbers separated by periods (e.g. 123.123.123.123) that
identifies each computer or device connected to the Internet. This long number is much harder for humans to
remember.
A Domain Name System (DNS) server contains a registry that maps each human-readable domain name (e.g.
www.yourdomain.com) to its IP address (e.g. 123.123.123.123), thus enabling visitors to access the relevant site from
anywhere in the world.
DNS Resolution
DNS is a distributed and hierarchical network of servers distributed all over the world. Each end user’s DNS server
does not hold a registry mapping for every domain in the world.
However, each DNS server does know how to navigate through the hierarchy of DNS servers in the world in order to
find that single Authoritative Name Server that contains the mapping of the requested domain to its IP address.
An Authoritative Name Server is the single DNS server responsible for resolving the DNS requests of a specific domain.
In most cases, the Authoritative Name Server of your site is located at your web hosting provider, although some
domains maintain their own Authoritative Name Server.
DNS Caching
Web servers and CDNs maintain a cache of DNS records. Thus, most DNS replies are retrieved from cache and do not
need to refer to the original DNS server. Requests that cannot be resolved using this cached information are passed on
to the original DNS server.
The IP address of each DNS domain request is cached in each DNS server as it is routed through the global hierarchy
of DNS servers in order to find the IP of its single Authoritative Name Server. The visitor’s browser also caches the DNS
in order to improve site performance for repeat visits.
Each such DNS record comes with a Time to Live (TTL) setting that specifies the amount of time that this DNS record
will be cached by each server. After the TTL expires, that DNS record is discarded and a new DNS query is sent to
retrieve the updated address.
DNS Zone
A DNS Zone represents the domain name space that is managed by a single Authoritative Name Server. A DNS Zone
resides on its Authoritative Name Server and contains multiple DNS entries for each sub-domain.
'A' record
An A (address) record is a DNS Zone record that maps a domain name to an IP address.
CNAME record
A CNAME (Canonical Name) record specifies that a domain name is an alias for another domain name.

Naked Domain
A naked domain is simply a domain name without the subdomain prefix. For example, without the www, docs, or help
prefix. At most DNS service providers, only A records are allowed for naked domains.

Attack Analytics
Attack Analytics is a tool to help speed up the security investigation of WAF alerts. It provides a comprehensive view of
attacks and attackers targeting your resources. The Attack Analytics service aggregates and analyzes your account’s
security alerts, identifies common characteristics, and groups them into meaningful security incidents.
For more information, see Attack Analytics and Attack Analytics Documentation .
To open Attack Analytics:

2. On the sidebar, click Attack Analytics, and then Launch Attack Analytics.

Imperva FlexProtect Pro for Application Security

Easily subscribe to Imperva Cloud Application Security using your AWS account.
The subscription includes:
• Cloud WAF protection for up to 10 sites. An always-on service that mitigates attacks targeting your websites
and web applications.
• Content Delivery Network (CDN). Improve your website performance while lowering bandwidth costs.
• SIEM integration. Integrate Imperva logs with your SIEM solution.
• Attack Analytics. Simplify your application security event investigations to quickly mitigate and respond to real
threats.
Subscribe
The Imperva FlexProtect Pro service is available through the AWS Marketplace.
Imperva Cloud Security Console
Once you subscribe to the Imperva FlexProtect Pro service, you can log in to your Imperva account.
The Cloud Security Console enables you to:
• gain visibility into attacks on your websites and web applications, with live views of incoming traffic, security
events, and server activity.
• manage your account and WAF settings. Define general site attributes and options related to security, web
scraping protection, performance, and availability of your website.
• create up to 4 additional account users for your team members, to enable collaboration and co-management of
the Imperva service.
Billing and usage
You can view your billing and usage details in the AWS Management Console.
Billing is based on pure volume of usage in a calendar month, rounded up to the nearest gigabyte.
At the end of each month, billing is calculated and the usage count is reset to 0.
Billing works on a 5 tier pricing model:
0 -1 GB Rate A The cost of any usage up to 1 GB.

1 -10 GB Rate B The cost of the next 9 GB used.
10 -100 GB Rate C The cost of the next 90 GB used.
100 - 500 GB Rate D The cost of the next 400 GB used.
The cost of the usage above 500
> 500 GB Rate E
GB.
For example:
For total usage in a month of 94.3 GB, usage is rounded up to the nearest GB (95) and calculated as follows:

1 GB at Rate A
9 GB at Rate B
85 GB at Rate C
Total = (1 X A) + (9 X B) + (85 X C)
Additional examples
If your total usage this month is this: The charge is this:

300 MB Rate A X 1 (Rounded up to 1GB)
Rate A X 1 (for the first GB) + Rate B X 1 (for the next
1.5 GB
500 MB, rounded up to 1 GB)
Rate A X 1 (for the first GB) + Rate B X 9 (for the next 9
15 GB
GB) + Rate C X 5 (for the last 5 GB)
FAQ
If I subscribed to this plan via AWS, can I add features by contacting the Imperva sales team?
No. Billing is done only via AWS. No features can be added at this point, but this may change moving forward.
I want to add DDoS protection, how do I do that?
There is no way to do that using this plan. You need to unsubscribe via AWS and contact Imperva sales to purchase a
new plan.
I subscribed in AWS, but never completed the Imperva registration process. Will I be charged?
If you did not complete the process of creating your account and configuring your sites to work with Imperva, you will
not be charged. Billing is calculated based on bandwidth usage for traffic to your sites.
Once I unsubscribe, how long will it take to complete the process?
We will terminate your account and send the final data usage to AWS within one hour.
Can I resubscribe?
Yes. If you decide to resubscribe within 30 days of the time you unsubscribed, we will enable your old account and you
will be able to login as usual. All the settings of your account will be saved.
If you resubscribe after 30 days, your old account will have already been removed, and you will need to go through the
full process of setting up your account.

Cloud Application and Network Security 10-12-2022

Uploaded by

Copyright:

Available Formats

You might also like

Cloud Application and Network Security 10-12-2022

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cloud Application and Network Security 10-12-2022

Uploaded by

Copyright:

Available Formats

Cloud Application and Network Security