Section 11: Every URL Is Hostile - Security & Abuse Prevention

Executive Summary: Section 10 handled our own failures; this one handles hostile users. Signed requests and topic policies gate access. The confirmation handshake proves an endpoint asked for traffic. Message signing (RSA-2048, once per message: 75 cores, not 300) proves a message is ours. SSRF defenses check the exact IP we connect to, defeating DNS rebinding. Spend and reputation limits stop SMS toll fraud and email abuse.

"Assume some of your customers are hostile. What do they do with this thing?" Answer in one breath: "Point us at someone else: spam and DDoS. Point us at ourselves: SSRF. Pretend to be us: forged webhooks. And one about money: SMS fraud."

Who May Publish, Who May Subscribe

Every request carries Authorization: NTF1-HMAC-SHA256 ... (Section 4). The client HMACs a canonical form of the request (method, path, query, headers, body hash) with a key derived from its secret and the date; the secret never crosses the wire. The Publish API recomputes and compares it in constant time, rejecting timestamps more than 5 minutes off, so a captured request is only replayable for a few minutes. TLS makes capture hard, and a replayed publish is just a duplicate, which at-least-once already tolerates. It takes microseconds of the ≈5 ms auth-and-quota slice.

The topic's access policy then decides who may Publish and Subscribe, including cross-account grants. Default deny; explicit deny wins.

Key Insight: Subscribe is read access to every future message. Audit cross-account subscribe grants like data-sharing agreements.