Can I audit my Sylius shop without being a developer?

You can check the version, the channel settings, the admin accounts and whether discounts behave as expected. Reading custom code and transitions needs someone who works with Symfony.

What does a Sylius audit deliver?

A useful one gives a ranked list of risks with evidence from your project and a rough effort for each. Be wary of a generic score or a report that could describe any shop.

Is an automated scanner enough?

It helps with known vulnerable dependencies. It will not tell you that a custom transition skips a payment check or that two promotions combine in a way you never wanted.

How often should a shop be audited?

There is no official rule. Sensible moments are before an upgrade, after a change of provider, and before a large campaign that would make a failure expensive.

Auditing Sylius with its official documentation

The Sylius official documentation on architecture, channels, the state machine, promotions and security can double as an audit grid: each page describes how the platform should behave, and an audit compares that with your project. The best-value checks are the exact version, the hostname on each channel, the custom transitions on orders and payments, and the way promotions combine. None of them requires a long engagement to start.

I offer Sylius audits, so I have an interest here. The aim of this article is that you can ask better questions, whoever you hire.

Start with the architecture, because it tells you where risk lives

The architecture page separates Components (standalone libraries), Bundles (the Symfony integration), and the Platform, with Core, Admin and Shop on top and an API built on API Platform. It stresses that business logic is kept apart from the API.

For an audit, the question is how much your project has drifted from this. A shop that extends Sylius through services and configuration can usually be upgraded. A shop where business rules sit in controllers, or where vendor behaviour has been overridden in many places, will resist every upgrade. Standard tools such as composer outdated give the dependency picture, but only reading the code gives this one.

Note that the documentation exists in several generations. Some of the pages I quote below are from the 1.14 documentation, which is the one I could read in full. The concepts carry over, but the mechanisms change, as the state machine shows.

The audit grid: what to check against the docs

Area	What the docs say	What I look for
Channels	A channel is one sales channel, detected by hostname by default	A hostname on each channel, correct billing data
State machine	Orders, payments and shipments move through defined transitions	Custom transitions and callbacks, code that sets a state directly
Cart promotions	Rules decide eligibility, actions apply the discount, priority and exclusivity arbitrate	Unwanted combinations, expired or unlimited codes
Catalog promotions	Applied in the background through Symfony Messenger	A supervised worker, failed messages
Security	Fixes arrive in patch releases	Latest patch of a supported branch, admin accounts

Channels: a configuration detail with a security angle

The channels page defines a channel as a single sales channel, such as a web store, a mobile app or a cashier, each able to differ in products, currencies, locales, countries, themes, hostnames, taxes, and payment and shipping methods. Each channel also holds the billing data used on invoices, so a wrong entry there produces wrong documents.

Hostnames are where this turns into security. The 2.3 upgrade notes describe a high severity issue: when a channel had no hostname, password reset emails could point to an attacker's domain. The patch exists, and the recommended configuration is a hostname on every channel or a strict trusted_hosts pattern. That takes a few minutes to check and is the first thing I would look at.

State machine: the version changes the audit

The 1.14 docs describe the Winzou bundle, with graphs defining states, transitions and callbacks, and a checkout that runs through states such as cart, addressed, shipping_selected, payment_selected and completed. The 2.0 upgrade guide then records that the default adapter became Symfony Workflow.

So the first question for any custom logic is which engine it is written against, because a callback written for Winzou has to be dealt with on the way to 2.x. The second is whether code changes states directly. The order documentation shows that payments and shipments have their own machines, with an order reaching fulfilled once they are complete. Code that sets a field without a transition can bypass callbacks, such as those that send an email or adjust stock, and it tends to surface as orders stuck in odd states. A query counting orders per state, compared with what the business expects, is a quick and revealing test.

Promotions: where the money leaks

The cart promotions page explains that rules only make an order eligible, while actions apply the discount, and that an exclusive promotion cannot combine with another. It also notes that the promotion processor first reverts existing promotions on an order, then re-evaluates them. Any custom code that adds a discount has to survive that cycle.

Catalog promotions work differently: they run in the background, the 1.14 docs mention allowing roughly 2 to 10 minutes after the start date, and any change recalculates the whole catalog. Without a running worker the discount simply does not appear. Finally, the 2.3 notes describe a high severity race in which simultaneous checkouts could exceed coupon limits, fixed with a lock in recent patches. If your business runs limited codes, this one is worth more than a theoretical concern.

Security: start with the patch level

Most of the security audit is unglamorous. Compare your version with the October 2026 release (1.14.21, 2.1.17, 2.2.12 or 2.3.2) and with the support dates. The same notes mention payment requests accepting disabled or unassigned payment methods, now rejected with an HTTP 422 error, which matters for anyone whose integration relied on that behaviour. Then review admin accounts, exposed development tools, and third-party plugins, since they sit outside the core project's releases.

When a full audit is not worth buying

If your shop is close to the standard installation and you are already planning to patch, a half day of checks by your current developer may be all you need. If you already know you will replace the platform, audit only the data you plan to carry over. And if your provider is doing good work and you simply want reassurance, ask them to walk you through this grid before you pay someone else.

What should you ask of an auditor? Evidence from your own code, risks ranked by business consequence, and a clear line between what must be done now and what can wait. My own approach is on the Sylius developer page. Send me your version and what worries you, and I will tell you within 24 working hours whether an audit makes sense for you.