Repository navigation
Improve intended behaviour in SECURITY.md to avoid security advisories being submitted for functionality that is by design - #3455
richturner wants to merge 4 commits into
Conversation
Webhook actions and agent protocols connect to user-configured addresses by design. Several reports have treated this as SSRF, so state the intended behaviour, where egress restriction belongs and what remains in scope. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
richturner
changed the title
wborn
left a comment
wborn
left a comment
There was a problem hiding this comment.
This is an initial AI-assisted review.
The new section provides useful clarification about intentionally unrestricted outbound connectivity and deployment-level network controls. This aligns with OpenRemote's integration capabilities and helps distinguish expected functionality from genuine security vulnerabilities.
The notification delivery and acknowledgement section should describe its intended authorization boundaries more precisely. The implementation only permits anonymous updates for notifications targeting publicly readable assets, and the security policy should explicitly preserve reports involving unauthorized notification state modifications, including those occurring within the same realm.
|
|
||
| #### Notification acknowledgement and delivery | ||
|
|
||
| The HTTP API endpoints for notification delivery and acknowledgement do not require authentication but do require the notification ID and target ID, this is by design for anonymous consoles. |
There was a problem hiding this comment.
Could the intended authorization boundary for notification delivery and acknowledgement be described more precisely?
NotificationResourceImpl.verifyAccess() permits anonymous updates only for notifications targeting publicly readable assets, provided the notification ID and target ID match.
The current wording could be interpreted as treating knowledge of both IDs as sufficient authorization for all notification targets.
It would also be useful to explicitly keep unauthorized notification state modifications in scope, including cases involving authenticated callers within the same realm. These are not necessarily covered by the existing exceptions for missing roles or cross-realm access.
|
Description
Adds a "Behaviour That Is Intended" section to
SECURITY.md, which GitHub links from the vulnerability report form.Webhook actions and agent protocols connect to whatever address they are configured with, internal addresses included, and we keep receiving reports that treat this as SSRF. The section states that this is intended, that restricting egress belongs to the deployment, and which cases remain in scope: reaching these features without the required role or from another realm, exposing a response or secret to someone who could not read it otherwise, and bypassing an operator-configured destination restriction.
It sits before "What To Include" so reporters see it before they write a report.
Checklist