OpenCart Penetration Testing

Every OpenCart extension is packaged as an OCMOD zip, installed through Extensions > Installer, and then runs from inside the extension/ directory with the same reach into the database and admin panel as the code OpenCart shipped with.

Why OpenCart findings sit in your extensions, admin access and checkout, not the core platform

OpenCart ships extensions as a zip package ending in .ocmod.zip, uploaded through Extensions > Installer, which creates a new folder inside the extension/ directory named for the package. Where a module needs to change behaviour that OpenCart’s event hooks do not cover, an OCMOD XML file inside that package searches for a line in a core file or template and inserts new code around it, all without editing the original file. OpenCart’s own developer guide describes OCMOD as the fallback once events are insufficient, and calls for a permission check inside every extension controller. We review installed extensions for exactly that: what each one can reach, whether its own permission check is actually enforced, and what an OCMOD modification changes in the pages and controllers around it.

OpenCart’s own installation guide recommends renaming the admin directory during setup and using strong admin credentials, because the default path is well known. Inside the admin panel, System, Users, User Groups sets two layers of permission for every section: Access controls what a group can see, and Modify controls what it can change, with Modify automatically granting Access underneath it, so a single checkbox can grant more than whoever configured it intended. Installed extensions add their own permission categories on top of this, covering payment, shipping and marketing extensions individually. We test whether the admin path and login are still discoverable, and map what each user group’s combined Access and Modify permissions actually allow against the role it was created for.

Coupons and any other adjustment to an order’s price run as their own extension type, calculated as a percentage of the cart total or a fixed amount and applied before Sales, Orders records the final figure your customer paid. OpenCart’s own coupon documentation caps a percentage coupon so it cannot take an order below zero, and ties usage to a start and end date, a minimum cart total, and a limit per coupon and per customer. Every order and every saved address belongs to a customer record identified by its own ID, and OpenCart’s admin warns that deleting a customer removes their order history and addresses permanently rather than just hiding them. We test whether those limits are enforced server-side rather than trusted from the checkout page, and whether one customer’s order or address is reachable by changing the ID in a request meant for their own.