Slack incoming-webhook URL pattern appears in public content
ShipReady found a non-placeholder URL matching its supported Slack incoming-webhook pattern in scanned page or script content.
Why it matters
If the URL is a live incoming webhook, it should not be included in public browser content where it can be copied.
How ShipReady detects it
What it inspects
ShipReady scans fetched page content and discovered script content for the supported https://hooks.slack.com/services/... incoming-webhook URL structure and applies its placeholder guard.
What triggers a finding
The rule triggers when a non-placeholder string matches the supported Slack incoming-webhook URL pattern.
What the evidence shows
The scanner observed a URL matching its Slack incoming-webhook format and preserves only a redacted prefix in the report.
Limits of this check
ShipReady does not request the URL, submit a message, validate the webhook, or identify its workspace or channel. The format match does not prove that the webhook is active or that it can post a message.
How to fix it
Trace the public URL
Identify the source or build configuration that placed the matched URL into public content.
Remove confirmed webhook URLs from client assets
Keep real webhook URLs in trusted server-side configuration and prevent them from being exposed in browser bundles.
Review a confirmed webhook
If the URL is confirmed as live, use the workspace owner's Slack controls to replace or revoke it.
How to verify the change
Inspect deployed output
Search deployed HTML and JavaScript after release.
Expected: No unintended string matching the supported Slack incoming-webhook URL pattern remains in public assets.