The Firewall monitors all incoming requests to your website and blocks anything that looks suspicious or dangerous.
When WAF blocks a request, you can see the details in Firewall → Attack Logs.
This section explains all key terms and abbreviations that appear in these reports.
IP (Internet Protocol address): the unique numeric address of the device that sent the request.
If multiple attacks originate from the same IP address, it’s usually an automated bot.
Tip: Avoid manually blocking single IPs unless you’re sure. Firewall already handles it automatically.
Country: the country from which the request was sent, based on the IP address.
Attackers often use VPNs or proxy servers, so the shown country may not be accurate.
Source — where our security module found the suspicious fragment in the request.
A User-Agent is a short line of text sent by a browser or program when it connects to a website.
It identifies the client — for example, “Mozilla/5.0 (Windows NT 10.0; Chrome/124.0)”.
Attackers often fake (or “spoof”) User-Agent strings to disguise scripts and bots as normal browsers.
While the User-Agent itself is harmless, fake ones help hide automated attacks and make traffic appear legitimate.
WebTotem Firewall can detect unusual or known malicious User-Agents (like “sqlmap” or “curl”) and block them automatically.
A URI is the path or address of the resource that was requested on your website.
Example: /api/login or /news?id=123.
Attackers use URIs to probe for weak points in your site — they try different paths (admin panels, old plugins, backup files) or add suspicious parameters (?cmd=ls, ?file=../../etc/passwd).
Monitoring suspicious URIs helps you understand which parts of your site are being targeted.
GET is one of the main HTTP request methods. It is used to retrieve data from the server — for example, when a visitor opens a web page.
In attacks, GET requests are often used with specially crafted parameters in the URL to test for vulnerabilities, such as SQL Injection or XSS.
Example: /index.php?id=1' OR '1'='1.
A well-configured WAF analyzes the content of GET requests and blocks those containing harmful code patterns.
POST is another common HTTP request method, used to send data to the server — for example, submitting a login form or uploading a file.
Attackers use POST requests to send hidden payloads to your server, such as malicious code or commands.
Because POST can carry large amounts of data, it is often used in attempts to upload infected files or inject SQL queries.
WAF scans POST data for dangerous content and prevents such attacks from reaching your site.
Cookies are small text files that websites save in a user’s browser. They store information like session IDs or preferences.
Every time a browser connects to a site, it sends cookies back to the server.
Attackers can steal, forge, or manipulate cookies to take over user sessions (“session hijacking”).
For example, if a cookie contains login data without encryption, a hacker could reuse it to impersonate another user.
WebTotem Firewall checks cookie behavior and flags suspicious cookie values or anomalies.
Headers are additional pieces of information sent with every HTTP request and response.
They describe things like data type (Content-Type), accepted language (Accept-Language), or origin (Referer).
Attackers sometimes modify or inject fake headers to bypass filters, smuggle commands, or trick caching systems.
For example, a fake “Host” or “X-Forwarded-For” header can be used to disguise the real source of an attack.
A WAF validates headers and blocks malformed or dangerous ones before they reach your site.
The body is the main content of a request. It’s used to send data from the client to the server — such as form inputs, JSON objects, or uploaded files.
In most modern attacks, the body is where the malicious code hides.
Examples include:
SQL Injection payloads.
JavaScript is used in XSS attacks.
Uploaded webshells disguised as images or documents.
The WAF inspects payloads for patterns and signatures of known exploits, limits file types and sizes, and blocks unsafe content automatically.
Developers should always validate and sanitize all data received in the request body.
Each of these components (UA, URI, GET, POST, COOKIE, HEADERS, BODY) represents a possible entry point for an attacker.
Even a small vulnerability in one of them can allow unauthorized access, data leakage, or full site compromise.
WebTotem Firewall continuously monitors and analyzes all these parts of every request to protect your site before an attack succeeds.
| № | Source | Transcript | Description |
| 1 | UA | User-agent | |
| 2 | URI | Uniform Resource Identifier | |
| 3 | GET | To retrieve data from the server | |
| 4 | POST | To send data to the server | |
| 5 | COOKIE | Site stores data on your device | Through your browser |
| 6 | HEADERS | Additional information | In the request or in the response |
| 7 | BODY | Data of request or response |
What the system did with the request:
Blocked by WAF – the attack was stopped before reaching your website.
Allowed – the request was safe and passed through.
Logged only – the request was recorded for analysis but not blocked.
“SQLi” - SQL Injection
What it means: an attempt to inject malicious SQL commands into a database query (for example through form fields or URL parameters).
Why it’s dangerous: attackers can read, modify or delete data, steal user credentials, or take control of your database.
What to do: treat as high severity — check the affected endpoint, ensure server-side input validation and parameterized queries.
“Injection”
What it means: a general category for attacks that inject unexpected data (commands or code) into an application’s inputs. This covers other types (template injection, XML injection, etc.).
Why it’s dangerous: can lead to data leakage, remote code execution, or application logic bypass.
What to do: validate and sanitize inputs, use safe APIs/libraries, and review the exact payload in the log to determine which subtype of injection was attempted.
“LFI” - Local File Inclusion
What it means: an attempt to make the application load or reveal files from the server’s filesystem.
Why it’s dangerous: attackers can read sensitive files, credentials, or configuration and may escalate to remote code execution.
What to do: ensure the app only loads whitelisted files, remove direct filesystem access based on user input, and fix the vulnerable code.
“RFI” - Remote File Inclusion
What it means: an attempt to make the server fetch and execute a file from a remote (attacker-controlled) location.
Why it’s dangerous: attacker-controlled code can be executed on your server (full compromise).
What to do: block external file includes, enforce allowlists, disable risky PHP features (or equivalent), and treat alerts as critical.
“Evasion”
What it means: attempts to bypass the firewall’s detection using tricks such as encoding, broken-up payloads, odd whitespace, comment insertion, or HTTP smuggling techniques.
Why it’s dangerous: attackers may hide real payloads to slip past simple filters. Repeated evasion attempts often precede successful attacks.
What to do: consider stricter rate-limiting.
“XSS” - Cross-Site Scripting
What it means: injection of malicious JavaScript (or HTML) into pages viewed by other users.
Why it’s dangerous: attackers can hijack sessions, steal cookies, perform actions on behalf of users, or display fake content.
What to do: escape output properly, validate input, use Content Security Policy (CSP).
“RCE” - Remote Code Execution
What it means: an attempt to execute arbitrary code or commands on the server.
Why it’s dangerous: one of the highest-risk categories — can lead to full server takeover.
What to do: treat as critical, block immediately, investigate server integrity and logs, patch the vulnerable code or component.
“Other”
What it means: attacks that don’t fit the main categories, or generic suspicious behavior (weird parameters, malformed requests, protocol abuse).
Why it’s dangerous: may indicate new or custom attack vectors.
What to do: review the payload and context — if repeated or paired with other suspicious signs.
“UWA” — Unusual Web Activity
What it means: suspicious or anomalous web behavior that doesn’t match a specific exploit signature — e.g., abnormal request patterns, strange parameter use, or unexpected traffic spikes.
Why it’s dangerous: often indicates scanning, reconnaissance, or early-stage attacks trying many approaches.
What to do: monitor and rate-limit; if activity persists, block or throttle the source and investigate for signs of automated scanning or brute-force attacks.
“Scanner”
What it means: automated tools that scan for known vulnerabilities (fingerprinting, path discovery, plugin/version probes). The signature detects scanner behavior rather than one specific exploit.
Why it’s dangerous: scanners are used to find weak points; a successful scan often leads to focused exploitation.
What to do: block or rate-limit scanners, check whether scans targeted sensitive endpoints, and harden any discovered endpoints.
“OSCI” — OS Command Injection (commonly used abbreviation)
What it means: attempts to inject system commands that the server will execute (often via poorly sanitized inputs passed to shell functions).
Why it’s dangerous: allows attackers to run arbitrary operating system commands — can fully compromise the host.
What to do: treat as critical; block source, audit for compromise, remove any vulnerable code that executes shell commands using user input.
An HTTP request is what the browser (or bot) sends to your website.
Each request uses a method, such as:
GET – retrieves data (for example, loading a page).
POST – sends data to the server (for example, submitting a form).
PUT / DELETE / PATCH – used mainly by APIs or admin tools.
Attackers often use unusual or malformed requests, such as /index.php?cmd=ls, to test your site for vulnerabilities.