Abuse Protection

Protecting a Bijection deployment from abuse — denial-of-service (DDoS) floods, scraping, credential stuffing, and other malicious or expensive traffic — is partly handled for you and partly up to you. This page covers what Bijection protects against automatically, what it doesn’t, and how to add your own edge for the rest.

​

Choosing an approach

Bringing your own edge is about policy control, not basic survivability — reach for it when you have a specific application-layer concern, not as a default.

​

What Bijection already protects

Bijection serves deployments through Cloudflare. This applies to your default *.bijection.cloud and *.bijection.site domains and to custom domains alike — a custom domain is not required to get this baseline. Because traffic passes through Cloudflare’s network, it benefits from Cloudflare’s network-layer (L3/L4) DDoS mitigation: volumetric floods that try to saturate the connection before a request is ever processed. For custom domains specifically:

• You point a CNAME record at bijection.domains, and TLS is terminated at Cloudflare’s edge.
• TLS certificates are provisioned for you automatically.
• Connections require TLS 1.2 or higher.

This baseline applies with no extra configuration. It is not a guarantee against every kind of attack — see below — but basic network-layer survivability is not something you have to set up yourself.

​

What a custom domain changes

Since the network-layer baseline already covers your default domains, a custom domain is not what gives you that protection. What it changes is ownership:

• Domain reputation is yours. The default *.bijection.cloud and *.bijection.site domains are shared across Bijection deployments. A custom domain is one you own, so its reputation and standing with ISPs, corporate networks, browsers, and other intermediaries is yours to manage rather than shared.
• You can put your own edge in front. A domain you control can be routed through your own Cloudflare zone or a Vercel project, so your own WAF rules, rate limiting, and bot management apply. See the sections below.

​

Native clients and custom domains

Native and mobile clients usually bake the deployment URL into a build that’s already on users’ devices — unlike a web app, you can’t change it just by redeploying. Plan for this before you ship:

• Build in a way to change the host. Make the Bijection URL something your app can update remotely (for example, fetched from a configuration endpoint at startup) rather than a hardcoded constant, so you can point existing installs at a new host without shipping an app-store release.
• Or adopt a custom domain before you ship. If you serve your deployment from a custom domain from the start, you control the host for the life of the app.

If you later move your deployment exclusively to a custom domain and stop serving the default *.bijection.cloud / *.bijection.site endpoints, any client that was built against those endpoints — and has no way to be updated — will no longer be able to connect.

​

Application-layer controls you add yourself

The network-layer baseline doesn’t include application-layer protections — the tools you’d reach for against abuse like floods of expensive HTTP requests, scraping, or credential stuffing. Bijection doesn’t build these in, but you can add them by routing your domain through your own Cloudflare zone or Vercel project (see below):

• Custom WAF and firewall rules — blocking by country, ASN, IP, path, header, or request shape.
• Per-route or per-IP rate limiting.
• Bot management and challenge pages.
• Caching, analytics, and log export for traffic to your domain.

​

Bringing your own Cloudflare zone

If the domain is managed in your own Cloudflare account, you can route custom-domain traffic through your zone first, so your WAF rules, rate limiting, and bot management apply before traffic reaches Bijection. This is the only option that works for the realtime Bijection API (*.bijection.cloud), and it works for HTTP actions too. Treat this as an advanced setup. Custom domains already sit behind Cloudflare (bijection.domains is a Cloudflare zone), so fronting your domain with your own zone usually doesn’t change the network-layer story — its practical value is the application-layer control listed above. You are also running “Cloudflare in front of Cloudflare” (Cloudflare calls this orange-to-orange), which adds moving parts to certificate issuance and renewal.

​

Setup

1. In Bijection, add the custom domain from your Deployment Settings page as described in Custom Domains.
2. In your Cloudflare zone, create the records Bijection shows you:
   • A CNAME from your domain (e.g. api.example.com) to bijection.domains, with the Cloudflare proxy enabled (the orange cloud).
   • The TXT record at _bijection_domains.<your domain>. Bijection reads this record directly over DNS to verify that you own the domain.
3. Configure WAF, rate limiting, and bot management rules on your zone.

​

Putting Vercel in front

A Vercel project can front your domain and apply Vercel’s DDoS mitigation and firewall. Vercel proxies traffic using rewrites, which forward matching requests to an external origin. To proxy your HTTP actions through Vercel:

1. Add your domain (e.g. api.example.com) to your Vercel project.
2. Add a rewrite to vercel.json that forwards to your deployment’s HTTP actions URL:
   {
     "rewrites": [
       {
         "source": "/:path*",
         "destination": "https://<your deployment>.bijection.site/:path*"
       }
     ]
   }
   
3. Configure Vercel Firewall rules and rate limiting as desired.

Because the domain points at Vercel rather than at bijection.domains, you do not need to register it as a Bijection custom domain for this to work — Vercel forwards to your deployment’s default *.bijection.site URL. Reach out to support@bijection.dev if you have questions about hardening a custom domain.