nullcipher

Slack incoming-webhook URLs (hooks.slack.com/services/…)

hooks.slack.com/services/, /workflows/ or /triggers/ followed by 43 to 56 characters of IDs and secret; the whole URL is the credential. Below: the exact rule, a live check, why it matters, and what to do if one already leaked.

Live check: Slack webhook URL

What an AI chat would receive after masking

# EXAMPLE, not a real webhook
SLACK_WEBHOOK=[SLACK_WEBHOOK_URL_1]

1 × Slack webhook URL found and masked.

How nullcipher recognises it

Checked only when the text contains “hooks.slack.com” (any case). Pattern (gitleaks rule slack-webhook-url, v8.30.1, translated to JavaScript): /(?:https?:\/\/)?hooks[^\n]slack[^\n]com\/(?:services|workflows|triggers)\/[+\/-9A-Za-z]{43,56}/ — the whole match is masked; any surrounding key name stays readable.

This is the rule text of the “Slack webhook URL” detector in the masking engine, copied from the engine when this page was built; the rule is ported from gitleaks’ default rule set (MIT licence; version, skipped rules and changes). Detectors run in a fixed order and, where two overlap, the earlier one wins.

Example (fake)

# EXAMPLE, not a real webhook
SLACK_WEBHOOK=hooks.slack.com/services/T00000000/B00000000/EXAMPLEexampleEXAMPLE0000

nullcipher replaces it with [SLACK_WEBHOOK_URL_1]. The workspace and webhook IDs are zeros, as in Slack's own documentation, and the secret part spells EXAMPLE. The scheme is left off here only to keep this page free of live-looking links; the rule matches with or without the https scheme in front.

Why it matters in an AI chat

There is no separate password: Slack's documentation says the webhook URL itself contains a secret, and anyone who has the URL can POST messages to the channel it was created for, under your app's name and icon. That makes it a ready-made phishing channel inside your own workspace.

Slack describes incoming webhooks as channel-specific and tied to the app's identity, so a leaked one cannot read messages or post to other channels. It also notes that allowed-IP lists do not apply to incoming webhooks, so an IP restriction on your app's tokens does not protect the webhook.

Webhook URLs travel in CI configs, alerting rules and scripts that people paste into an AI chat when a notification stops working.

If it already leaked

  1. Treat the URL as compromised. Slack says it actively searches out and revokes leaked secrets, but that search covers public places such as repositories, not your AI chat history, so do not wait for it. [1]
  2. Cut the webhook off. The one switch Slack's reference documents for an installation's credentials is uninstalling the app from the workspace (the apps.uninstall method, which revokes every token of that installation, unlike auth.revoke which revokes one). Then reinstall the app and pick the channel again to get a new webhook URL. [2][1]
  3. Check that the old URL is dead: a POST to it should now fail. Slack lists no_service (webhook disabled, removed or invalid) and no_active_hooks among the errors a webhook returns. [1]
  4. Update every place the old URL was stored — CI variables, alerting rules, .env files — with the new one.

Sources

  1. Sending messages using incoming webhooks — Slack Developer Docs — checked 2026-09-25.
  2. apps.uninstall method — Slack Developer Docs — checked 2026-09-25.
  3. Security best practices — Slack Developer Docs — checked 2026-09-25.

Open the full masking tool to mask a whole log, .env file or e-mail — every type at once — and restore the values in the AI's answer. Or see all 229 detectors, with a page for 46 secret types, and how to delete a chat you already sent.