Events

The Events page is the workspace for investigating HTTP requests and security events processed by WAAP. Use it to move from high-level attack patterns to individual requests, sessions, and security signals. Request history is retained for 30 days.

1. 1

   Open the Customer Portal

   Sign in to the CDB Technical Web Portal.

2. 2

   Open Events

   Navigate to WAAP > Analytics > Events.

Event filtering

Raw request logs are too large to review by hand. Combine filters to isolate the traffic for an investigation — for example POST requests to /login from a specific country that were blocked during a five-minute window. Applied filters also update the Events charts: request volume over time, the mix of decisions (Blocked, Monitored, Allowed, Passed) and optional actions (CAPTCHA, JS Challenge), and the split between suspicious and legitimate traffic.

By default, the toolbar shows:

• Time range — isolate the exact period when suspicious activity occurred.
• Domain — focus the investigation on traffic targeting all domains, or a specific domain.
• Event — focus on a security signal or detection, including DDoS. Type a rule name and add it, for example SQL Injection or DDoS.
• Actions — combine the mitigation decision and any extra challenge in one filter. Each dropdown has an Include / Exclude switch. Values are Blocked, Monitored, Allowed, Passed, Captcha, and JS Challenge. For example, Include + Blocked + Captcha returns requests blocked after a failed Captcha.

Open Add filter to add more dimensions. Every added dropdown also has Include / Exclude.

