Skip to main content

Hold internal tools to the same standard as your app

Give every internal dashboard, support tool, and admin panel that can change merchant settings the same authentication, network boundary, and escaping as your app.


Internal tools are part of your app's attack surface even when they live in a separate project with their own login. They're discoverable through URLs in public JavaScript bundles, predictable subdomains, and certificate transparency logs, which publish the hostname on every TLS certificate issued. A stored cross-site scripting bug in a tool that renders merchant data becomes a cross-store attack, because the script runs with the access of the staff member viewing it.


Apply the following to each tool that can read or change merchant data:

  • Require real authentication, with multi-factor authentication or single sign-on, and authorize each action. An unlisted URL isn't access control.
  • Put the tool on a private network or behind a VPN.
  • Escape all merchant data that the tool renders. See Render untrusted content as text.
  • Limit which staff can change storefront-rendered settings, and log every change.
  • Include the tool's code when you check your app on every release.

The app security checks cover an internal tool only when you scan its code. See Check your app on every release for how to scan a separate repository.


Was this page helpful?