diff --git a/docusaurus/docs/get-started/best-practices.md b/docusaurus/docs/get-started/best-practices.md
index b0e9866c5..f38fb006b 100644
--- a/docusaurus/docs/get-started/best-practices.md
+++ b/docusaurus/docs/get-started/best-practices.md
@@ -22,6 +22,7 @@ Is something missing from this list? [Let us know](https://github.com/grafana/pl
 - **Include default dashboards in your data source or app plugin** - Refer to [Bundling of dashboards](../key-concepts/plugin-types-usage.md#bundling-of-dashboards) for more information.
 - **Ensure that the minimum version of Grafana is correct** - Make sure that the `grafanaDependency` in your `plugin.json` points to the earliest version of Grafana that your plugin fully supports.
 - **Don't expose sensitive information** - For security reasons, avoid exposing sensitive information such as secrets. Make sure to utilize log levels properly, avoid excessive logging, and never log credentials or other sensitive information.
+- **Don't allow user input of arbitrary code** - For security reasons, don't let your plugin's users enter potentially malicious code to prevent arbitrary code execution.
 - **Avoid using `console.log` in your plugin** - Console messages are usually for debugging purposes and therefore not suitable to ship to the client.
 - **Add linting and auto-completion** - Reduce bugs in your plugin by adding a code snippet like [this one](https://grafana.com/blog/2021/01/21/6-tips-for-improving-your-grafana-plugin-before-you-publish/#tip-3-add-linting-and-auto-completion-to-your-pluginjson) in VS Code to get linting for your plugin.
 - **Include a well-written README** - Give users a deeper understanding of how to configure and use your plugin, but don’t make it essential reading. You want users to be able to understand your plugin intuitively without referring to the documentation if possible.