It works. That does not mean much yet

An AI assistant writes code that does what you ask. The checkout field shows up, the report gets generated, the button deletes the record. That is usually where testing ends, because from the store owner’s point of view everything is fine.

But nobody asked the assistant to make the code hold up against someone who deliberately types something other than an email address into the form. In its 2025 report Veracode tested more than a hundred language models on 80 coding tasks, and in 45 percent of cases the generated code contained a vulnerability from the OWASP Top 10. Models keep getting better at writing code that runs. Security has not kept up.

CS-Cart adds one more twist. The core has good protections, but some of them only work when the add-on uses them the right way. The assistant does not know that unless someone tells it. Below are five places where things go wrong most often.

A database query glued together from form input

The classic. The add-on needs to find orders by email address, so the assistant builds the query from whatever came in from the form:

$orders = db_get_array(
    "SELECT order_id, total FROM ?:orders WHERE email = '" . $_REQUEST['email'] . "'"
);

It works until someone types a piece of SQL into the field. Then the query does something completely different from what you planned, and in the worst case pulls out the data of every customer. CS-Cart’s database functions have placeholders for exactly this: ?s for text, ?i for a number, ?a for a list. The core makes the value safe before it reaches the query:

$orders = db_get_array(
    "SELECT order_id, total FROM ?:orders WHERE email = ?s",
    $_REQUEST['email']
);

If you see $_REQUEST, $_GET or $_POST attached with a dot to the text of a query, that is the first place to fix.

Escaping switched off in a template

By default CS-Cart escapes everything a Smarty template prints on the page. HTML that a customer types into an order note shows up as plain text instead of running in the browser.

AI assistants often break this with the best intentions. When a field should show bold text or a link but shows the tags instead, the quickest fix is to add nofilter:

{$order_info.notes nofilter}

Problem solved, except that now any customer can put a script in an order note, and it will run in the browser of the administrator who opens that order in the admin panel. That is XSS, and in the Veracode study the models failed to protect against it in 86 percent of attempts. nofilter only makes sense for content created by the administrator or cleaned by the add-on beforehand. It should not appear next to data from customers or vendors.

CS-Cart protects forms against CSRF, the situation where a foreign site sends a request on behalf of a logged-in administrator. It does this with a token added to every form in the admin panel. There is a catch, though: the core checks the token only on POST requests.

An assistant asked to add a delete button often turns it into a plain link:

if ($mode == 'delete') {
    db_query("DELETE FROM ?:my_addon_items WHERE item_id = ?i", $_REQUEST['item_id']);
}

That link also works when the administrator clicks it in an email, or when a foreign site embeds it as an image. The token is never checked, because this is not a POST. Anything that changes or deletes data should run only when a form is submitted:

if ($_SERVER['REQUEST_METHOD'] == 'POST') {
    if ($mode == 'delete') {
        db_query("DELETE FROM ?:my_addon_items WHERE item_id = ?i", $_REQUEST['item_id']);
    }
}

The storefront is stricter still, because there CS-Cart checks the token by default only in selected places such as login and the customer profile. An add-on with its own storefront form has to declare that its form needs protection.

Admin screens without permissions

In the CS-Cart admin panel you can give staff limited permissions, for example order handling without access to settings. An add-on that adds a new admin screen should register it in the permissions schema.

If it does not, the core treats the screen as needing no permission at all and lets every administrator in. A support team member who was meant to see only orders can then open, say, a customer data export or integration settings with API keys. AI assistants almost never write this schema on their own, because the add-on works perfectly well without it.

A vendor sees someone else’s orders

In Multi-Vendor each vendor has their own panel and should see only their own products, orders and customers. The core enforces this on its own screens by adding a vendor ID condition to the queries.

An add-on written by an assistant that does not know it is working in a marketplace fetches data without that condition. The sales report in the vendor panel then shows the turnover of the whole marketplace, and the customer list includes people who bought from competitors. This is not a theoretical risk. You see it as soon as you log in as a second vendor. It is worth checking.

An add-on that breaks after an update

The last problem is not about break-ins, but it costs just as much. To change the look of the product page or the checkout, an AI assistant happily copies a whole core template and edits the copy. That works until the first CS-Cart update. Then the core has a new version of the template, the store keeps showing the old copy from the add-on, new features do not appear, and sometimes the checkout stops working.

CS-Cart has template hooks for this, places where an add-on inserts only its own fragment. A change made through a hook usually survives an update. A copy of a whole file almost never does.

What you can check yourself

You do not need to be a developer to catch some of these mistakes. Before you install an add-on on your live store, do a few things:

  1. Search the add-on files for $_REQUEST, $_GET and $_POST and see whether any of them is attached with a dot to an SQL query.
  2. Search the templates for the word nofilter and, for every hit, ask where the displayed content comes from.
  3. Check that delete and status change buttons submit a form and are not plain links.
  4. Log in as a staff member with limited permissions and check whether they can see add-on screens they should not.
  5. On Multi-Vendor, log in as two different vendors and compare what each of them sees.
  6. Install the add-on on a copy of the store first and go through the whole purchase path on it, payment included.

You can also ask the same AI assistant to check its code against these points. It helps, but it does not replace a review, because the model that made the mistake often cannot see it.

When to hand the code over for review

If the add-on touches orders, payments or customer accounts, or accepts form data, it is worth having it reviewed before launch by someone who knows CS-Cart from the inside. We have done this for years with our own add-ons and with add-ons clients bring in for fixing, and today more and more of them are written with AI. The review ends with a report listing the exact places to fix, which stays with you even if you make the fixes yourself.

A code review of one add-on costs from 900 PLN net, and as part of CS-Cart store care we review new add-ons as they come, before they reach your store.