> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vikat.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security best practices
> Best practices for hosting Vikat on the public internet: strong dashboard credentials, enforced inference auth, locked-down CORS, and reverse-proxy security headers.
**Read this before you expose Vikat to the internet.** Vikat includes secure defaults, but a public deployment is only as safe as the controls you actually turn on. By default the dashboard and inference endpoints are reachable by anyone who can route to the host. The items below are the minimum hardening for any gateway that is reachable from outside your private network.
Most of these controls live on the **Security Settings** page in the dashboard at `/workspace/config/security`, or in your `config.json` (inference and CORS controls under the `client` block; dashboard credentials under `governance.auth_config`). The rest live in the reverse proxy in front of Vikat.
***
## 0. Read the startup security report
You do not have to audit this from memory. On every start, Vikat inspects its own resolved
configuration — after `config.json`, the configuration store and the built-in defaults have been
merged — and reports each permissive setting that is actually in effect. Each one is written as a
`WARN` log line and repeated in a console banner, naming the setting, what it exposes, and the exact
configuration that closes it:
```text theme={null}
security posture: client.enforce_auth_on_inference (false) — inference endpoints answer without a
virtual key, API key or user token. Anyone who can reach this port can spend your provider credits
and reach every model you have configured. Fix: "client": {"enforce_auth_on_inference": true}
```
The report covers `governance.auth_config.is_enabled`, `client.enforce_auth_on_inference`, the field
encryption key, `client.disable_content_logging` and `client.allowed_origins`. A gateway with all
five closed prints nothing, so the report is also the quickest confirmation that your hardening
took effect. There is no flag to suppress it — the way to silence the warning is to fix the setting.
These defaults are permissive and they have not changed. Turning one on in a release would stop
existing deployments answering, so Vikat reports the exposure rather than changing behaviour under
you. Nothing in this report alters how the gateway runs.
***
## 1. Use a strong dashboard password
The dashboard can be protected with **Password protect the dashboard** on the Security Settings page (an admin username + password). Anyone who reaches the dashboard URL without credentials can read configuration, virtual keys, and logs, so this is the first thing to turn on for a public host.
**Password policy is enforced starting OSS v1.6.0 and Enterprise v1.5.0.** On these versions Vikat validates the password both in the UI and on the server before saving, and rejects weak values with HTTP 400. On **earlier versions there was no strength check at all**. If you are running an older build, choose a strong password manually (and upgrade as soon as you can).
The enforced policy requires every dashboard password to have:
* At least **12 characters**
* At least one **uppercase** letter
* At least one **lowercase** letter
* At least one **number**
* At least one **special character**
```json theme={null}
{
"auth_config": {
"is_enabled": true,
"admin_username": "admin",
"admin_password": "env.VIKAT_ADMIN_PASSWORD"
}
}
```
Reference the password from an environment variable or secret (`env.VAR_NAME`) instead of hardcoding a literal value in `config.json`. Env/secret references are stored as-is; literal passwords are hashed before storage.
For Enterprise deployments, prefer **SSO / OIDC** over a shared dashboard password so every operator who can change configuration is a known, traceable identity. See the [security hardening guide](/enterprise/moving-from-oss/security-hardening) and the SSO setup guides ([Okta](/enterprise/setting-up-okta), [Entra](/enterprise/setting-up-entra), [Keycloak](/enterprise/setting-up-keycloak), [Zitadel](/enterprise/setting-up-zitadel), [Google Workspace](/enterprise/setting-up-google-workspace)).
***
## 2. Enforce authentication on inference
By default, inference endpoints (`/v1/chat/completions`, `/v1/embeddings`, `/v1/images/generations`, and related endpoints) accept anonymous requests. On a public host that means anyone who finds the URL can spend against your provider keys.
Turn on the **Enable Auth on Inference** toggle on the Security Settings page (labeled **Enforce Virtual Keys on Inference** in OSS). This requires every inference call to present a valid credential, such as a [Virtual Key](/features/governance/virtual-keys), API key, or user token, which Vikat resolves to scoped upstream provider keys. Your raw provider keys never leave the gateway.
```json theme={null}
{
"client": {
"enforce_auth_on_inference": true
}
}
```
This is the main setting. The older fields `enforce_governance_header` and `enforce_scim_auth` are deprecated. Don't use them in new deployments. Changing this setting requires a Vikat restart in Enterprise.
Once enforced, pair it with [budgets and rate limits](/features/governance/budget-and-limits) per virtual key so a runaway client can't burn through your provider spend even with valid credentials.
***
## 3. Review the rest of the Security Settings page
The Security Settings page (`/workspace/config/security`) exposes several more controls worth checking before going public:
| Setting | Config key | Recommendation for public hosts |
| ------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Allow Direct API Keys** | `allow_direct_keys` | Keep **off** (default). When on, callers can pass their own provider key in a header (`x-vikat-direct-key: true`), bypassing your registered key pool. |
| **Allowed Origins** | `allowed_origins` | Set an explicit list. Never `*` in production. A wildcard lets JavaScript from any page on the internet call your gateway. |
| **Allowed Headers** | `allowed_headers` | Narrow to the minimum your callers need (e.g. `Authorization`, `Content-Type`, your virtual-key and tracing headers). |
| **Required Headers** | `required_headers` | Optionally require headers on every request; missing ones are rejected with 400. |
| **Whitelisted Routes** | `whitelisted_routes` | Only add routes that must bypass auth. System routes (`/health`, login, etc.) are always whitelisted. |
```json theme={null}
{
"client": {
"allow_direct_keys": false,
"allowed_origins": [
"https://app.example.com",
"https://internal-dashboard.example.com"
],
"allowed_headers": ["Authorization", "Content-Type", "X-Request-Id"]
}
}
```
Changing `allowed_origins` or `allowed_headers` requires a Vikat restart to take effect.
Enterprise deployments should also tighten the provider-forwarded `x-vikat-eh-*` header allowlist (`header_filter_config`). See [Tighten both header allowlists](/enterprise/moving-from-oss/security-hardening) for details.
***
## 4. Terminate TLS and serve from a reverse proxy
Never expose Vikat's HTTP port directly to the internet. Put a reverse proxy (NGINX, an Ingress controller, or a cloud load balancer) in front of it to terminate TLS, so all traffic, including dashboard logins, virtual keys, and prompts, is encrypted in transit.
See the [Nginx reverse proxy guide](/deployment-guides/how-to/nginx-reverse-proxy) for streaming-safe proxy settings, and bind Vikat itself to an internal interface so it is only reachable through the proxy.
***
## 5. Send security headers from the reverse proxy
Add hardening response headers at the proxy layer to defend the dashboard against clickjacking, MIME sniffing, and protocol downgrade. Vikat is served behind the proxy, so this is the right place to set them once for every response.
```nginx theme={null}
server {
listen 443 ssl;
server_name vikat.example.com;
# Force HTTPS for one year, including subdomains
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Clickjacking / iframe embedding protection
add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "frame-ancestors 'none'" always;
# Block MIME-type sniffing
add_header X-Content-Type-Options "nosniff" always;
# Limit referrer leakage
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
location / {
proxy_pass http://vikat_backend;
# ... streaming-safe proxy settings (see nginx guide)
}
}
```
```yaml theme={null}
ingress:
enabled: true
className: nginx
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
more_set_headers "Strict-Transport-Security: max-age=31536000; includeSubDomains";
more_set_headers "X-Frame-Options: DENY";
more_set_headers "Content-Security-Policy: frame-ancestors 'none'";
more_set_headers "X-Content-Type-Options: nosniff";
more_set_headers "Referrer-Policy: strict-origin-when-cross-origin";
```
| Header | Protects against |
| -------------------------------------------------------------- | ------------------------------------------------------------ |
| `Strict-Transport-Security` | Protocol downgrade / SSL-stripping attacks |
| `X-Frame-Options` / `Content-Security-Policy: frame-ancestors` | Clickjacking and embedding the dashboard in a hostile iframe |
| `X-Content-Type-Options: nosniff` | MIME-type sniffing |
| `Referrer-Policy` | Leaking dashboard URLs to third-party sites |
Use the `always` flag (NGINX) so headers are sent even on error responses. Only enable HSTS once you are confident HTTPS will stay on. Browsers cache it for the full `max-age`.
***
## 6. Restrict network exposure
Network-level controls limit the impact of a misconfiguration:
* **Don't publish the raw container port.** Expose only the reverse proxy; keep Vikat on an internal network or `localhost` upstream.
* **Firewall / security groups.** Allow inbound traffic only on `443` (and `80` for the ACME/HTTP-to-HTTPS redirect). Block everything else.
* **Restrict the admin surface.** If only your team needs the dashboard, put it behind a VPN, an IP allowlist, or an identity-aware proxy rather than the open internet.
* **Run as non-root.** The official `vikat/vikat-gateway` image already runs as an unprivileged user. Keep it that way and avoid mounting host paths writable.
***
## Hardening checklist
Restart the gateway and check the logs: no `security posture:` lines means nothing on this list is still open.
12+ chars with mixed case, number, and symbol. Upgrade to OSS v1.6.0 / Enterprise v1.5.0+ so the policy is enforced.
`enforce_auth_on_inference: true`: no anonymous path to a model.
`allow_direct_keys: false` unless you have a specific reason.
Explicit `allowed_origins`, never `*` in production.
No raw HTTP port exposed to the internet.
HSTS, frame-ancestors / X-Frame-Options, nosniff, Referrer-Policy.
Per-virtual-key limits before the first real request.
Firewall to 443, admin surface behind VPN/allowlist where possible.
***
## Related guides
* [Nginx reverse proxy](/deployment-guides/how-to/nginx-reverse-proxy)
* [Enterprise security hardening](/enterprise/moving-from-oss/security-hardening)
* [Virtual keys](/features/governance/virtual-keys)
* [Budgets and limits](/features/governance/budget-and-limits)
* [Security at Vikat](/security): how Vikat itself is built and scanned