Exhaustive report on security protocols and development standards for PrestaShop modules
1. Introduction: the cybersecurity landscape in e-commerce
E-commerce platforms handle high-value data (credentials, payments, customer records) and are prime targets. In PrestaShop, the attack surface depends heavily on module quality: a single vulnerable connector can compromise the whole shop. This report provides a complete security reference for building PrestaShop modules (1.7 and 8), based on official documentation, Marketplace Addons requirements, and community audits (including Friends of Presta). Goal: deliver resilient code against SQL injection, XSS, CSRF, path traversal, and structural flaws.
2. Architecture and structural integrity: first line of defense
2.1 Execution context protection and isolation
Every PHP file must run only through the core dispatcher. Add this guard at the top of every PHP file (classes, helpers, install scripts, PHP views) to block direct access:
<span class="cp"><?php</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="nb">defined</span><span class="p">(</span><span class="s1">'_PS_VERSION_'</span><span class="p">))</span> <span class="p">{</span>
<span class="k">exit</span><span class="p">;</span>
<span class="p">}</span>
If _PS_VERSION_ is not defined, the call did not come from PrestaShop; execution stops before any leak or partial run.
2.2 Directory listing prevention
Place an index.php in every directory and subdirectory of the module to prevent file enumeration (including asset folders). Minimal example:
<span class="cp"><?php</span>
<span class="nb">header</span><span class="p">(</span><span class="s1">'Expires: Mon, 26 Jul 1997 05:00:00 GMT'</span><span class="p">);</span>
<span class="nb">header</span><span class="p">(</span><span class="s1">'Last-Modified: '</span><span class="mf">.</span><span class="nb">gmdate</span><span class="p">(</span><span class="s1">'D, d M Y H:i:s'</span><span class="p">)</span><span class="mf">.</span><span class="s1">' GMT'</span><span class="p">);</span>
<span class="nb">header</span><span class="p">(</span><span class="s1">'Cache-Control: no-store, no-cache, must-revalidate'</span><span class="p">);</span>
<span class="nb">header</span><span class="p">(</span><span class="s1">'Cache-Control: post-check=0, pre-check=0'</span><span class="p">,</span> <span class="kc">false</span><span class="p">);</span>
<span class="nb">header</span><span class="p">(</span><span class="s1">'Pragma: no-cache'</span><span class="p">);</span>
<span class="nb">header</span><span class="p">(</span><span class="s1">'Location: ../'</span><span class="p">);</span>
<span class="k">exit</span><span class="p">;</span>
For Apache, add a .htaccess at the module root to deny direct access to templates and config files.
2.3 Dependency hygiene and the PHPUnit case
Third-party libraries can introduce supply chain risks (e.g., accidentally shipping PHPUnit with the vulnerable eval-stdin.php). Good practices:
- Exclude from the production ZIP any test folders (
tests/,spec/), test configs (phpunit.xml), andrequire-devdependencies. - Install in production via
composer install --no-dev --optimize-autoloader. - Keep libraries updated to integrate security fixes.
2.4 Compatibility declaration and lifecycle
Declare compatibility explicitly via ps_versions_compliancy and avoid open-ended bounds:
<span class="nv">$this</span><span class="o">-></span><span class="n">ps_versions_compliancy</span> <span class="o">=</span> <span class="p">[</span><span class="s1">'min'</span> <span class="o">=></span> <span class="s1">'1.7.0.0'</span><span class="p">,</span> <span class="s1">'max'</span> <span class="o">=></span> <span class="s1">'8.99.99'</span><span class="p">];</span>
This protects merchants by blocking installs on unsupported versions.
3. Data validation and sanitization: theory and practice
3.1 Input abstraction with Tools::getValue()
Direct access to $_GET and $_POST is discouraged. Use Tools::getValue($key, $defaultValue) to centralize access, benefit from URL decoding, and avoid undefined indexes. It does not sanitize: follow with strict validation.
3.2 The Validate class: barrier against malformed data
Before any business logic or persistence, apply the right Validate methods:
- Numeric and boolean:
Validate::isInt(),Validate::isUnsignedInt(),Validate::isFloat(),Validate::isBool(). - Strings and HTML:
Validate::isGenericName()for labels,Validate::isCleanHtml()for rich content ($allow_iframeonly when strictly needed). - Specific:
Validate::isFileName()for uploads,Validate::isHookName()for dynamic hooks.
3.3 Path traversal prevention
For any file reference coming from user input, strip path sequences and confine access to the intended folder:
<span class="nv">$safeFilename</span> <span class="o">=</span> <span class="nb">basename</span><span class="p">(</span><span class="nc">Tools</span><span class="o">::</span><span class="nf">getValue</span><span class="p">(</span><span class="s1">'file'</span><span class="p">));</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="nc">Validate</span><span class="o">::</span><span class="nf">isFileName</span><span class="p">(</span><span class="nv">$safeFilename</span><span class="p">))</span> <span class="p">{</span>
<span class="k">die</span><span class="p">(</span><span class="s1">'Bad filename'</span><span class="p">);</span>
<span class="p">}</span>
<span class="nv">$targetDir</span> <span class="o">=</span> <span class="n">_PS_MODULE_DIR_</span><span class="mf">.</span><span class="s1">'mymodule/uploads/'</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="nb">file_exists</span><span class="p">(</span><span class="nv">$targetDir</span><span class="mf">.</span><span class="nv">$safeFilename</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Allowed processing</span>
<span class="p">}</span>
Using a whitelist of expected files further reduces exposure.
4. Database security: preventing SQL injection
4.1 The Db class and casting
All queries must go through Db (no direct PDO/mysqli). Escape by type:
- Integers: cast
(int)$id. - Strings:
pSQL($name). - SQL identifiers (table/column):
bqSQL($table). - Arrays:
array_map('intval', $ids)orarray_map('pSQL', $values)beforeimplode.
4.2 Securing IN clauses and lists
<span class="nv">$ids</span> <span class="o">=</span> <span class="nc">Tools</span><span class="o">::</span><span class="nf">getValue</span><span class="p">(</span><span class="s1">'ids'</span><span class="p">,</span> <span class="p">[]);</span>
<span class="nv">$safeList</span> <span class="o">=</span> <span class="nb">implode</span><span class="p">(</span><span class="s1">','</span><span class="p">,</span> <span class="nb">array_map</span><span class="p">(</span><span class="s1">'intval'</span><span class="p">,</span> <span class="p">(</span><span class="k">array</span><span class="p">)</span> <span class="nv">$ids</span><span class="p">));</span>
<span class="nv">$sql</span> <span class="o">=</span> <span class="s1">'SELECT * FROM '</span><span class="mf">.</span><span class="n">_DB_PREFIX_</span><span class="mf">.</span><span class="s2">"product WHERE id_product IN (</span><span class="nv">$safeList</span><span class="s2">)"</span><span class="p">;</span>
For string lists, wrap each pSQL value in single quotes.
4.3 Abstraction with DbQuery
Structure queries with DbQuery to reduce risky concatenations and ease audits:
<span class="nv">$query</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">DbQuery</span><span class="p">();</span>
<span class="nv">$query</span><span class="o">-></span><span class="nf">select</span><span class="p">(</span><span class="s1">'p.id_product, pl.name'</span><span class="p">);</span>
<span class="nv">$query</span><span class="o">-></span><span class="nf">from</span><span class="p">(</span><span class="s1">'product'</span><span class="p">,</span> <span class="s1">'p'</span><span class="p">);</span>
<span class="nv">$query</span><span class="o">-></span><span class="nf">leftJoin</span><span class="p">(</span><span class="s1">'product_lang'</span><span class="p">,</span> <span class="s1">'pl'</span><span class="p">,</span> <span class="s1">'p.id_product = pl.id_product'</span><span class="p">);</span>
<span class="nv">$query</span><span class="o">-></span><span class="nf">where</span><span class="p">(</span><span class="s1">'pl.id_lang = '</span><span class="mf">.</span><span class="p">(</span><span class="n">int</span><span class="p">)</span> <span class="nv">$context</span><span class="o">-></span><span class="n">language</span><span class="o">-></span><span class="n">id</span><span class="p">);</span>
<span class="nv">$query</span><span class="o">-></span><span class="nf">where</span><span class="p">(</span><span class="s1">'p.reference = "'</span><span class="mf">.</span><span class="nf">pSQL</span><span class="p">(</span><span class="nv">$ref</span><span class="p">)</span><span class="mf">.</span><span class="s1">'"'</span><span class="p">);</span>
4.4 Prohibited practices
- Never alter core tables (create satellite tables instead).
- Always prefix tables with
_DB_PREFIX_.
5. Output security and XSS prevention
5.1 Smarty escaping modifiers
Each variable in .tpl must be escaped according to context:
- HTML:
{$var|escape:'htmlall':'UTF-8'} - HTML attribute:
{$var|escape:'html':'UTF-8'} - JavaScript:
{$var|escape:'javascript':'UTF-8'} - URL:
{$var|escape:'url'}
5.2 The nofilter controversy
{$content nofilter} disables XSS protections. Use it only on HTML validated upstream with Validate::isCleanHtml(). Never apply it to raw user input (Tools::getValue).
6. Authentication, authorization, and CSRF protection
6.1 Cross-Site Request Forgery (CSRF)
6.1.1 Back Office (Admin)
- Generation:
Tools::getAdminTokenLite('AdminMyController'). - Explicit validation for custom actions or AJAX:
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="nc">Tools</span><span class="o">::</span><span class="nf">isSubmit</span><span class="p">(</span><span class="s1">'submitAction'</span><span class="p">)</span> <span class="o">||</span> <span class="nc">Tools</span><span class="o">::</span><span class="nf">getValue</span><span class="p">(</span><span class="s1">'token'</span><span class="p">)</span> <span class="o">!==</span> <span class="nc">Tools</span><span class="o">::</span><span class="nf">getAdminTokenLite</span><span class="p">(</span><span class="s1">'AdminMyController'</span><span class="p">))</span> <span class="p">{</span>
<span class="k">die</span><span class="p">(</span><span class="s1">'Forbidden'</span><span class="p">);</span>
<span class="p">}</span>
Links generated via Context::getContext()->link->getAdminLink(...) include the token automatically.
6.1.2 Front Office
- Generation:
Tools::getToken()(session-bound). - Validate server-side before any processing.
- In
ModuleFrontController, set$this->ssl = true;to force HTTPS and protect token transport.
6.2 Password hashing evolution
PrestaShop 1.7/8 uses bcrypt through core services (PrestaShop\PrestaShop\Core\Crypto\Hashing). For modules handling authentication, support verification of legacy MD5 hashes during migration, then rehash to bcrypt on successful login.
7. Modernization and PrestaShop 8 standards
7.1 Strict typing and PHP rigor
PrestaShop 8 supports PHP 8.0/8.1: respect method signatures (parameter and return types) when overriding the core, and favor declare(strict_types=1); to reduce implicit behaviors.
7.2 Service-oriented architecture (Symfony)
Declare controllers as services (config/services.yml) and inject dependencies (repositories, translator, logger) instead of static calls. This improves testability and lets you apply Symfony security policies.
7.3 Removal of deprecated features
Legacy APIs removed in 8 require an audit of deprecated calls before migration. Replace direct database or file access with modern services.
8. Quality assurance and validation tools
8.1 PrestaShop Validator
Always submit the module to validator.prestashop.com: it detects structural errors, forbidden PHP functions (eval, shell_exec), Smarty escaping issues, and licensing problems.
8.2 PHPStan: advanced static analysis
Integrate prestashop/php-dev-tools and PHPStan into CI to catch type errors, missing methods, and dead branches before runtime.
8.3 Threat intelligence: Friends of Presta
Follow security advisories from Friends of Presta to anticipate attack patterns seen in the wild (SQLi via Tools::getValue, path traversal, etc.) and patch modules promptly.
Conclusion
Securing a PrestaShop module requires defense in depth: structural guards (index.php, .htaccess), strict validation and sanitization (Tools, Validate, pSQL), safe output (Smarty escaping), anti-CSRF mechanisms, and adoption of modern PrestaShop 8 standards. Coupled with audit tools (Validator, PHPStan) and active monitoring, developers can ship robust modules that protect merchants and customers against current threats.
