Verifying Slack requests and securing transport
How an app proves inbound requests came from Slack (signing secret HMAC over v0:timestamp:raw body, five-minute replay window, mutual TLS, Bolt's built-in check) and how it protects outbound traffic and tokens: url_verification over valid TLS, Socket Mode, the Restrict API Token Usage IP list, tokens in headers, HTTPS redirect URLs and unfurl controls against prompt-injection exfiltration.
Identify the steps you could take to make your app communicate securely in Slack.
~8 min read · 12 practice questions ·
What the exam expects
- Verify an inbound request: rebuild
v0:<timestamp>:<raw body>, HMAC SHA256 it with the signing secret, compare toX-Slack-Signature, and reject timestamps more than five minutes off. - Diagnose broken verification (parsed or re-serialized bodies) and know Bolt does it when given
signingSecret. - Choose mutual TLS or Socket Mode when the requirement is "verify at the load balancer" or "no public endpoint".
- Pass the
url_verificationchallenge over HTTPS with a valid certificate. - Limit a leaked token's damage: Restrict API Token Usage (IP list), token rotation,
auth.revoke; send tokens in headers, never query strings. - Secure transport and AI output: validate TLS, HTTPS redirect URLs on domains you control, disable unfurls for model-generated links.
Key terms: signing secret (app secret Slack uses to sign every request it sends); X-Slack-Signature (the v0= hex HMAC on each request); replay attack (resending a captured, validly signed request); mutual TLS (your TLS server authenticates Slack's client certificate); Restrict API Token Usage (allowed IP list for the app's tokens).
Key facts
- Detail
v0:+X-Slack-Request-Timestamp+:+ raw body
- Detail
v0=+ hex HMAC SHA256 digest, keyed with the signing secret
- Detail
- Ignore requests more than five minutes from local time
- Detail
- Deprecated; replaced by signing secrets
- Detail
- Accept only
platform-tls-client.slack.com
url_verification- Detail
- Valid SSL certificate; respond HTTP 200 with
challenge
- Detail
- Up to 20 entries per Security best practices (SCIM guide says 10); single IPs or CIDR ranges; no IPv6 or local IPs
- Detail
- Web API call rejected with
invalid_auth; incoming webhooks exempt
- Detail
- Never in a GET query string; Bearer header or POST body
- Detail
- After the exchange, compare the
team.info/users.infodomain with the customer's expected domain
- Detail
- Socket Mode over a WebSocket from
apps.connections.open
Sources for this section (5)
- Why does Slack include the timestamp in the signed basestring?
- When is Socket Mode the right answer to a security requirement?
- What must an app return to a `url_verification` request?
- Why should an LLM-backed app turn off unfurling for generated links?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Slack Developer pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 38 lessons of the Slack Developer guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (12 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams