Book IndexHideShow
Back to topic

Cloud Application Security

Log File Structure

Log File Structure

This topic explains the Imperva log file structure and provides compatibility information.

In this topic:


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:

startTime The start time of the current log file, in UNIX epoch time format.
endTime The end time of the current log file, in UNIX epoch time format.
accountID Your Account ID.
Format The format of the events in the log file: CEF , LEEF or W3C (Example Logs).
Checksum An MD5 checksum that verifies that the entire file content has not been tampered with.
publicKeyId Public Key ID.
key The log content decryption key.
configID The configuration ID. Each account has a configuration ID.
W3C fields For W3C format, it is required to present the list of 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.

Description CEF LEEF W3C Detailed Description
ID fileId fileId cs-sessionid The unique identification.
Client IP src src c-ip The client IP that made the request.
User Agent requestClientApplication requestClientApplication cs(User-Agent) The UserAgent header value.
Request Start Time start start cs-start The time in which this visit started, in UTC. In UNIX epoch time format.
Response End Time end end cs-end The end time of the response to the request, in UTC. In UNIX epoch time format.
Request Headers additionalReqHeaders additionalReqHeaders cs-additionalReqHeaders Request headers in JSON format, with each field represented as a name-value pair.
Response Headers additionalResHeaders additionalResHeaders cs-additionalResHeaders

Response headers in JSON format, with each field represented as a name-value pair.

Note: Use of these fields for CEF and LEEF formats require enablement by Imperva Support.

URL request url cs-uri The URL of the request.
Ref ID tag tag s-tag Ref ID.
Country Code ccode calCountryOrRegion cs-countrycode The country code of the site visitor.
City cicode cicode cs-cicode The city code of the site visitor.
Protocol app proto cs-version The request protocol
Request ID deviceExternalId deviceExternalId s-externalid A unique identifier of the request that can be used to correlate with reports and data from the Imperva Cloud Security Console
Referrer ref ref cs(Referrer) The URL of the previous page that the client visited
Method requestMethod requestMethod cs-method The request method.
HTTP Status Code cn1 cn1 sc-status The HTTP response code returned to the client.
X-Forwarded-For xff xff s-xff

The X-Forwarded-For request header.

This log field is populated only if the request received from the client contained the XFF header, and/or the request received from the client was passed to the origin.

Content Length in in cs-bytes The content length.
Account ID suid suid s-suid The numeric identifier of the account of the site owner.
Account Name Customer Customer s-accountname The account name of the site owner.
Site ID siteid siteid s-siteid The numeric identifier of the site.
Site Name sourceServiceName sourceServiceName s-computername The name of the site.
Request Result act cat sc-action

The method in which Imperva processed the request:

  • REQ_PASSED: If the request was routed to 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 Codes.

Source Port cpt srcPort c-port The client port used to communicate the request.
Protocol version ver protoVer cs-provider The TLS version and encryption algorithms used in the request.
PoP name deviceFacility popName sr-pop The Imperva PoP that handled the request.

For each request that has attack information the following is provided:

Description CEF LEEF W3C Detailed Description
Post Body postbody postbody cs-postbody The post body data of the request.
Server IP sip dst s-ip The IP address of the server.
Server Port spt dstPort s-port The port of the server.
Query String qstr qstr cs-uri-query The query string of the request.
Captcha Support cs1 cs1 s-capsupport Whether or not the client application supports Captcha.
JS Support cs2 cs2 cs-js-support Whether or not the client application supports JavaScript.
Cookies Support cs3 cs3 cs-co-support Whether or not the client application supports cookies.
Visitor ID cs4 cs4 cs-vid The ID of the visitor.
Debug cs5 cs5 cs-clappsig For internal use.
Client App cs6 cs6 cs-clapp The client application software.
Latitude cs7 cs7 cs-lat The latitude of the event.
Longitude cs8 cs8 cs-long The longitude of the event.
Rule Name cs9 cs9 s-ruleName The threat rule name that this request triggered. For example, SQL Injection or Blocked IP (ACL).
Attack ID filePermission filePermission cs-attackid Imperva attack id.
Attack Type fileType fileType cs-attacktype The type of attack.
Browser Type dproc dproc cs-browsertype The browser type.
Attack Severity This information is presented in the header, not as a separate field. N/A cs-severity

The rule type that was triggered, and the corresponding Imperva internal rule ID number.

  • ACL: -1
  • SQL Injection: 0
  • 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
Additional Rule Info cs11 cs11 cs-ruleInfo

Additional information on the violation that triggered the rule, in JSON format.

Used for API Specification Violation events.

JSON structure:

{“api_specification_violation_type”:”<type>”,”parameter_name”:”<parameter name>”}

The possible values for api_specification_violation_type are:


The “parameter_name” is present only if the violation occurs in the context of a parameter. Its value is the relevant parameter name.

For each request that has delivery rules information the following is provided:

Description CEF LEEF W3C Detailed Description
Delivery Rule Details cs10 cs10 cs-rule JSON describing all actions that were applied to a specific request (detailed JSON structure below)

JSON structure for delivery actions:

Redirect { "rule_id": "<rule id>", "type": "AD_REDIRECT", "int_value": "<redirect code>", "name": "", "orig": "<original url>", "rewrite": "<redirect url>"}
URL Rewrite { "rule_id": "<rule id>", "type": "AD_URL_RW", "int_value": 0, "name": "", "orig": <original url>, "rewrite": <new url> }
Header Rewrite { "rule_id": "<rule id>", "type": "AD_HEADER_RW", "int_value": 0, "name": <header name>", "orig": <original value>", "rewrite": <new value>" }
Add Header { "rule_id": "<rule id>", "type": "AD_HEADER_RW", "int_value": 0, "name": <header name>", "orig": "", "rewrite": <new value>" }
Remove Header { "rule_id": "<rule id>", "type": "AD_HEADER_RW", "int_value": 0, "name": <header name>", "orig": "", "rewrite": "" }
Cookie Rewrite { "rule_id": "<rule id>", "type": "AD_COOKIE_RW", "int_value": 0, "name": <cookie name>", "orig": <original value>", "rewrite": <new value>" }
Add Cookie { "rule_id": "<rule id>", "type": "AD_COOKIE_RW", "int_value": 0, "name": <cookie name>", "orig": "", "rewrite": <cookie value>" }
Remove Cookie { "rule_id": "<rule id>", "type": "AD_COOKIE_RW", "int_value": 0, "name": <cookie name>", "orig": "", "rewrite": "" }
Forward to DC { "rule_id": "<rule id>", "type": "AD_FORWARD_TO_DC", "int_value": <dc id>, "name": "", "orig": "", "rewrite": "" }

Read More

Join the Discussion