Security and Operations

Configure origins, CSRF, cookies, proxies, CSP, scaling, and observability with the server-driven runtime in mind.

#security#csrf#cookies#observability

Security and Operations

Vango apps are stateful and long-lived. Security and deployment posture matter early, not just at launch.

WebSocket origins

In production, configure explicit origin checks or same-origin enforcement.

Do not accept arbitrary origins.

CSRF

If you use cookie auth or any stateful HTTP endpoint:

  • enable CSRF protection

  • include the CSRF token on protected form and upload requests

setup.RouteForm.View(...) injects the hidden CSRF field automatically. Raw Form(...) posts, uploads, and custom side-effecting HTTP requests must include it explicitly.

Cookies

Production cookie defaults should usually be:

  • Secure

  • HttpOnly when JavaScript access is not needed

  • an intentional SameSite policy

Treat cookie configuration as a real security decision, not framework boilerplate.

Trusted proxies

If Vango sits behind a proxy or load balancer, configure trusted proxy handling deliberately.

Route agreement between SSR and the live runtime matters. Incorrect proxy prefixing can create route mismatches, reconnect loops, and broken navigation.

XSS and URL sanitization

Prefer typed Vango view code over raw HTML.

When you must use raw HTML, keep the input trusted and sanitized. Treat URLs and browser-exposed payloads as untrusted input.

CSP

Use a real Content Security Policy for production apps.

Keep trust boundaries close to the layout if you allow special cases such as non-default module origins.

Scaling

Vango can scale, but you need to account for stateful sessions, resume windows, persistence, and runtime traffic.

Think through:

  • session store behavior

  • reconnect and resume posture

  • upload and webhook boundaries

  • runtime endpoint prefixing

Observability

Vango supports structured diagnostics and operational reporting. Read diagnostic output literally. The framework is usually telling you which contract you broke.

Common areas to watch:

  • patch mismatch or self-heal reloads

  • stale generated artifacts

  • schema compatibility issues

  • persistence budget failures

Diagnostics and troubleshooting

When debugging, start with:

  1. the exact diagnostic code

  2. recent list or client-boundary changes

  3. recent persisted type or schema changes

  4. recent proxy or deployment changes

For reload spam, inspect list keys, client-boundary ownership, render-time navigation misuse, and SSR versus WebSocket path agreement before blaming transport settings.

Unsafe configuration reporting

Treat break-glass settings as operational exceptions. Review unsafe config reports explicitly instead of letting risky modes accumulate silently.

Next, read Testing and Tooling for the verification and workflow side of app development.