PrestaShop Security Audit is a security audit service for PrestaShop stores, in which a specialist examines the shop the way an attacker and an auditor would, and turns what it finds into a graded report with ordered fixes. It installs, and the first full scan runs from one button in the back office.
It settles the merchant's blindest risk: a card skimmer does not slow the page or break anything, it sits in a template or a script, copies what shoppers type into payment forms, and keeps doing it until somebody reads the code. The same silence hides forgotten admin accounts, world-readable configuration, backups reachable from the street, and modules with published weaknesses.
One click runs the whole examination, and each area goes deep. Core and module files are compared against known-good releases to surface injected or quietly modified code, templates and scripts are inspected for unfamiliar and disguised payloads, and the database is reviewed for recently created admin accounts and stale privileges. Installed modules are matched against published security advisories, and the shop's outside surface is tested from outside: leftover installer and backup files, developer traces, revealing test pages, open directory listings and the protection of the admin entrance, each confirmed as actually reachable rather than merely present. Settings that decide exposure, forced encryption, session cookie protection, sign-in throttling, debug output left on, are read and judged too.
The report gives a score, a grade and findings ordered by severity, each with what it means and the exact hardening step, and evidence of an active compromise is flagged first with containment steps. Uncertain matches say they are uncertain instead of crying wolf, and a check that fails reports itself instead of silently vanishing. Every run is kept in history with its score, grade and totals, scans repeat on the schedule you set with findings reaching you by email, and nothing about your shop ever leaves your server: the examination is local, its data path is read-only, and the self-checks call only your own addresses. Agencies enroll many shops into one fleet view over a signed, consent-scoped connection.
A skimmer becomes a finding instead of a headline, the hardening backlog orders itself by severity instead of by anxiety, and the bank's security questionnaire gets answered with a graded, dated history instead of a shrug.
Summary of what the module offers
PrestaShop Security Audit reads the shop the way an attacker would and reports like an auditor. This page answers six questions:
- What the scan examines: files, database, modules, settings and the shop's outside surface
- Where the findings go: nowhere, the scan is local, read-only and private
- What a report contains: score, grade, severities, exact steps, honest uncertainty
- How improvement is proven: a kept history of every run
- How it stays current: scheduled scans and findings by email
- How agencies use it: a signed fleet connection across many shops

What does the scan actually examine?
Four layers. Files: core and module code compared against known-good releases, templates and scripts inspected for injected, disguised or unfamiliar payloads, and world-writable paths reported. Database: recently created admin accounts, stale privileges and suspicious sign-in surface. Modules: the installed list matched against published security advisories, with abandoned modules flagged.
Then the outside: the scanner knocks on the shop's own public doors, leftover installer files, reachable backups, developer traces, revealing test pages, open directory listings and the admin entrance, and reports the difference between a file that exists and one the whole internet can fetch. Configuration completes the picture: forced encryption, session cookie protection, sign-in throttling and debug output left on in production.

Where do my findings go?
Nowhere. The scan runs inside your server, its database access is guarded to read-only questions, and the results are stored in your own shop. No inventory of your modules, versions or paths is sent to anyone, which is not the standard in this category.
Even the exposure checks respect the boundary: they request only your shop's own addresses, from your shop, to confirm what an outsider genuinely reaches. Your risk map is yours.

What does a report look like?
A score and a grade at the top, then findings ordered by severity, each carrying what it means, why it matters and the exact step that closes it. Evidence pointing at an active compromise is flagged first, with containment steps, because that hour is not the hour for reading everything.
Two honesty rules run through it. A match that is not certain says so and is downgraded rather than presented as a confirmed breach. And a check that fails to run reports its own failure visibly while the rest of the scan completes, so an error never masquerades as a clean result.

How do I prove things are improving?
Every run is kept: score, grade, totals per severity, what triggered it, how long it took. The history screen turns security from a feeling into a curve, which is exactly what a boss, a bank or an insurer asks for.
Scans repeat on the schedule you set, and new findings reach you by email, so the shop is examined regularly, not only in the week someone remembered to worry.

I manage many shops. Does this scale?
Yes, by explicit enrollment. Each shop joins the fleet with a token, the connection is bound to a narrow, read-only consent, and every command and result travels signed. A remote request with the wrong scope, or one trying to smuggle its own scan parameters, is refused by the shop itself.
The agency sees every enrolled shop's posture from one place, and each merchant's data still lives on that merchant's server. Withdrawal is one click on the shop's side.

What does it change on the shop, and how does the start look?
Nothing on the storefront: the module is detection, not interference. It adds no visitor-facing code, blocks no traffic and deletes no files; it tells you precisely what to change and where, and leaves the changing to you.
The start is installation and one button. The two switches that exist, deep scan and the outside self-check, arrive already on, so the first report is the full picture, minutes after installing.

-
ReferenceSVC-SECURITY-AUDIT
-
In stock999999 Items
-
Service typeAudit
-
Turnaround3–5 business days
-
DeliverableSeverity-scored risk report + walkthrough
-
Access neededStore URL; read access (admin/files optional)
-
PrestaShop versions1.6 / 1.7 / 8 / 9
-
ImplementationQuoted separately
-
NDA / DPAAvailable on request
What customers say about us
Be the first to share your experience with this module.
Write a Review
A severity-scored hardening plan for your real store, built around the places PrestaShop compromises actually happen.
A specialist reviews your live store, files, database and configuration for malware, skimmers, stale access, vulnerable modules and recovery gaps. The output is not a scare-sheet: every risk is evidenced, ranked by severity and likelihood, and mapped to the concrete remediation.
Malware, skimmers & persistence
The compromise paths that cause real damage and repeat infections.
- Magecart / checkout skimmer scripts, obfuscated JavaScript and exfiltration endpoints
- Backdoors and web shells in
/img,/upload, module folders and modified core files - Database tampering: malicious hooks, rogue employees, altered configuration and suspicious sessions
Vulnerability exposure
Known weaknesses matched to your exact versions and configuration.
- SQL injection and Smarty/template RCE exposure where they could lead to full takeover
- Core and module CVEs, especially abandoned modules attackers actively scan for
- CSRF, upload, path and debug-mode issues that can chain into something worse
Access, transport & recovery
Whether the store can be protected, contained and restored after an incident.
- Employee accounts, stale SuperAdmins, permissions, 2FA and back-office exposure
- TLS, security headers, cookie flags, file permissions and production debug settings
- Backup coverage and whether a clean, tested restore is actually possible
How it works
-
Intake Day 1You share the store URL, PrestaShop version, host and any incident history or symptoms.
-
Specialist review Days 2-4We inspect files, database, templates, JavaScript, modules and configuration, reproducing serious findings before recording them.
-
Triage During reviewActive skimmers, exposed backdoors or other Critical findings are flagged immediately instead of held for the final report.
-
Handover Final dayYou receive the severity-scored report, hardening roadmap and a walkthrough call or thread.
What's included - and what's not
This is diagnosis and a prioritised plan. It stays honest about the boundary between finding the work and doing the work.
A report that names the risk, not just the category
A typical Critical row would read: External script on checkout template - Critical / High likelihood / Medium effort - remove injection, rotate keys, review order data. Other concrete rows include default-path back office with no 2FA, an unrecognised SuperAdmin, a module two majors behind a security fix, _PS_MODE_DEV_ enabled in production, or a database backup exposed under webroot.
FAQ
Do you need admin credentials?
Is this just an automated scan?
What if you find an active compromise?
Will the audit risk my live store?
Is my data private?
Related services
Loading feature requests...
Easy return - no questions asked
Install, set up and take profit
Priority Help & Satisfaction Over Sales