Audit stored settings and custom code
After you fix a vulnerability, audit what's already stored for every store, because fixing the path doesn't remove what came through it.
If an attacker used an unauthenticated endpoint or a public metafield to store a script, then closing the endpoint leaves the script in place, and it keeps running until you remove it.
If your app stores custom CSS, JavaScript, HTML, or any other value that renders on storefronts, then check what's stored now, and again after you fix any of the issues in these guides. Look for:
- Script elements, inline event handlers such as
onerror, andjavascript:URLs in values that should contain only text or CSS. - Script, stylesheet, or image URLs that load from domains that you don't recognize.
eval,new Function,atob,String.fromCharCode, and long encoded or obfuscated strings.- Code that redirects buyers, rewrites links or forms, or reads or intercepts checkout, payment, or login fields.
- Values that changed recently from a user, tool, or IP address that you don't expect.
Check every place that a rendered value comes from: your database, app-owned and app-data metafields, public metafields that your extension reads, and configuration that your servers return to your extension at runtime. If you find malicious code, then remove it, find the path that it came through, and follow the steps in Respond to a security incident.
Anchor to VerifyVerify
No app security check covers this practice, because the checks read source code, not stored data. Script the search against your database so that you can rerun it.