saas-security

• SKILL.mdcore · 7,022 bytes
• SKILL.mdcore · 7,022 bytes
• metadata.jsonasset · 1,439 bytes
• references/vendor-specifics.mddoc · 3,963 bytes
• references/verifying-findings.mddoc · 4,746 bytes

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/saas-security/SKILL.md. -->

# SaaS Integration Security

Wiring your application to a third-party SaaS platform: verifying an inbound webhook against the vendor's own scheme rather than a generalized one, why a valid signature identifies the sender and not the user in the payload, replay windows, one credential per integration and per environment, least-privilege scopes, and treating a bulk export as a data boundary. Use when writing a webhook receiver, an OAuth integration, a SCIM endpoint, or any code that authenticates to or from a SaaS vendor.

## ALWAYS

- Verify an inbound webhook against **that vendor's documented scheme**, and do not generalize from another one. Vendors differ in the header, in the secret, and — the part that breaks a generalized implementation — in the **canonical string** that gets signed. Some sign the raw body, some sign a version prefix plus a timestamp plus the body, some sign the HTTP method and path as well. Read the vendor's page for the vendor you are integrating; a signature routine copied from a different vendor produces a receiver that rejects every legitimate event, and the fix someone reaches for is to turn verification off.
- Verify against the **raw request body**, exactly as received, before any parsing or re-serialization. A framework that decodes JSON and re-encodes it changes whitespace and key order, and the HMAC no longer matches — which again ends with verification being disabled rather than fixed.
- Check the **timestamp** the vendor sends and reject requests outside a short window, then reject **replays** inside it by recording delivery or event ids. A signature is valid forever; the window narrows the replay opportunity and the id store closes it.
- Compare signatures in **constant time**. `crypto-misuse` owns the comparison API for each language.
- Treat the signature as proof of **who sent the payload, not who the payload is about**. This is the distinction that matters most in this domain: a verified Zoom or Calendly or HubSpot event genuinely came from that vendor, and the `email`, `from`, or custom fields inside it may still be attacker-chosen — anyone who can book a meeting or submit a form controls them. Resolve the subject to a canonical id server-side. `auth-security` owns the general rule for producer-asserted identity.