Alerting: Update Swagger spec

[github-actions]

This is an automated pull request to update the alerting swagger spec.
Please review and merge.

[cycode-security]

❗Cycode: SAST violation: 'Unsanitized user input in deserialization method'.

Severity: Critical

Description

Deserializing data from untrusted sources, like user inputs or request parameters, without proper verification is a security risk. Attackers can embed malicious code or payloads within serialized data. When your application deserializes this data without checks, it becomes vulnerable to attacks.

Cycode Remediation Guideline

• Do not deserialize data from untrusted sources directly. This can lead to security vulnerabilities.
• Do validate and sanitize all data before deserializing it. Ensure that the data is coming from a trusted source and is in the expected format.

References

• OWASP Deserialization cheat sheet

Would you like to exclude this SAST violation from your status checks?
Tell us what to do with one of the following hashtags:

Tag	Short Description
#cycode_sast_ignore_everywhere	Applies to this SAST violation for all repos in your organization
#cycode_sast_ignore_here	Applies to this request only
#cycode_sast_false_positive	Applies to this SAST violation for all repos in your organization

[cycode-security]

❗Cycode: SAST violation: 'Unsanitized user input in HTTP request (SSRF)'.

Severity: High

Description

Including unsanitized user input in HTTP requests puts your application at risk of Server-Side Request Forgery (SSRF). This is a security vulnerability that occurs when a server-side application makes HTTP requests to arbitrary URLs controlled by the user. SSRF can be exploited by attackers to target internal systems behind firewalls that are otherwise inaccessible from the external network, by tricking the server into making requests to these systems.

Cycode Remediation Guideline

• Do not use direct user input to construct URLs for backend requests. If user input is necessary, ensure it is strictly validated or sanitized to prevent malicious manipulation.
• Do use a safelist or predefined mapping when incorporating user input in URLs. This ensures that your application only redirects users to safe and intended destinations.

safeURLs := map[string]string{
    "key1": "https://safe-domain1.com",
    "key2": "https://safe-domain2.com",
}
requestedKey := getUserInput()
if url, ok := safeURLs[requestedKey]; ok {
    // continue with request
} else {
    log.Fatal("Requested URL is not allowed")
}

• Do implement IP safelists and blocklists to customize and block specific IP ranges, especially those that are private, loopback, or otherwise non-routable.
• Do use network-level security measures. If your HTTP client does not support IP range blocking, run it with restricted system permissions or within a network environment where firewall rules can effectively block requests to dangerous addresses.
• Do consider using a secure HTTP proxy to route all backend HTTP requests. This proxy can serve as a filter to block requests to potentially harmful addresses, acting as an additional layer of security.

References

• OWASP SSRF Prevention Cheat Sheet

Would you like to exclude this SAST violation from your status checks?
Tell us what to do with one of the following hashtags:

Tag	Short Description
#cycode_sast_ignore_everywhere	Applies to this SAST violation for all repos in your organization
#cycode_sast_ignore_here	Applies to this request only
#cycode_sast_false_positive	Applies to this SAST violation for all repos in your organization

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 2 weeks if no further activity occurs. Please feel free to give a status update or ping for review. Thank you for your contributions!

[github-actions]

This pull request has been automatically closed because it has not had any further activity in the last 2 weeks. Thank you for your contributions!