Before installing a storefront plugin or app, check who maintains it, what access it asks for, what code it loads from elsewhere, how fast it patches, and how you would remove it. Ten questions, answered in writing, will filter out most of the risky ones in about an afternoon each.
Why plugins are the weak spot
Your store platform may be well maintained. Your twelve plugins might not be. Each one can read orders, touch the checkout, add scripts to every page or call out to its own servers. Small maintainers get acquired, abandon projects or have their accounts taken over, and you inherit the change without a notice.
The ten questions
- Who maintains it? A named company or person, with a way to report security problems.
- When was it last updated? Long silence is a signal, even without a known flaw.
- What permissions or scopes does it request? Match them to the job. A shipping label tool should not need customer emails and payment data.
- What data leaves your store? Ask where it goes and why.
- What does it load at runtime? Remote scripts are code you do not review.
- Does it touch the checkout or login page? If yes, raise the bar.
- What does it depend on? Third party libraries inside the plugin carry their own flaws.
- How does the vendor announce and fix vulnerabilities? Look for a changelog and a past record of prompt fixes.
- Can you test it first? Use a staging store.
- How do you remove it cleanly? Check for leftover code, tables and scheduled jobs.
Keep an inventory
A simple sheet works: plugin, version, owner on your side, what it does, permissions, date reviewed. Review it every quarter. Delete anything unused; an inactive plugin is still attack surface.
Update with intent
Turn on security updates where the platform allows it, but test in staging first for anything on the checkout path. Subscribe to the vendor's advisories. If a vendor goes quiet and a vulnerability is public, plan the swap, not a wait.
For custom and theme code
If you build your own extensions or themes, they have dependencies too. Scanning those dependencies and keeping an SBOM lets you answer, quickly, whether a newly disclosed library flaw affects you. Safeguard offers dependency scanning and SBOMs for that, and a free scan at gold.safeguard.sh/scan. It does not scan a closed source plugin you cannot upload, so the questions above still matter.
Scoring the answers
Give each question a red, amber or green mark. Any red on questions three, four or five should block installation until the vendor explains it. Two or more ambers on a checkout facing plugin should trigger a staging trial with network monitoring, so you can see what it calls. Save the scored sheet. When the plugin later has an incident, you can show what you knew when you approved it, and you can compare the old answers with the new ones to see what changed. Repeat the sheet briefly at each major version.
Quick check
Is a plugin with many installs safe?
Not necessarily. Popularity helps you find problems reported by others, but it does not replace checking permissions, update history and runtime behaviour.
Last reviewed: 19 October 2026.
