Log File Structure
- Last UpdatedApr 20, 2025
- 7 minute read
This topic explains the Imperva log file structure and provides compatibility information.
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:
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
Events include header fields and event fields.
Event header fields
Each event includes the header fields listed in the table below.
For example: CEF:0|Incapsula|SIEMintegration|1|1|Illegal Resource Access|3|
Note: These event headers apply only to CEF and LEEF log file formats. The W3C format does not include event header fields. The relevant details are included in the log file header fields or main event fields.
Event 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.
For each request that has attack information the following is provided:
For each request that has delivery rule 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": "" } |