Skip to main content

Threat Detection

Pro Feature

Threat detection and automatic blocking are available with the Pro license. Get your Pro license to access this feature.

Sentinel detects and blocks malicious requests automatically using signature-based pattern matching.

How it works​

  1. Request Analysis: Every HTTP request is analyzed before reaching PrestaShop — query string, raw body, form fields (including multipart/form-data submissions) and uploaded file names. Percent-encoding is undone first, so encoding a character does not hide a payload. The security tokens that PrestaShop adds to its links and forms are not compared with the signatures when they have exactly the shape PrestaShop gives them, so that a random token no longer gets a page or a form refused by chance; any other value of these parameters is analyzed as usual, and the signatures that target them still apply.
  2. Pattern Matching: The request is compared against known threat signatures downloaded from the Sentinel API
  3. Instant Blocking: If a malicious pattern is detected, the request is blocked with HTTP 403, unless it comes from a trusted IP or goes to a URL never blocked (see What is never blocked)
  4. Logging: All detected attacks are logged with details (IP, URI, pattern matched)
Oversized or malformed requests

Pattern matching runs with a backtracking budget set by Sentinel, so behaviour does not depend on your host's PHP configuration. If a request is crafted so that the matching engine gives up before finishing — a known way of slipping a payload past signature-based filters — the request is treated as a threat and blocked, never as clean traffic. A signature that fails to compile is ignored instead, so a faulty pattern cannot block your visitors.

One exception: when the engine gives up on a request coming from the back office with a signed-in employee session, the request is not blocked. A very large back-office form can exhaust the budget of a greedy signature without carrying anything hostile, and blocking there would cost your team a page over a check that never reached a conclusion. The event is recorded in the security logs as Detection Skipped, with the signature involved and the reason the check could not be completed. A signature that actually matches blocks the request, employee session or not; from a trusted IP or to a URL never blocked, neither a match nor an aborted check blocks it.

Turning detection on or off​

Threat detection is set in the Real-time threat detection card of the Threat detection tab of Sentinel > Configuration. Turn the switch on or off, then click Apply: nothing changes until you click it.

Turning detection on also downloads the latest signatures. If they cannot be downloaded, detection is still turned on and the page shows Threat detection enabled, but the signatures could not be downloaded: followed by the reason.

The badge of the card gives the state of detection:

  • On: every request is compared with the signatures, and an attack is blocked, unless it comes from a trusted IP or goes to a URL never blocked (see What is never blocked).
  • Waiting for signatures: detection is turned on, but no signature has been downloaded yet, so nothing is blocked.
  • Off: detection is turned off, including on the PHP files reached directly (see Signature detection on direct accesses).

While the signatures have not been downloaded, the tab shows the Threat Detection Signatures Missing notice above the card, with a Download Signatures button. Detection stays inactive until they are downloaded.

On the free plan, the card shows the Pro invitation described under Threat detection instead of the switch and the badge.

Only an employee who can configure the Sentinel module changes these settings; the others see the tab read-only. See Who can change the settings.

Signature Updates​

Threat detection signatures are managed remotely on the Sentinel API and synchronized automatically:

  • At installation: Signatures are downloaded when the module is installed
  • Daily sync: The back-office automatically checks for updated signatures once every 24 hours
  • Manual download: If signatures are missing, the Threat detection tab of Sentinel > Configuration shows the Threat Detection Signatures Missing notice with a Download Signatures button

A shop whose plan no longer includes threat detection receives an empty signature set at the next synchronization: it then has nothing left to compare requests with.

A passing error keeps the signatures already in place until the next synchronization: the Sentinel service cannot be reached, answers too late, returns a server error, or refuses the licence key.

As long as the shop keeps threat detection, its signatures follow those of the Sentinel service without requiring a module update.

What is never blocked​

The addresses of the Trusted IPs card of the General tab of Sentinel > Configuration are never blocked by threat detection: in the front office, in the back office and on the PHP files reached directly (see Signature detection on direct accesses). It is the list that the brute-force and DDoS protections already trust, and CIDR ranges are supported.

An exemption lets every attack through

A request from a trusted IP, or to a URL never blocked, is not blocked, even when it carries an attack. Only trust addresses that you control, and check the points below.

  • Maintenance IPs: the maintenance IPs set in PrestaShop are trusted too, as long as the Also trust PrestaShop maintenance IPs switch of the card is on, and it is on from the installation of the module. Read them again, and turn the switch off if one of them is an address that you do not control. On the PHP files reached directly, a change of the maintenance IPs made in PrestaShop applies once you save the Trusted IPs card again.
  • Behind a proxy or a CDN: only the address forwarded by a proxy declared in the Behind a proxy or a CDN? card counts, never the legacy Trust X-Forwarded-For setting. Until the proxy is declared, Sentinel sees the address of the proxy instead of yours, and your trusted IP is not recognised. If the address of an undeclared proxy is among the trusted IPs or the maintenance IPs, every visitor who comes through that proxy is exempted.
  • Ranges that are too wide: a range such as 0.0.0.0/0 exempts every address it contains, attackers included, and Sentinel does not refuse it. Keep each range to the addresses that you control.
  • Logged, not blocked: a request from a trusted IP that matches a signature reaches its page as usual, and Security Logs records it as not blocked, with the signature that matched: under Detection Skipped for a request that goes through PrestaShop, and as Not blocked — trusted IP in the file logs tab for a PHP file reached directly.
  • Detection turned off: while the Real-time threat detection switch is off, nothing is compared, so nothing is blocked and no exemption is recorded: no Detection Skipped event, no Not blocked — trusted IP or Not blocked — trusted URL mark. The direct accesses that the Auto Prepend File protection records, and the POST, PUT, PATCH and DELETE requests, are still logged.

