Docs: Add plugin security development guide #1195
Conversation
|
Hello! 👋 This repository uses Auto for releasing packages using PR labels. ❌ This PR cannot be merged until the following issues are addressed:
🏷️ More info about which labels to use
|
|
|
||
| ## General best practices | ||
|
|
||
| ### Security audits and reviews |
There was a problem hiding this comment.
If we want people to use gosec it should become part of the default scaffolding, maybe as a step in GH actions workflow.
There was a problem hiding this comment.
it is - the validator runs in the release workflow, but we should mention that
|
|
||
| ### Data handling | ||
|
|
||
| - **Prevent data exposure**: Don’t expose sensitive data like user credentials, API tokens, or personally identifiable information (PII) through logs, requests, or the browser console. |
There was a problem hiding this comment.
Probably should provide some example of how to do this. One way is to scan automatically for potentially exposed secrets with trufflehog. Which we also want to offer as part of the GH action checks: https://github.com/grafana/grafana-community-team/issues/224
| ### Data handling | ||
|
|
||
| - **Prevent data exposure**: Don’t expose sensitive data like user credentials, API tokens, or personally identifiable information (PII) through logs, requests, or the browser console. | ||
| - **Encrypt data**: Always encrypt sensitive data in transit using SSL/TLS, and encrypt at rest when needed. |
There was a problem hiding this comment.
Not sure how we are asking people to do that - or do you mean on the server side / not in the plugin?
Or do we want to say - store sensitive configuration in secureJsonData https://grafana.com/developers/plugin-tools/how-to-guides/data-source-plugins/add-authentication-for-data-source-plugins#store-configuration-in-securejsondata?
|
|
||
| - **Use HTTPS**: Ensure all external requests use HTTPS. | ||
| - **Set timeouts**: Set timeouts for external requests to prevent them from hanging indefinitely. | ||
| - **Implement retry logic**: Use retry logic with exponential backoff for external requests. |
There was a problem hiding this comment.
how is this bullet point "Implement retry logic" related to security?
|
|
||
| - [OWASP Top 10](https://owasp.org/www-project-top-ten/) – The most critical security risks for web applications. | ||
| - [GoSec](https://github.com/securego/gosec) – A security analysis tool for Go. | ||
| - [npm audit](https://docs.npmjs.com/cli/v6/commands/npm-audit) – Check for vulnerabilities in npm dependencies. |
There was a problem hiding this comment.
| - [npm audit](https://docs.npmjs.com/cli/v6/commands/npm-audit) – Check for vulnerabilities in npm dependencies. | |
| - [npm audit](https://docs.npmjs.com/cli/commands/npm-audit) – Check for vulnerabilities in npm dependencies. |
to avoid linking to outdated npm cli versions
|
|
||
| ## General best practices | ||
|
|
||
| ### Security audits and reviews |
There was a problem hiding this comment.
it is - the validator runs in the release workflow, but we should mention that
|
|
||
| ### Security audits and reviews | ||
|
|
||
| Before submitting a plugin for publication, conduct security audits and reviews. Use tools like `gosec` for Go and `eslint` for TypeScript to catch common issues. Peer reviews should focus on identifying injection vulnerabilities, improper handling of sensitive data, and weak authentication. |
There was a problem hiding this comment.
If its just about creating secure plugins, i don't see a need to mention submitting for publication, it applies to private plugins too.
|
|
||
| ### Minimizing dependencies | ||
|
|
||
| Keep dependencies to a minimum. Update packages regularly and remove unused ones. Use tools like `npm audit` and `go mod tidy` to identify outdated or vulnerable dependencies. |
There was a problem hiding this comment.
this should mention our update cmd as well
| ### Secure coding practices | ||
|
|
||
| - **Don’t hardcode secrets**: Avoid hardcoding API keys, tokens, or passwords in your code. | ||
| - **Use least privilege**: Ensure your plugin uses the least privileged account or role when accessing resources. |
There was a problem hiding this comment.
is this applicable?
|
|
||
| Ensure [secure authentication methods](../how-to-guides/data-source-plugins/add-authentication-for-data-source-plugins.md) are in place for API interactions. Always verify that the user accessing your plugin has the appropriate permissions. | ||
|
|
||
| - **Authorization checks**: Confirm that users have the required roles before allowing access to certain actions within the plugin. |
There was a problem hiding this comment.
would need a guide
|
|
||
| When the frontend communicates with the backend: | ||
|
|
||
| - **Use HTTPS**: Always use HTTPS to protect data. |
|
|
||
| ### Configuration validation | ||
|
|
||
| Validate user-provided configuration values to prevent configuration errors that could lead to security vulnerabilities like injection attacks. |
There was a problem hiding this comment.
this feels too vague
|
|
||
| ### Storing secrets | ||
|
|
||
| Store API keys, tokens, and other secrets securely. |
Draft of new plugin security guide for collaboration with David Harris and others.