8SF - Eight Security Fences

Static MPAs have no logins, no sessions, and no user data. That simplicity is a gift: the attack surface is small and predictable. The real challenge is protecting the server, minimizing exposure and ensuring safe browser to server communication.

The Eight Security Fences model creates a layered, resilient perimeter. For tiny sites it may be overkill, but for long term maintainability and sovereignty, it provides a clear model for security.

Fence 1. Redundance

Redundance is not about uptime; it's about sovereignty. If your provider disappears, becomes hostile, or becomes legally risky - can you move your assets within 48 hours?

1. Jurisdictional Exposure

US-based providers: Cloud Act (data readable by US authorities regardless where it is stored)
National Security Letters + gag orders (secretly read your data without your permission)
FISA 702 surveillance (Collect, intercept and read your data)
Unpredictable mess and changing rules make it hard for US tech companies

2. Vendor Risk

Reputation & transparency: How do they handle incidents?
Supply chain depth: Who do they depend on? (e.g., AWS resellers)
Lockin: Are you trapped by proprietary dashboards, DNS, or storage?
Exit cost: Can you rebuild your stack elsewhere in under 48 hours?

3. Geopolitical Stability

Risk of sanctions, routing hijacks, or state interference
Likelihood of internet shutdowns
Predictability of legal processes around data seizure

This fence is about mental and operational readiness: you should always be able to leave.If your stack is in Docker/Kubernetes, you can physically move it to a different host in hours, not months.

Fence 2. Risk Assessment

This fence formalizes what Fence 1 hints at: a structured evaluation of your provider and its ecosystem.

Supply chain risk:

Does your VPS vendor have a clean security history? What about their upstream carriers and data centers?

Exit strategy:

How portable is your setup? Can you redeploy from a Git repo and a tarball?

Business continuity:

Does the vendor have a disaster recovery plan? Do you have off-provider backups?

This fence ensures you're not surprised by the predictable.

Fence 3. Cloudflare
Cloudflare acts as your first line of defense:

DDoS mitigation
Bot filtering
Global caching
Early HSTS enforcement
TLS termination at the edge

But it comes with trade-offs:

Cloudflare sees all traffic
GDPR/CCPA implications
Centralization risk
Potential regional compliance issues

Fence 4. VPS Firewall

Your VPS vendor firewall is your first server-side barrier. Start with deny all. Then open only what you truly need:

80/443 — public web
22 (or custom SSH port) — restricted to your IP
10000 (Webmin) — restricted to your IP

This fence prevents 99% of random internet noise from ever touching your machine.

Fence 5. Dynamic Firewall

Once traffic reaches your server, you may need a reactive layer: Nginx rate limiting combined with fail2ban watching logs and banning IPs that has suspicious behavior. This fence catches brute-force attempts, scrapers, and misbehaving bots that slip past the VPS firewall.

Fence 6. Nginx
Security headers:

X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
HSTS
TLS configuration

Fence 7. Go Web Server

Even static MPAs have some application logic — redirects, headers, logging, maybe small dynamic endpoints.

CSP (Content Security Policy)
CSRF protection (if any forms exist)
Output encoding to prevent XSS
Structured logging for incident analysis
Graceful error handling

Fence 8. Camera on all fences

Every fence should log deviations from the normal:

Cloudflare logs
VPS firewall logs
Nginx access/error logs
fail2ban bans
Go server logs
System metrics

Threats become visible. You can tune your defenses based on real data. This fence is what transforms security from static configuration into an adaptive practice.