URLs never blocked​

The URLs never blocked card of the Threat detection tab of Sentinel > Configuration lists the URLs that threat detection never blocks, such as the address where a payment provider confirms an order. This list is not the Excluded URLs list of the DDoS protection: a URL excluded there is still checked by threat detection.

Write one path per line, starting with /, without the domain or the query string. Each entry is one of two things:

  • A module page: a path that starts with /module/, such as /module/ps_wirepayment/validation, is the validation page of the ps_wirepayment module, shown by PrestaShop. Sentinel compares the entry with the page that PrestaShop is about to run, not with the address requested: the page is covered with or without friendly URLs, with a language prefix and in a shop installed in a subfolder, while an address whose query string leads to another page is not. Case does not matter. Only the front pages of an enabled module are covered, never the back office nor the pages of PrestaShop itself.
  • A PHP file called directly: any other path, such as /modules/mymodule/ipn.php, is a file reached without going through PrestaShop (see Signature detection on direct accesses). Write it from the root of the shop, without the folder of a shop installed in a subfolder. Only a request that reaches the listed file by its plain path is covered: nothing after the file name, no empty, . or .. segment, nothing still encoded once decoded, and the same case as the entry.

A * stands for one whole segment made only of unaccented letters, digits, _, . or -, never a /, and is refused as the first or the last segment: /modules/*/ipn.php covers /modules/mymodule/ipn.php, not /modules/mymodule/sub/ipn.php nor /modules/my+module/ipn.php.

Save refuses the whole list, saves nothing and keeps what you typed in the field when an entry does not start with /, holds .., ?, #, %, \, a space, an empty segment such as in //, a . segment, a trailing / or a * that is not a whole segment, or is longer than 255 characters. The page then names the first refused entry: %entry% is not a valid URL path. Start it with /, leave out the query string, and use * only for a whole segment that is neither the first nor the last. Nothing was saved: correct it and save again., where %entry% is that entry. A list of more than 50 URLs is refused the same way, with At most 50 URLs can be listed. Nothing was saved: shorten the list and save again. Otherwise, empty lines and repeated entries are dropped, and the page shows URLs never blocked have been saved.

  • Only what needs it: an attack sent to a listed URL goes through, as the warning above says. List only the payment or webhook URLs that threat detection blocks by mistake, and use * sparingly.
  • Logged, not blocked: a request to a listed URL that matches a signature reaches its page as usual, and Security Logs records it as not blocked, with the signature that matched: under Detection Skipped for a module page, and as Not blocked — trusted URL in the file logs tab for a PHP file called directly. A request from a trusted IP is recorded as coming from a trusted IP, even to a listed URL.

Protected Threats​

SQL Injection​

Detects attempts to manipulate your database:

Example: /index.php?id=1' AND SELECT SLEEP(5)--

Sentinel blocks patterns like:

  • SELECT ... SLEEP ...
  • UNION SELECT ...
  • SQL keywords in suspicious contexts

File Operations​

Detects attempts to write malicious files:

Example: file_put_contents('shell.php', '<?php ...')

Blocks attempts to:

  • Write files with file_put_contents
  • Download remote code with wget
  • Modify PHP configuration with ini_set

Command Execution​

Prevents execution of system commands:

Example: system('rm -rf /')

Module Exploits​

Detects known vulnerabilities in popular PrestaShop modules:

  • Product Search module
  • Blog modules (CSBlog, SmartBlog, etc.)
  • Payment modules

Suspicious HTTP Headers​

Detects malicious or suspicious HTTP headers:

  • Security scanners: Blocks requests from known scanning tools (sqlmap, nikto, nmap, dirbuster, etc.)
  • Empty User-Agent: Blocks requests with no User-Agent header (common in automated attacks)
  • Log4Shell: Detects JNDI injection attempts in HTTP headers

When an attack is detected​

  1. Request is blocked with HTTP 403 Forbidden
  2. Custom page is displayed to the attacker
  3. Attack is logged in /var/logs/sentinel-YYYY-MM-DD.log
  4. Context is recorded: IP address, URI, matched pattern, request data

From a trusted IP or to a URL never blocked, the request is not blocked: it reaches its page as usual, without the blocking page, and the attack is only logged, as not blocked.

Example of blocked request​

When someone tries:

https://yourstore.com/index.php?search=SELECT SLEEP(10)

They see:

HTTP 403 Forbidden
Access Denied
Your request has been blocked for security reasons.

And Sentinel logs:

{
  "ip": "192.168.1.100",
  "uri": "/index.php?search=SELECT SLEEP(10)",
  "pattern": "(.*)select(.*)sleep(.*)",
  "method": "GET"
}

Next: Security Logs