Security at SlingHook

At a glance

• All traffic to SlingHook is served over HTTPS.
• Passwords are hashed with bcrypt, API tokens are stored only as SHA-256 hashes, and endpoint signing secrets are encrypted at rest with libsodium.
• Every request for an endpoint, a captured webhook or a replay is checked against the signed-in account.
• Server-side replays can’t reach private networks or cloud metadata services.
• Sign-in, sign-up and webhook ingest are rate limited.
• Card details never touch our servers: Paddle handles checkout.

Accounts and sign-in

• Passwords are hashed with PHP’s password_hash (bcrypt) and never stored or logged in plain text. Sign-in checks a password hash even when the email has no account, so its timing doesn’t reveal which addresses are registered.
• Brute-force protection. Failed sign-ins are counted per email and IP address, per IP address and per email, and once a limit is hit further attempts are refused for up to 15 minutes. Sign-ups are limited per IP address. The counters store only hashes of the email and IP.
• Session cookies are HttpOnly, SameSite=Lax and Secure, and the session id is replaced every time you sign in or sign up, which prevents session fixation.
• Cross-site request forgery. Every request that changes data must be sent as JSON, and requests the browser marks as cross-site are refused. A form or script on another website can’t act as you.
• API tokens for the CLI carry 160 bits of randomness and are shown once. They can only be created from a signed-in dashboard session, not by another token, and you can revoke them at any time.

Keeping your data separate

Every database query uses prepared statements, and every lookup of an endpoint, captured request, replay attempt or scenario is scoped to the account that owns it. Knowing another account’s endpoint id or request id doesn’t let you read, replay or delete it. The live event stream checks ownership of the endpoint before it sends anything.

Catch URLs

Each endpoint gets a random UUID URL. Anyone who has the URL can send it requests, which is how webhook providers reach you, so treat it like a password.

• Custom responses are limited to data formats (application/json, application/xml, text/xml, text/plain and application/x-www-form-urlencoded). A catch URL can never serve a web page.
• Every catch response is sent with X-Content-Type-Options: nosniff and a sandboxing Content-Security-Policy, so a browser won’t run anything a response contains.
• Bodies over 1 MB are truncated before they are stored, and the dashboard marks them as truncated.

Signing secrets and signatures

• Signing secrets you save on an endpoint are encrypted with libsodium (XSalsa20-Poly1305) using a server-held key before they reach the database. They are only shown when you ask to reveal them.
• Signatures are checked for Stripe, GitHub, Shopify, Slack and Standard Webhooks using constant-time comparison. Timestamped schemes reject signatures older than 5 minutes.
• You can pin an endpoint to one provider’s scheme, so a captured signature from one provider can’t be passed off as a valid signature from another.

Replay and local relay

When the hosted service replays a webhook, the target address is checked before the request is sent. Loopback, private (RFC 1918), link-local, carrier-grade NAT and reserved ranges are blocked, including the cloud metadata address 169.254.169.254. The request is then pinned to the address that passed the check, so a DNS change between the check and the connection can’t redirect it. A missing configuration fails closed: private targets are only allowed on installs explicitly set up for development.

To reach localhost, use the SlingHook CLI. It runs on your machine, opens an outbound connection to SlingHook and forwards each webhook to your local server itself. You don’t open a port or expose your machine to the internet, and SlingHook never connects into your network. The CLI saves your token in a config file only your user can read.

Exported code

“Export as code” turns a captured request into cURL, Node, Python, PHP, Go or .http snippets. Header values and bodies come from whoever sent the webhook, so every value is quoted and escaped for its language before it goes into the snippet. A malicious header can’t turn a copied cURL command into a different shell command.

Abuse limits

• Each endpoint has its own request rate limit, and ingest, sign-in and sign-up are also rate limited per IP address at the web server.
• Live event streams are capped per IP address so one client can’t tie up the server.
• Plans cap endpoints and monthly events, and the Free plan stops storing new events once its monthly limit is reached.

Storage and retention

Captured requests are stored as they were received, with their headers, body and sender IP address. Masking secrets in the dashboard only hides them on screen. Requests are deleted automatically once they pass your plan’s history period (24 hours on Free, 30 days on Pro, 90 days on Team), unless you pin them or use them in a saved scenario, and you can delete them yourself at any time. Our servers run on Oracle Cloud Infrastructure. The privacy policy covers what we collect and who we share it with.

Payments

Paddle is our Merchant of Record and handles checkout, cards, invoices and tax. We never see or store card numbers. Billing webhooks from Paddle are only accepted with a valid Paddle signature.

What we don’t do yet

We would rather you know the gaps than find them:

• There is no two-factor authentication or single sign-on yet.
• Email addresses aren’t verified at sign-up yet.
• SlingHook has not had an independent security audit and holds no certifications such as SOC 2 or ISO 27001.
• Captured request bodies and headers aren’t encrypted separately inside the database; only signing secrets are.

If any of these block you from using SlingHook, tell us at support@example.com. It helps us decide what to build next.

Keeping your endpoints safe

• Send test-mode or sandbox events where your provider offers them, rather than live customer data.
• Add the provider’s signing secret to the endpoint and pin its scheme, so you can tell genuine webhooks from anyone else who learns the URL.
• If an endpoint URL leaks, delete the endpoint and create a new one.
• Revoke CLI tokens you no longer use from the dashboard settings.

Reporting a vulnerability

We will reply within 3 working days, keep you updated while we fix it, and credit you if you would like. Please test only against your own account, don’t access or change other people’s data, avoid anything that degrades the service for others, and give us a reasonable chance to fix the issue before you share it publicly. We won’t take legal action against anyone who reports in good faith and follows these guidelines.