Vet a store app or plugin by checking what data and permissions it asks for, who maintains it, how often it is updated, what it loads from other services, and how you would remove it. Approve it in writing with an owner, and review it again on a schedule.
Why plugins deserve a gate
Ecommerce stores grow by adding apps: reviews, loyalty, shipping, upsells, analytics. Each is third party code with access to orders, customers or the storefront. Customer reviewers know this, and they ask how you decide what gets installed. A simple approval routine is a strong answer.
The vetting checklist
| Check | What to look for | Red flag |
|---|---|---|
| Permissions | Does it request only the access its job needs? | Broad read and write on orders or customers for a cosmetic feature |
| Maintainer | Named company or person, support channel, contact for security issues | Anonymous publisher, no way to report a problem |
| Update history | Recent releases, changelog, response to past issues | Abandoned for a long time |
| External calls | What domains does it load code or send data to? | Unexplained third party endpoints |
| Data handling | What it stores, where, and whether it can be deleted | No clear answer |
| Exit | Can you remove it cleanly and revoke its access? | Leaves data or tokens behind |
Step by step
- Write the business case in one sentence. If you cannot, skip the install.
- Read the permission list before clicking install. Compare it to the job.
- Look up the publisher and the update history. Note the date you checked.
- Test in a staging store or a development copy first, and watch its network calls.
- Record the approval: who approved, what data it can reach, the review date.
- Set a calendar reminder to re-review, and remove apps nobody uses.
Keep an app register
A table with app name, owner, purpose, permissions, date approved and next review is enough. This is also the evidence a questionnaire asks for when it says "do you assess third party software before use". It turns a vague yes into a file.
Offboarding matters as much
When an app is removed, revoke its API tokens and webhooks, delete its data where you can, and confirm the storefront no longer loads its code. Leftover scripts and tokens from apps you stopped using are a common blind spot.
Code you write or customise
Plugins and themes often pull in open source packages of their own. If you build or modify them, scan their dependencies like any other project. Reviewers will ask about both.
For more on this theme, see open source dependency risk in ecommerce platforms.
Safeguard scans the dependencies of code you maintain, including custom themes and extensions, and has a free scan at https://gold.safeguard.sh/scan. It does not review closed apps you install from a marketplace, so keep the checklist above for those.
Quick check
How many apps is too many?
There is no fixed number. Every app needs an owner and a reason, and unused ones should go.
Do official marketplace listings mean an app is safe?
A listing is a starting point, not proof. Still check permissions and update history.
Should staging use real customer data?
Prefer test data. If you must use real data, restrict access and delete it after.
Last reviewed: 19 October 2026.