• Countries — analyze traffic based on geographic origin.
• IP address — investigate activity from a specific client.
• Response Codes — correlate security events with application behavior.
• HTTP Methods — distinguish between request types such as GET, POST, PUT, PATCH, or DELETE.
• Path — focus on a particular application endpoint or API route. Accepts a URL path or a glob-like pattern, for example /api/v1/* matches all endpoints under that prefix.
• Request ID — inspect one or more specific requests. Multiple request IDs can be provided as a comma-separated list.
• Reference IDs — group repeated requests that triggered the same security rule. Multiple reference IDs can be provided as a comma-separated list.
• Session IDs — analyze sequences of requests generated within one client session. Multiple session IDs can be provided as a comma-separated list.
• Organizations — filter by the WHOIS organization on the client IP. Values are those seen in the selected time range.
• ASN — filter by the autonomous system number of the client IP.
• Devices and Clients — filter by the parsed user-agent device and client family. Values are those seen in the selected time range.
• Tags — filter by tags WAAP assigned to the request, for example Injection Attack.
• User-Agent — case-insensitive partial match on the user-agent string.
• JA3 — filter by the JA3 TLS fingerprint of the originating client. Useful for identifying botnets that share a common network stack regardless of IP address.
• JA4 — filter by the JA4 TLS fingerprint of the originating client. JA4 normalizes handshake fields that browsers may reorder between sessions, producing more stable fingerprints for modern TLS clients.

Security analysts, SREs, and DevSecOps engineers use Events to investigate suspicious traffic, validate enforcement actions, detect recurring attack patterns, confirm whether rules behave as expected, and export evidence for incident response.

Inspecting an individual event

Click an event in the list to expand the row and reveal fields that are not shown as table columns. Those fields explain why a request was flagged and where it originated.

Key fields in the expanded view include:

• Organization — the name of the organization that owns the client IP address, sourced from WHOIS data. This helps analysts attribute traffic to a hosting provider, cloud platform, ISP, or corporate network, which is often a strong signal when distinguishing legitimate users from automated or malicious infrastructure.
• Tags — threat category labels assigned by WAAP, such as Injection Attack or SQL Injection. Tags reflect the high-level threat classification detected for the request, giving analysts an immediate understanding of the type of threat behind a security event without inspecting the raw payload.
• Detector and Payload — shown together in the portal only when a WAF and OWASP Top Threats signature matched (for example SQL injection or XSS) and the first detector has a non-empty matched_content. If there is no matched fragment, the section is not shown. They stay hidden for bot, IP reputation, CSRF, custom-rule, and DDoS events. Detector shows the signature ID and the request part that matched, for example ID862 in query_params. Payload shows the matched fragment (matched_content): URL-encoded and limited to 200 characters. The portal shows the first detector; the API returns the full detector list. The top-level rule name on the event is the policy that made the decision; detector lists the signatures inside that policy.
• JA3 and JA4 — TLS fingerprints computed from the client's TLS handshake. Both values appear as dedicated fields in the event details panel for HTTPS requests. Use them to identify clients by network stack rather than IP address, or to pivot from an event directly into a fingerprint-based filter.

Organization indicates who the request came from. Tags classify the threat. Detector and Payload show which signature matched and on which fragment. JA3/JA4 fingerprints identify the client network stack.

Exporting events

WAAP provides two export paths: a CSV download of the events currently loaded in the table, and continuous delivery of CDN request logs that include WAAP fields.

Export from the Events page

The Events page downloads the events currently loaded in the table as a CSV file. That file is not the full filtered result set. For a complete extract, use the Get security events endpoint and page through results with the next cursor.

1. 1

   Apply the investigation filters

   Set the time range and any other filters first. The CSV contains the events currently loaded in the table after those filters are applied.

2. 2

   Download the CSV

   Click the download icon in the toolbar. The control is labeled Export CSV. The browser downloads a CSV file.

   

Continuous export via Logs Uploader

For automated pipelines and long-term retention, configure Logs Uploader. When WAAP is enabled on a CDN resource, WAAP fields are appended to each CDN request-log entry. Logs Uploader does not deliver a separate WAAP event stream.

Real-world investigation scenarios

Investigating an API attack

A backend team notices abnormal behavior on /api/login. A security analyst opens Events and filters traffic by time range, path, and HTTP method.

The filtered dataset reveals a burst of POST requests from a limited set of IP addresses, triggering authentication-related rules. The analyst confirms that WAAP blocked the majority of these requests and identifies the activity as credential-stuffing automation.

Distinguishing legitimate automation from malicious bots

Some services rely on legitimate automated traffic from partners or internal integrations. However, malicious bots may produce similar patterns.

By filtering events by country, session ID, and decision, analysts can distinguish legitimate automation from abusive scripts attempting to scrape content or overload endpoints.

Validating a new security rule

After deploying a new custom rule, a DevSecOps engineer reviews Events to confirm that the rule correctly identifies malicious requests without affecting legitimate traffic.

The analyst filters by time range and decision to review blocked versus allowed requests and confirm that the policy change behaves as intended.

Investigating repeated attacker behavior

Automated attacks often generate sequences of requests rather than isolated events.

By pivoting from an IP address to a session ID or reference ID, analysts can observe the full sequence of requests generated by a single automated workflow. This helps determine whether the attacker is scanning, probing authentication flows, or attempting exploitation.

Exporting evidence for incident response

Once relevant traffic is isolated, analysts can download the events loaded in the table as a CSV file, or use the API with pagination for a complete extract.

This allows teams to:

• attach traffic samples to incident reports.
• share evidence with SOC teams.
• provide technical context to engineering teams.
• document mitigation effectiveness.

Recommended investigation workflow

Work through Events in this order:

1. 1

   Narrow the timeframe of the incident
2. 2

   Identify the affected endpoint or domain
3. 3

   Review mitigation decisions taken by WAAP
4. 4

   Pivot to source indicators such as IP address or session ID
5. 5

   Export relevant events for documentation or response

Query security events and retrieve individual event details using the Analytics endpoints. The current Python and Go SDKs do not include a method for GET /docs/waap/v2/analytics/events, so the examples use HTTP. Response examples include only the fields used in each step.

ℹ️

An API token is required. To retrieve details for a specific event, the domain ID is also needed — use List Domains (GET /docs/waap/v2/domains) to list available domains and their IDs.

Set the API token before running the examples:

export GCORE_API_KEY="{YOUR_API_KEY}"

List events

The Get security events endpoint (GET /docs/waap/v2/analytics/events) returns security events across all domains in the account. Each record includes the client IP address, triggered rule, decision, and request metadata. Results older than 30 days are not available. Pages use cursor pagination: pass the next value from a response as the next query parameter to fetch the following page.

START=$(date -u -d '24 hours ago' '+%Y-%m-%dT%H:%M:%SZ' 2>/dev/null || \
        date -u -v-24H '+%Y-%m-%dT%H:%M:%SZ')

curl -X GET "https://api.cdb-staging.cdn.orange.com/waap/v2/analytics/events?start=${START}&decision=blocked&limit=50" \
  -H "Authorization: APIKey $GCORE_API_KEY"

Response:

{
  "results": [
    {
      "id": "96763b8fb655e9f18a2e04097b704e39-458959",
      "decision": "blocked",
      "optional_action": "",
      "action": "block",
      "client_ip": "203.0.113.45",
      "country": "US",
      "domain": "example.com",
      "domain_id": 12345,
      "method": "POST",
      "path": "/api/login",
      "rule_name": "SQL Injection",
      "status_code": 403,
      "result": "blocked",
      "request_time": 1790505000000
    }
  ],
  "next": "eyJyZXF1ZXN0X3RpbWUiOjE3OTA1MDUwMDAwMDB9"
}

The table lists commonly used query parameters. It is not the complete API. Parameters discussed on the Events page, including ja3 and ja4, are included. For the full set — including tags, user_agent, has_policy_override, order_by, and every exclude_* filter — see Get security events.

Parameter	Required	Description
start	Yes	Start of the time range in ISO 8601 format.
end	No	End of the time range. Defaults to the current time when omitted.
next	No	Cursor from a previous response. Repeat the original filters and attach next to fetch the following page.
limit	No	Number of items to return. Maximum 100. Defaults to 100.
domains	No	Filter by domain IDs. Omit to query all domains.
decision	No	One or more of: blocked, monitored, allowed, passed.
optional_action	No	One or more of: captcha, challenge. The value challenge corresponds to JS Challenge in the Customer Portal.
ips	No	One or more client IP addresses.
countries	No	Country codes in ISO 3166-1 alpha-2 format.
path	No	One or more URL paths. * is a wildcard.
http_methods	No	One or more HTTP methods: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE.
status_codes	No	One or more HTTP response status codes.
request_ids	No	One or more request IDs.
reference_ids	No	One or more reference IDs.
session_ids	No	One or more session IDs.
ja3	No	One or more JA3 TLS fingerprints. Each value is 32 hexadecimal characters.
ja4	No	One or more JA4 TLS fingerprints, for example t13d3113h2_e8f1e7e78f70_ce5650b735ce.
user_agent_clients	No	Parsed user-agent client families. Values come from GET /docs/waap/v1/analytics/filters/user-agent-clients for the selected period.
user_agent_devices	No	Parsed user-agent device types. Values come from GET /docs/waap/v1/analytics/filters/user-agent-devices for the selected period.
organizations	No	WHOIS organizations on client IPs. Values come from GET /docs/waap/v1/analytics/filters/organizations for the selected period.
exclude_decision	No	Exclude one or more decisions. Additional exclude_* filters are listed in the API reference.

Event details

Retrieve the full set of attributes for a specific event, including request headers, user agent details, session context, the incident ID from any challenge that was issued, the threat category tags that explain why the request was flagged, and the detector array for WAF and OWASP signature matches.

The request_id value comes from the id field in the events list response. The domain_id is also present in each list result.

curl -X GET "https://api.cdb-staging.cdn.orange.com/waap/v1/domains/{DOMAIN_ID}/requests/{REQUEST_ID}/details" \
  -H "Authorization: APIKey $GCORE_API_KEY"

The API returns:

{
  "id": "96763b8fb655e9f18a2e04097b704e39-458959",
  "path": "/api/login",
  "method": "POST",
  "action": "block",
  "decision": "blocked",
  "optional_action": "",
  "rule_id": "86",
  "rule_name": "SQL Injection",
  "pattern_matched_tags": [
    {
      "tag": "sql",
      "display_name": "SQL Injection",
      "description": "This client attempted insertion or injection of a SQL query via the input data from the client to the application.",
      "field": "query_params",
      "field_name": "q",
      "pattern_name": "SQL Injection Prevention",
      "pattern_value": "select user from master.."
    }
  ],
  "common_tags": [
    {
      "tag": "injectionattack",
      "display_name": "Injection Attack",
      "description": "Multiple injection attempts were detected."
    }
  ],
  "traffic_types": ["policy_blocked"],
  "user_agent": {
    "full_string": "python-requests/2.31.0",
    "device": "Other",
    "client": "Python Requests"
  },
  "network": {
    "client_ip": "203.0.113.45",
    "country": "US",
    "organization": {
      "name": "Example Hosting LLC",
      "subnet": "203.0.113.0-203.0.113.255"
    }
  },
  "request_time": "2026-09-27T10:30:00",
  "reference_id": "ad07c06f19054e484974fa22e9fb6bb1",
  "session_id": "0c74d14951b22dc3f22cbba9668ecea1",
  "query_string": "q=select%20user%20from%20master..",
  "http_status_code": 403,
  "http_version": "1.1",
  "scheme": "https",
  "content_type": "application/json",
  "response_time": "12",
  "incident_id": "",
  "request_headers": {
    "HOST": "example.com",
    "CONTENT-TYPE": "application/json"
  },
  "detector": [
    {
      "rule_id": "ID862",
      "rule_name": "SQL Injection Prevention",
      "subject_type": "query_params",
      "subject_field": "q",
      "matched_content": "select%20user%20from%20master.."
    }
  ]
}

Top-level rule_name is the policy that made the decision. detector lists the signatures inside that policy. The array is populated only for WAF and OWASP Top Threats signature events; otherwise it is empty. matched_content is the matched fragment, URL-encoded and limited to 200 characters.