Web App Firewall, HTTPS, and Egress Allowlists Explained

Application security splits roughly into "what comes in" (inbound traffic, authentication) and "what goes out" (outbound calls, data exfiltration). Most teams focus exclusively on inbound. The biggest production breaches of 2024–2025 were data exfiltrations made possible by a compromise that allowed unrestricted outbound connections.

This guide covers the three baseline controls you should have on every production application:

HTTPS enforcement.
Some form of WAF (Web Application Firewall).
An egress allowlist.

All three are built into the Launchverse platform; this guide explains what they're for and when you genuinely need them.

1. HTTPS enforcement

This is non-negotiable in 2026. There is no good reason to serve a public application over plain HTTP — every browser flags it as insecure, search engines penalise it, and the certificates are free.

Launchverse issues Let's Encrypt certificates automatically per domain. The "Enforce HTTPS" toggle in the Security tab adds a 308 redirect from any incoming HTTP request to its HTTPS equivalent. Turn it on for every production project; there's no downside and the cost is zero.

2. WAF — Web Application Firewall

A WAF inspects incoming HTTP requests and rejects ones matching known-malicious patterns (SQL injection, XSS, common exploit signatures). The popular open-source standard is OWASP ModSecurity Core Rule Set, which catches roughly 80–90% of automated attack traffic.

You don't strictly need a WAF if your application is well-engineered:

Parameterised queries make SQL injection nearly impossible.
React / Next.js / Vue all auto-escape strings into JSX, killing most XSS.
Modern frameworks default to CSRF tokens for state-changing requests.

But a WAF is cheap defence-in-depth. It catches:

Bots probing for /wp-admin, /.env, /.git/config, etc.
Brute-force credential stuffing.
Old vulnerabilities in libraries you forgot to upgrade.

On Launchverse, the WAF is a Pro+ feature. The Security tab shows what's active and lets you toggle individual rule families on/off if a legitimate request gets blocked.

3. Egress allowlist

This is the control most teams skip. An egress allowlist limits which external hosts your application can call out to.

Why does it matter? Consider what happens if an attacker gets RCE on your container (which happens — usually through a vulnerable dependency, an SSRF, or a misconfigured upload handler):

Without an egress allowlist, they can curl your environment variables to their own server, exfiltrate user data, mine cryptocurrency, or join a botnet.
With an egress allowlist that permits only the hosts you actually use (api.stripe.com, *.s3.amazonaws.com, your Postgres database) — none of that is possible. The compromise stops at your container.

An egress allowlist isn't a substitute for fixing the RCE; it limits the blast radius if you missed one.

How to set it up

In the Security tab on Launchverse, the egress allowlist section accepts a list of hostnames. Add every external host your application talks to:

Payment providers: api.stripe.com, api.paystack.co
Email senders: api.sendgrid.com, api.postmarkapp.com
Object storage: *.s3.amazonaws.com, *.r2.cloudflarestorage.com
Auth services: your-tenant.auth0.com, *.supabase.co

Internal services (your own Postgres, Redis) are always allowed via the project's private network and don't need to be in the allowlist.

When the allowlist is active, traffic to anything not on it is dropped. You'll see this in your application logs as failed getaddrinfo/connection refused — that's working as intended.

Common mistakes

Adding * to the allowlist. Defeats the entire purpose. If you can't enumerate your egress, your dependency surface is too sprawled — audit it.
Forgetting CDN endpoints. Most external APIs use a CDN (*.cloudfront.net, *.fastly.net). Add wildcards for the CDN, not the API hostname, in those cases.
Not testing. Set the allowlist on staging first. Hit every code path. Anything missing will manifest as a connection error; add it. Then ship to prod.

What you don't need

A separate API gateway in front of your application. The reverse proxy on every modern PaaS already does what most API gateways do (TLS, routing, rate limiting). Add Kong/Tyk only if you're running 50+ services.
A bastion host. SSH into your container should not be a daily operation; if it is, you've over-architected. The dashboard's Shell tab gives you a one-shot terminal session that's audited.