Skip to main content

Secure Your Upstream with the Auth Token

Make sure requests to your upstream really come from SaaS Custom Domains, and set up firewalls, Cloudflare and CDNs in front of it.

Written by Drago Crnjac

Overview

Your upstream receives requests for all of your users' custom domains and uses the X-Served-For header to decide whose content to show. Anyone who can reach your upstream directly could send that header too, and see another user's pages. This article shows how to make sure a request really came through SaaS Custom Domains, and how to set up anything that sits in front of your upstream.

Check the auth token on every request

We add the X-SaaS-Domains-Auth-Token header to every request we forward. Its value is your upstream's auth token, shown on the upstream page under Auth Token, with a button to copy it.

  • Reject any request that has X-Served-For but not the right token. Requests to your own domain, without X-Served-For, aren't affected.

  • Keep the token in an environment variable. Also reject requests when that variable is empty, so a missing setting can't switch the check off.

  • Compare the token in constant time.

The Handling forwarded requests docs have ready-to-use examples for Rails, Node.js, Django and Laravel.

About the token

  • Each upstream gets a random token.

  • You can set your own token by editing the upstream (1 to 64 letters, digits, dashes or underscores).

  • When you change it, have your app accept both the old and the new token for a short time, then remove the old one. Otherwise requests are rejected until your app has the new token.

Don't allowlist our IP addresses

Our proxies run on AWS and their outgoing IP addresses change, so there's no fixed list of addresses to allow. Check the auth token instead.

The two A record addresses, 75.2.96.173 and 99.83.186.151, are where visitors connect to us. Requests to your upstream don't come from them.

Cloudflare or a firewall in front of your upstream

This works, but all your custom domains reach your upstream from a shared pool of proxy addresses. Firewalls can mistake that for bot traffic and block it for a while, usually with a 403 or a Cloudflare error page.

Add a rule that lets requests with your correct X-SaaS-Domains-Auth-Token header through. In Cloudflare, create a WAF custom rule that matches the header value and uses the Skip action for bot and rate limiting checks.

A CDN or cache in front of your upstream

We send your upstream's own host in the Host header, so every custom domain looks the same to a CDN. Add X-Served-For to the CDN's cache key. Otherwise a page, or a redirect, cached for one user's domain can be served on another user's domain.

TLS between us and your upstream

With TLS on (the default), your upstream needs a valid certificate from a public certificate authority such as Let's Encrypt. Self-signed certificates and private certificate authorities are rejected.

If your upstream only serves plain HTTP, edit the upstream, turn off TLS and set the port to 80. Visitors still connect to your custom domains over HTTPS, but the auth token travels unencrypted between us and your upstream, so use TLS where you can.

Until next time, keep building!

Need more help? Reach out via the Intercom chat widget and we'll be right with you!

Did this answer your question?