Start with the traffic path
A useful security model begins with the actual request path:
User / client
↓
DNS
↓
Public IP / edge
↓
DDoS protection
↓
Security group / firewall
↓
TLS endpoint
↓
Reverse proxy / load balancer
↓
Application
↓
Database / storage / external services
Each layer solves a different problem.
A network firewall can restrict which ports are reachable. It does not validate a login form.
TLS encrypts traffic in transit. It does not prevent an authenticated user from accessing data they should not be authorized to see.
A WAF can block some malicious HTTP patterns. It does not replace secure application code, authentication, or authorization.
Treating these controls as interchangeable creates gaps.
Use modern TLS for public application traffic
For internet-facing applications, TLS should be the default for the entire application rather than only login or checkout pages.
Current security guidance favors TLS 1.3 and supports TLS 1.2 where compatibility is required. Legacy SSL, TLS 1.0, and TLS 1.1 should not be enabled for normal modern web workloads.
A practical target is:
Preferred: TLS 1.3
Compatible fallback: TLS 1.2
Disabled: SSLv2, SSLv3, TLS 1.0, TLS 1.1
Do not weaken the primary production endpoint simply to support obsolete clients unless there is a documented business requirement and an isolated compatibility design.
For a concrete Nginx certificate workflow, use How to Install Certbot for Nginx on Ubuntu 24.04 with Let's Encrypt.
Certificate lifecycle is an operational responsibility
A certificate is not a one-time setup task.
For every public hostname, know:
- who issues the certificate;
- where the private key lives;
- how renewal happens;
- how expiry is monitored;
- which service reloads after renewal;
- who owns failure response;
- what happens during migration or DNS cutover.
Automation reduces manual work, but it does not remove ownership.
A production team should be able to answer:
If automatic renewal fails tonight, how will we know before users see certificate errors?
Certificate-expiry monitoring belongs in the operating model, not in a yearly calendar reminder.
HTTPS redirect and HSTS solve different parts of downgrade risk
A common pattern is:
HTTP :80
→ redirect
→ HTTPS :443
The redirect improves usability when users type or follow an HTTP URL.
HSTS adds a browser policy telling supporting clients to use HTTPS for future requests. This helps reduce SSL-stripping/downgrade exposure after the browser has learned the policy.
Example:
Strict-Transport-Security: max-age=31536000
Options such as includeSubDomains and preload have larger consequences.
Do not enable includeSubDomains or preload casually. Every affected subdomain must be ready for HTTPS for the duration of the policy.
HSTS is sent over HTTPS. Sending it only over an insecure HTTP response does not create the intended protection.
Decide where TLS terminates
TLS termination is the point where encrypted traffic is decrypted.
Common models include:
TLS at the application VM
Client
→ TLS
→ Nginx/Caddy on VM
→ local application
Good for:
- single-VM applications;
- simple operating models;
- teams already managing Nginx or Caddy.
Client
→ TLS
→ load balancer/platform
→ backend
Good for:
- multiple application instances;
- centralized certificate management;
- managed routing.
TLS termination plus re-encryption
Client
→ TLS
→ edge/load balancer
→ TLS
→ backend
Useful when backend traffic also needs encryption in transit across a network boundary.
TLS passthrough
The edge does not decrypt traffic and forwards encrypted connections to the backend.
Useful only when the backend must directly own the TLS session or client-certificate authentication.
The decision should follow the trust boundary, operational ownership, and routing requirement.
For the traffic-layer architecture behind these choices, see Reverse Proxy vs Load Balancer. The comparison covers where TLS is terminated, when a backend connection is re-encrypted, and when passthrough is appropriate; it does not imply every model is a native Raff load-balancer feature.
Private networking does not automatically remove encryption requirements
A private network reduces internet exposure. It does not automatically make every internal connection trustworthy.
Ask:
- Is the network shared across workloads or teams?
- Does the connection cross infrastructure you do not fully control?
- Do compliance or contractual requirements require encryption in transit?
- Is authentication tied to the TLS channel?
- What is the impact of an internal credential or routing compromise?
For some internal application-to-database traffic, private networking plus authenticated database connections may be sufficient for the risk model. In other cases, TLS should still be required.
Use Private Networking Explained: VPCs, Subnets & Internal Traffic for the network boundary. Raff VPC is the product path for private cloud-resource networking, not a replacement for TLS or certificate verification.
Encryption at rest and encryption in transit solve different problems
Encryption in transit protects data while it moves between systems.
Examples:
- HTTPS;
- database TLS;
- mTLS between services;
- encrypted API calls.
Encryption at rest protects stored data against certain storage/device exposure scenarios.
Examples:
- encrypted disks;
- encrypted object storage;
- encrypted database storage;
- encrypted backups.
One does not replace the other.
A database may be encrypted at rest while credentials travel over an unencrypted network. Conversely, a perfectly encrypted HTTPS session can still write plaintext-sensitive data into an insecure application log.
Think in terms of data lifecycle, not one encryption checkbox.
Security groups and firewalls reduce exposed network surface
Raff's current security model includes stateful security groups and isolated VPCs.
Use them to expose only the ports that must be reachable.
A typical public web VM might need:
80/tcp → HTTP redirect or ACME
443/tcp → HTTPS
22/tcp → restricted administrative source only, if SSH is needed
The application runtime port such as 3000 or 8000 should usually remain private when Nginx, Caddy, or another proxy owns the public entry point.
A firewall is the network exposure boundary. It does not inspect business logic or user authorization.
Use Cloud Firewall Rules Explained for network-rule design.
WAF and firewall are not the same control
A network firewall answers questions such as:
- which source can reach this destination?
- which protocol?
- which port?
A web application firewall operates at the HTTP/application layer and can inspect request patterns, headers, paths, and payload characteristics.
A WAF can be useful for:
- blocking known exploit patterns;
- managed rule sets;
- virtual patching in some cases;
- reducing obvious malicious HTTP traffic.
But a WAF cannot reliably replace:
- authorization;
- secure query construction;
- validation;
- dependency patching;
- session security;
- business-logic abuse controls.
Raff's current security page documents DDoS protection, security groups, VPC isolation, IAM/MFA, and audit logs. Do not assume that means a managed WAF is automatically present.
If your application requires WAF functionality, treat that as a separate architectural requirement and verify the actual provider/product before designing around it.
DDoS protection and rate limiting solve different problems
DDoS protection attempts to preserve service availability during malicious traffic floods.
Rate limiting controls how frequently a source, identity, token, or route can perform an action.
Examples:
- login attempts per IP;
- password reset attempts per account;
- expensive API calls per API key;
- webhook submissions per source.
Infrastructure DDoS mitigation does not remove the need for application/API rate limiting.
For API-level controls, use API Rate Limiting: Protecting Apps Without Blocking Real Users. For an infrastructure-versus-application attack-response framework, see DDoS Protection for Small Teams.
Security headers can reduce several browser-facing risks.
Important examples include:
Content-Security-Policy
Controls which sources the browser may load for scripts, styles, frames, images, and other resources.
CSP can reduce the impact of some cross-site scripting paths, but a poorly designed policy can break the application.
Strict-Transport-Security
Tells browsers to prefer HTTPS for future requests.
X-Content-Type-Options
Commonly set to:
X-Content-Type-Options: nosniff
frame-ancestors / X-Frame-Options
Controls whether pages may be embedded in frames, reducing clickjacking risk.
Modern CSP frame-ancestors is often the more expressive control.
Referrer-Policy
Controls how much referrer information browsers send to other destinations.
Do not copy a "perfect security headers" block from another application without testing. CSP in particular must match the application's actual resource and integration model.
Headers such as CSP and HSTS are primarily enforced by supporting clients, especially browsers.
They do not replace server-side controls for:
- API authentication;
- authorization;
- input validation;
- request signing;
- service-to-service identity.
A backend API called by another server may not use browser security headers in the same way a web page does.
Mutual TLS is useful when both sides need certificate identity
Normal HTTPS authenticates the server to the client.
Mutual TLS (mTLS) adds client certificate authentication:
client verifies server certificate
+
server verifies client certificate
mTLS can fit:
- service-to-service communication;
- partner integrations;
- administrative APIs;
- high-trust internal systems.
Trade-offs include:
- certificate issuance;
- private-key protection;
- rotation;
- revocation;
- client onboarding;
- debugging complexity.
For many public APIs, OAuth, signed tokens, or API keys plus TLS can be operationally simpler.
Do not choose mTLS solely because it sounds stronger; choose it when certificate-based client identity fits the threat model and operational capacity.
Edge security should be layered, not duplicated
A practical small-team model can look like:
DDoS protection
→ security group
→ TLS
→ reverse proxy
→ authentication
→ authorization
→ rate limiting
→ validation
→ application
Optional controls can be added where justified:
WAF
mTLS
CSP
additional edge proxy
bot controls
The aim is not maximum number of controls.
The aim is that every important threat has an owner and every control has a reason.
For Raff workloads, the current platform security boundary includes infrastructure controls such as:
- DDoS mitigation on public IPs;
- tenant/VPC isolation;
- security groups;
- IAM and MFA;
- audit logging.
Your workload team remains responsible for controls including:
- guest OS patching;
- which ports you expose;
- TLS/certificate configuration inside VMs where you terminate TLS;
- application authentication and authorization;
- secrets;
- API validation;
- security headers;
- application rate limiting;
- WAF integration when required;
- application dependency security.
That distinction matters during incidents. A platform can remain healthy while the application is insecure or unavailable.
A practical edge-security review
For each public application, review:
Network exposure
- Is only required traffic public?
- Are administrative ports restricted?
- Are databases and internal services private?
TLS
- Are supported protocol versions intentional?
- Does HTTP redirect to HTTPS where appropriate?
- Is renewal automated?
- Is expiry monitored?
Proxy/load-balancer
- Are forwarding headers correct?
- Is TLS terminated at the intended layer?
- Is backend encryption required?
Browser/API controls
- Are authentication and authorization explicit?
- Is rate limiting applied to abuse-sensitive operations?
- Are security headers tested?
- Is request size bounded?
Recovery
- Can a certificate be rotated quickly?
- Can a compromised secret be revoked?
- Can a bad edge configuration be rolled back?
- Are logs sufficient to investigate abuse?
Edge security mistakes to avoid
Exposing the application port directly
If the reverse proxy owns the public edge, there is usually no reason to expose both the proxy and application runtime ports publicly.
Treating HTTPS as proof the app is secure
TLS protects the connection. It does not fix broken authorization, injection, weak passwords, or vulnerable dependencies.
Adding HSTS preload without inventorying subdomains
A forgotten HTTP-only subdomain can become inaccessible.
Putting every dependency into a readiness probe
A temporary dependency failure can remove every application instance from service and amplify the outage.
Applications should trust proxy headers only from expected proxy infrastructure.
Assuming DDoS protection replaces application abuse controls
Volumetric protection does not prevent credential stuffing, expensive API misuse, or business-logic abuse.
Frequently asked questions
What is application-edge security?
Application-edge security is the set of controls protecting the public boundary between clients and an application, including TLS, firewalls, proxies, security headers, rate limiting, and optionally WAF or mTLS.
What TLS versions should a modern web application support?
Current guidance prefers TLS 1.3 and may retain TLS 1.2 for compatibility. Legacy SSL, TLS 1.0, and TLS 1.1 should not be enabled for normal modern workloads.
Is a firewall enough for a public web application?
No. A firewall controls network exposure, while application security also requires TLS, authentication, authorization, validation, and workload-specific controls.
Is a WAF the same as DDoS protection?
No. DDoS protection focuses on availability under traffic attacks, while a WAF inspects HTTP/application-layer requests. They address different threat classes.
Should I enable HSTS preload?
Only after every relevant subdomain is confirmed to support HTTPS and the team understands the long-lived consequences. Ordinary HSTS should also be rolled out deliberately.
When should I use mTLS?
Use mTLS when certificate-based client identity is justified, commonly for service-to-service or trusted partner communication. Account for certificate issuance, rotation, and revocation overhead.
Does Raff provide a managed WAF?
Raff's current public security page documents DDoS protection, security groups, VPC isolation, IAM/MFA, and audit logs. A managed WAF should not be assumed unless it is explicitly available and verified at the time of deployment.
Sources
