feat: add outbound webhooks with at-least-once delivery #325
probelabs / Visor: security
succeeded
Feb 28, 2026 in 40s
✅ Check Passed (Warnings Found)
security check passed. Found 2 warnings, but fail_if condition was not met.
Details
📊 Summary
- Total Issues: 2
- Warning Issues: 2
🔍 Failure Condition Results
Passed Conditions
- global_fail_if: Condition passed
Issues by Category
Security (2)
⚠️ api/webhook_handlers.go:127 - API error responses include raw error messages from internal libraries (e.g., fromc.ShouldBindJSON). This can leak implementation details to the client. While the API is admin-only, it's a security best practice to log detailed errors server-side and return a generic, non-revealing error message to the user.⚠️ models/webhook.go:92 - Thewebhook_eventstable, which serves as the persistent delivery queue, has no data retention or cleanup mechanism. Events with a final status of 'delivered' or 'exhausted' remain in the table indefinitely. Over time, this can lead to unbounded table growth, potentially causing database performance degradation and resource exhaustion.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check warning on line 130 in api/webhook_handlers.go
probelabs / Visor: security
security Issue
API error responses include raw error messages from internal libraries (e.g., from `c.ShouldBindJSON`). This can leak implementation details to the client. While the API is admin-only, it's a security best practice to log detailed errors server-side and return a generic, non-revealing error message to the user.
Raw output
Modify the `webhookError` calls that use `err.Error()` for request binding or other internal errors. Log the full `err` object on the server and return a consistent, generic error detail like 'Invalid request body' or 'An internal error occurred'.
Check warning on line 101 in models/webhook.go
probelabs / Visor: security
security Issue
The `webhook_events` table, which serves as the persistent delivery queue, has no data retention or cleanup mechanism. Events with a final status of 'delivered' or 'exhausted' remain in the table indefinitely. Over time, this can lead to unbounded table growth, potentially causing database performance degradation and resource exhaustion.
Raw output
Implement a periodic cleanup task to prune old events from the `webhook_events` table. A new configuration option, similar to `LogRetentionDays`, could control how long to keep terminal-state ('delivered', 'exhausted') events before deleting them.
Loading